I am trying to use GitHub for the first time and have managed to upload a small project i am working on.
The problem is that all of my files but one are being added to GitHub - i created this file after committing the project and have tried right clicking and 'ADD' but this does not seem to work.
Does anyone have any ideas of what the problem could be? I understand this is probably a fault on my behalf, i am just not able to figure out what i must do to rectify it.
Using "ADD" without "COMMIT" only informs git that the added file should be included in the next commit, but it doesn't trigger any action itself.
You need to commit the file after using "ADD" in order for it to be versioned.
So:
Right click on the file -> ADD
VCS Menu -> Commit changes
Your file should appear on the list with the tick next to it. Click commit and you are good to go.
Do you have a git bash? If no, I recommend installing it, then try:
Run Git bash -> go to your project directory
git status -> should produce sth like "Untracked files: "
git add .
git commit -m "YourMessage"
git push
This should add your file to git versioning and push it to the GitHub repository.
The most common reason for this is there is no change seen. Try making another change to the file, even if you just add spaces to the end of one of he lines. Then save and try the commit again.
I had the same problem after creating the repository and committing; the only file committed was the MainActivity.java file, all other files were showing as 'unversioned file'.
Make sure to change your Project Window view to 'Project'.
Then right click your project and select Git --> +Add.
All files will be updated and the "unversioned" list will be gone.
Related
I have an empty SVN repo on a remote server. I moved the code into kdesvn app and now I need to make a first commit. But I want to exclude some folders from commit (ignore them) so that they never upload later on.
How shall I do it in kdesvn? I went to Repository menu but could not find a command to mark folders ignored.
EDIT
I did not commit anything yet. Just copied sources into kdesvn. On each file and folder I have icon with a green plus symbol and the status saying "locally added". Look at the image
You want to make a SVN revert. With kdesvn you select the files to revert, then in the menu Subversion > Working Copy > Revert current changes.
If you want to SVN ignore them, just right-click on a file that is not under version control (grey background color) and select Ignore/Unignore current item.
I've checked out a copy of the SVN branch (my branch) locally to which I've merged from a different branch (which has a completely different folder structure). So basically there are a lot of deletions (of old files) and additions (of new files).
When I try to commit the merge to the repository (to my branch), Tortoise says
This commit is not recursive, and there are moved/renamed folders selected for commit. Such moves/renames are always performed recursively in the repository. Do you want to commit anyway?
Is it fine to proceed with this commit? If not, what should I do so that there's no problem?
Also, for some files that I've added, I've made changes after adding (if this affects the nature).
Found by Google how to fix it: press F5 in the commit window (not in the "warning popup")
See http://tortoisesvn.tigris.org/ds/viewMessage.do?dsForumId=757&dsMessageId=2831045 for details.
On 26.08.2011 22:39, Ryan J Ollos wrote:
For several months now I've been seeing the following dialog box appear when
initiating Commit. It frequently happens when attempting to commit following
a merge.
The thing I have noticed lately however is that if I Cancel and then
manually refresh the file list (F5), I don't see the message again when
initiating the commit a second time. The commit seems to succeed fine and
with no further problems.
The commit dialog monitors the working copy in a background thread for
change notifications. Such notifications are sent by the OS in case
files are modified/moved/renamed/...
If such a notification is received, the commit dialog first does a few
checks so it can drop most of them. If the notification indicates that a
file that is not checked and not visible in the commit dialog has
somehow changed, it switches back to non-recursive committing.
That's because if you have e.g. a file open in another editor and save
your changes while the commit dialog is open, then that file would get
committed as well even though you haven't checked it in the commit
dialog (it doesn't show up until you refresh the dialog with F5).
So if you see that warning dialog often, please check if there's another
tool/app running which modifies files in your working copy.
And as you noticed: if you hit F5, that 'non-recursive flag' is reset
because after a refresh, you see all the files again - even the ones you
modified after you started the dialog.
Stefan
I had the same issue but resolved it by reverting changes to files that I had marked to 'ignore-on-commit'
Once I reverted these files, then tortoisesvn was able to commit all the other files from the merge
Is it fine if i proceed with this commit?
No, your commit will ignore all changes in WC-tree and reflect only root-level changes (broken merge).
You made an error when checking out non-recursive initially. You can try to perform good, full commit using --depth infinity parameter in the CLI or find this switch in TortoiseSVN GUI.
svn commit --depth infinity . -m "Merge"
Also for some files that I've SVN-added , I've made changes after adding (If this affects the nature).
In my case that was exactly what caused the message to appear, even I unselected those files for the commit.
Ugly solution which only works safely if just a few files are affected:
Create a copy of the changed files
Revert the changed files
Commit the merge/reintegration
Copy the changed files back to the original place
Reminder to self: only reintegrate a branch if the target (trunk) is clean.
I just had the same issue. Instead of selecting all the files, I clicked on versioned and everything worked well. In my case, the option versioned selected all the files, so everything is ok now.
It looks like TortoiseSVN performs some kind of validity checking before calling commit. Good but the error message is very unclear.
When I faced this issue, I went back to using the svn command line to commit. Commit failed due to the reason that one of the folders was not up to date. After updating just that folder, I ran "svn commit" once again and it went through.
Edit: PS: Before you use try this out, make sure you do not have any files marked as "ignore on commit". "Ignore on commit" is tortoise specific and SVN commit picks these changes as well.
Just thought I'd post this because it worked for me...
The reason this happened is because I'd partially renamed one of the new projects I'd created and for some reason they all showed up as "Missing" on the commit screen.
After I removed the project and folder (which SVN had put a tick on) and put it back in as a new project again, suddenly all of the "Missing" had turned into "Added" and the commit ran fine without warning me of anything.
Hope this helps!
I saw this issue and the cause was a few added files not having the added status for no apparent reason. They were 'normal' even though the parent folder correctly showed as 'added'. I reverted those 'normal' changes and then manually re-did them. This made each added item show up twice in the commit list but it resolved the error and everything appears to be in working order now.
It didn't have anything to do with ignore-on-commit as in another answer, it just seemed like a bug in TortoiseSVN.
The problem could be, that your mergeinfo is deleted by someone or automatically, because the infos moved up in the tree. If you are gonna merge them in again, it will work for the moment. But all others will get problems with their not merged branches. SVN will loose some code and merge already submitted code again.
So reverting those files and changing them again could work, but you should not just commit the changes.
i don't know a option for tortoisesvn but u could use the command line
svn commit --non-recursive [folder]
thats sould work just as u like it to work
greeings
I use tortise svn in VS2010. When I go to commit my changes at the end of the day, I get the following error.
Commit item 'folder / filename' has copy flag but an invalid revision.
What does that mean and how do I resolve it? I Googled for it but really only saw a transcript of a rather esoteric discussion for a Java-related issue.
EDIT - 10/25/2010
Nothing? Really?
I agree with Pekka's comment. Right click on the project folder -> TortoiseSVN -> Check for modifications. Take note of the files you changed.
Create a new folder - and checkout the repository to the new folder. Move the files that changed back into the new folder, replacing any existing ones. Try your commit again.
You may try doing this with Windows Explorer instead of Visual Studio.
have you renamed that folder[say, folder1]?
If not then, "export" the content of that folder to somewhere else[say, folder2].
go back to parent of folder1 and delete then update folder1.
replace all the files[*not folder*s] in folder1 with the equivalent files from folder1
now commit folder1 independently after stealing any lock if exists.
What happens if you try to get the latest revision (update before committing, but after you back up your code ;)?
It sounds like there is potentially something that is in conflict in a bad way - you may need to back up your files, update or check out a new working copy, and then replace checked out files with your old ones.
check out a clean copy. put in the changes you previously made. commit.
do that, and try to forget your problems. it should work.
Using TortoiseSVN, how do you tag the code?
Is the process to branch exactly the same?
I know you have to just copy the code to the /tag/ folder, but how?
i.e. I want to copy revision # to a tag#.
Will it affect the /trunk/ at all?
The answers here were missing some key information for getting started with SVN and braches.
Step 1: You need to make sure you have a suitable branches/tags dir. e.g. if your project has this structure:
url/myproj/trunk/...
you also need:
url/myproj/tags/
url/myproj/branches/
To do this, don't "add" the directories and commit them, or tortoise will give you an error. Instead use the tortoise svn repo-browser, go to myproj then right click and "add Folder".
Step 2: Right click on your trunk folder, select "tortoise SVN" then "branch/tag". The copy branch/tag dialogue now pops up.
Step 3: Set the "to Path" to "/myproj/tags/myversion" where myversion is usually something like "1.0". Select "Head revision in the repository" and make sure "switch working to new branch/tag" is not checked. Hit OK.
Step 4: Unfortunately, next time you do an update, it will pull down the branches and tags as files. This means your HD will get filled with every file from every branch and version created. One solution is to only checkout each individual trunk dir, which is not always convenient (as you have to manually update 30 trunk dirs if you have one repo with 30 projects).
Personally, having used CVS, SCCS, PVCS, VSS & Rational for 30 years, I find SVN much harder to work with.
Right click on your project folder and select Branch/Tag
Point the URL to whatever you want the folder to be called inside the /Tag/ folder
Select Specific revision in repository and choose the one you want
It won't affect the trunk at all.
How to create a tag :
Right click on your repository local copy
Choose Create a branch or a tag...
Choose URL of the tag (normally at the same level that trunk you have a tags folder)
Choose which revision you want to tag
(Usually, you will choose HEAD revision. Why ? Because normally tags are to mark a state of your repository typically for release management, and then when you have the repository state wished, you tag it and then continue the development.
Yes, it's almost the same process that for branches, the difference is "conceptual".
No effect to your trunk !
Here's the official documentation.
Creating a tag won't affect the trunk nor your working copy (you'll still be pointing to trunk) unless you switch to the newly created tag or branch.
Answers below:
The process is almost exactly the same as a branch.
A branch is a tag which is updated essentially.
Right click on the folder you want to tag, click on RepoBrowser, then branch/tag.
Modify the ToURL, with where you want to place your tag
Enter your comment/tag in the box below.
This will tag the code in the folder, without moving it.
This will not effect the trunk at all.
I have a settings file that is under version control using subversion. Everybody has their own copy of this file, and I need this not to be ever committed. However, like I said, there is already a copy under version control. My question is: how do I remove this file from version control without deleting everyone's file, then add it to the ignore list so it won't be committed? I'm using linux command line svn.
Make a clean checkout, svn delete the file and add the ignore. Then commit this. Everyone else will have to take care (once) that their local copy isn't deleted on the next svn update, but after that, the local file would stay undisturbed and ignored by SVN.
If you remove the file from version control, how does a developer new to the project (or the one who accidentally deleted his local copy) get it after initial checkout? What if there are additions to the settings file?
I would suggest the following: Keep a default settings file (with no passwords, hostnames, connection strings, etc.) in SVN, name it something like settings.dist, and let the code work with a copy of this, named settings. Every developer has to make this copy once, and can then work with her personalized settings. If there are additions, add them to settings.dist – everyone else will get them with a update and can merge then into her personalized copy.
After you delete the file, your users will have to recover the file from the repository using svn export.
$ svn export -r x path ./
Where x is a revision where the file existed before it was deleted, path is the full path to the file, and ./ is where the file will be placed.
See svn help export for more information.
simply define a file containing settings that will override the default ones. This file is not checked into Subversion and each developer is responsible for maintaining this file according to their environments.
In an Ant-based world, you would have the files:
settings.properties
settings-local.properties (ignored for Subversion)
and in your build.xml file
<property file="settings-local.properties"/>
<property file="settings.properties"/>
For those who couldn't connect the dots:
modify the build.xml file like proposed
set the setting-local.properties as ignored
in an init target of your build, copy the settings.properties to settings-local.properties
wait a couple of days until everyone had the chance to run this target
delete the setting.properties from Subversion
Voila, every developer has its own setting-local.properties and everything was done automatically (and no developer lost his or her settings, which happens if you brutally delete the file from Suvbersion and there is no "Everyone else will have to take care...")
I have a similar issue. In my case it's an auto-generated user settings file (visual studio) that was accidentally checked in very early in the project. While just deleting it might work, it seems more correct to have it removed from the history, as it was never supposed to be in there in the first place.
I came across this, which might be a new feature since this question was originally posted 7.5 years ago:
https://stackoverflow.com/a/6025750/779130
Seems like an idea would be to:
1) create a dump of the project.
2) filter the dump using `svndumpfilter` to exclude the unwanted file(s).
3) load the dump as a new project.
This might be the only way to completely get rid of the file. In most cases the "delete and ignore" approach might be good enough.
[[ I'm new to subversion, so maybe this doesn't make sense. marking this as wiki -- if you know the right answer, please APPEND in the later section ]]
Couldn't you have a custom set of checkout steps so each user gets a different settings folder?
$ svn checkout http://example.com/project project
..
$ dir project
original_settings\ folder1\ folder2\
$ svn checkout http://example.com/project/aaron_settings project\settings
..
$ dir project
original_settings\ folder1\ folder2\ settings\
Or for new users
$ svn import project\settings http://example.com/project/aaron_settings
What I'm getting at is you want each user to have a custom view of the repository. In other version control systems, you could set up a custom listing of which projects you were using and which you weren't and which you put in odd places.
Does this work in subversion? The above code looks really risky, but maybe i'm doing it wrong.
WIKI:
(nothing yet)