I just spent a fair amount of time selecting the files and directories I wanted under version control. I'm running subclipse under eclipse. I right clicked, Team, Add to Version Control. Now I want ONLY those files committed without right clicking the whole directory which contains a huge number of media files that I don't want handled by version control. If I go Team/Commit under that directory it hangs for a very long time... I thought by "Add to Version Control" there was an option to commit those files only. I just don't know how to do it.
I hope I explained the question properly..
UPDATE:
Since people are talking more about ways to ignore files rather than committing what you're marked as "Add"ed to Version Control, let me put this a different way. What does "Add to version control" do exactly? It seems to be a feature without use.
Subclipse includes both unversioned files and files you specifically marked for addition when you open the commit dialog. It does not perfectly mirror the behavior of the command-line client. You have two options: uncheck each file you do not want to commit in the Subclipse commit dialog or use the command-line svn tool to commit. The command-line tool will only commit files you have marked for addition and will ignore the other files. Here's a simple example:
$ touch file
$ svn status
? file
$ svn add file
A file
$ svn status
A file
$ touch file2
$ svn status
? file2
A file
$ svn commit -m "Added empty file"
Adding file
Transmitting file data .
Committed revision 2.
? denotes a file that it unknown to svn and will not be put under version control automatically by svn commit. A denotes a new file that is scheduled for addition. Subclipse is trying to mirror this behavior by allowing you to "add a file to version control", which is the equivalent of the command-line svn add. but also includes unversioned files not scheduled for addition in its commit dialog (which I personally find somewhat annoying). If you run svn status on the command-line, those files which you "added to version control" in Subclipse will be marked with an A while those you did not will be marked with a ?. You won't have to run any svn add commands since you did that already in Subclipse.
You can add a pattern in Preferences/Team/Ignored resources (it's not the same as svn:ignore). You can also delete it, if it is no longer helpful.
use svn:ignore for the resources you don't need under version control (Team > Add to svn:ignore)
Related
I am working on a Java project in Eclipse and I use SVN to commit various versions of it in the repository. However I have noticed, that when I delete a class and I then commit the project, the old class is still included in the latest committed version of the project. Is there any way to prevent the SVN from maintaining classes which have been actually deleted?
Update: The same problem comes out when I rename a class and then I try to commit the new version of the project. It keeps both classes and stores both on the repository version. How can I prevent it from storing the old ones? I appreciate deeply any help bacause I would not like in any case to store it spoiled with the old classes.
If you use an Subversion for Eclipse like SubClipse then deleting a file in Eclipse will automatically schedule the file for deletion on next commit.
If you use a Subversion client outside of Eclipse you will have to delete the file using that client and then refresh the project in Eclipse after the file is gone from your working copy.
You need to also delete the class in svn as well, something like:
$ svn rm path/to/class.java
You can also remove the file using Eclipse, assuming that you have the svn plugin installed. Make sure that you select the file when you are committing your changeset, otherwise the deletion won't be sent to the server.
Update: Answering the update to the question
$ svn mv path/to/OldClass.java path/to/NewClass.java
Or, as Martin mentioned, ensure that your have your subversion plugin in eclipse properly configured, then it will also do the svn rm and svn mv commands for you.
SVN needs to know about any changes for all files and folders that are controlled by SVN (i.e. that are put under version control). It is easy to detect file changes, but it is not easy to detect rename and delete operations. If you just delete a file (using your operating system tools), SVN will warn you about a missing file.
For these operations you must use the corresponding SVN commands. SVN is best learned, when doing it manually with all those SVN commands (at first).
Using a SVN client makes it a little easier for you. For example, if you use TortoiseSVN, you can right-click a file and choose "SVN delete" for doing both, deleting the file and communicate it to SVN. Same for renaming.
The same is done by using a SVN plugin in Eclipse (Subclipse or Subversive, for example). If you then use Eclipse for deleting or renaming a file, the plugin will also do the operation and communicate it to SVN.
Keep something in mind: When deleting or renaming files (and/or folders) - using SVN commands, of course - you should always do a SVN update prior to SVN commit. Otherwise you might get an error about a revision problem.
Decided to take the jump from CVS to SVN.
I setup a new repository in subclipse for my project. When I go to 'Finish' the setup it wants to do an initial commit and presents me with a flat list of files to select the files for version controlling.
The problem is I have thousands of generated binary files I dont want to commit.
So I click on cancel because it would take me all day to go through and unselect all the unwanted files. Annoyingly when I click on a parent category for the files I want to ignore it is not recursive!
So I click cancel then go to the eclipse directory structure for the project and manually set svn:ignore on all directories I want to ignore. Then I try and do a commit again and all the files are once again presented - ignore seems to have done nothing.
Can anybody point out what I might be doing wrong?
For the first commit, I recommend writing a small script to delete (of course you'll have a backup) all the files that are not meant to be committed.
Afterwards, if you find you accidentally committed a file, you can
svn delete file
Upon the first checkout, copy back (or better yet, regenerate) all the binary files. This will trigger svn to notice that your local repository is out-of-sync with the remote repository.
cd <Root of local repository>
svn status
You will see lots of "to be added" items. Go to the parent directory and add in svn:ignore properties for each of the generated items.
cd build
svn propedit svn:ignore .
which will open an editor (if it doesn't, you need to set the environmental variable SVN_EDITOR to a suitable editor). Then you can add in entries that svn will know are not tracked.
(in the ignore property editor)
target
build
image*
*.o
(and so on)
Save the file, and it will be staged for the next commit. Subsequent runs of svn status will no longer show these files as "needing to be added", but they will show the directory as "needing to be committed (it's a revision on the directory)"
Quick Aside
So I'm not entirely certain exactly which functionality of Subclipse you were using in order to create a repo and share a project to it, I'm assuming you created like a file based repo through the eclipse SVN repo view and tried to share and then commit to it. It looks like your problem got solved but I did want to add an answer on here because I ran across this post looking for the answer to this same problem of handling initial commits even just in general with SVN and wanted to offer help to anyone else looking for the help.
Intro
To start off I would recommend not working through an IDE extension like this just for the initial commit as they can miss a lot of the options for handling opening a repo in SVN. I personally really like the command line form of SVN to work with but TortoiseSVN is a good option for a GUI.
Whether you create a local file-based repo or are connecting to an SVN server and you want better control over your first commit in an previously unversioned project here is what I've found as the best general workflow for doing so.
Create the remote folder to save to.
On command line this will be:
$> svn mkdir your-url-scheme://your-site-address.domain/path/to/repo/example-directory
Or on TortoiseSVN open your repo for browsing, right click, and select "create new folder"
This will give you a location in the SVN repo to checkout from for our next step.
Checkout in to the already started project
Make sure to use the empty, newly created folder in your repo to checkout with. SVN does not actually require a folder being checked out to to be empty, which is an important part of what makes it actually very flexible and able to subsume parts of your directory into it fairly easily if used correctly.
Now you will checkout this empty folder into the root folder of your already started project. This will add your project to the working copy of this folder without any commit being made yet. The command is:
$> svn co your-url-scheme://your-site-address.domain/path/to/repo/example-directory /your/projects/root/
"co" standing for checkout. In Tortoise svn you can right click on or in the empty repo folder and select "checkout..." and then select the project root.
Set ignores and commit
Finally, you can easily set your ignores on certain files before adding any other files to the tree using the command:
$> svn propset svn:ignore file-or-directory-to-ignore
And to add all non-ignored directories and files:
$> svn add * --force
The force is technically unnecessary in this case but ensures full recursion. You can also now do all of this in your file explorer if using TortoiseSVN or you can even use your IDE extensions to do this at this point(make sure to ignore all files you need to before mass-adding files for commit), all that's left is to make sure to commit the newly added files to the repo and you're up and running with source control :)
Added this method here simply because this method allows you to avoid any unnecessary copying of those stinky binaries that no one wants to lug around with them.
I am having terrible trouble with SVN in Eclipse Indigo with my Java project.
I am not a hobby, not a professional programmer, but I have heard how important version control systems are for serious projects, and thought it was time I learned how to use one.
Now I find I can't commit, no matter what I try. I get different errors depending upon what I do.
I suspect the problem was caused by my checking the "Persist project refactoring history in project folder instead of workspace" box in Project > Properties > Refactoring History, but I am not sure. But since I did that, I got an error saying "svn: Path '.settings' not present" error. I tried again,unchecking the box for .settings/org.eclipse.ltk.core.refactoring.prefs. This time I got a different error upon an attempted commit, "Path 'gamecore' not present". ('gamecore' is a root-level package in the project, where I'm putting most classes until they can be moved somewhere more appropriate.)
I tried several permutations of fiddling with the project preferences I'd changed, and unchecking some files on attempted commits. All failed.
In desperation, I cut n' pasted the source files I'd changed to a text file, reverted to my previous version, then cut n' pasted the new versions over top of the old. This time I got "svn: File '/Space Game/.refactorings' is out of date".
So I am in a position where, no matter what i do, I can't commit. At this point I am considering expunging the whole repository and importing from my workspace (something I did when I accidentally deleted the project before, thinking there was a duplicate in the repository.)
I've searched the web for the errors I've had, and all the threads I have found seem to assume a lot more knowledge of version control than I have. Most include bash shell commands, which I don't have access to.
My questions are:
1) Is this the best course of action?
2) Is there another less drastic way to recover?
3) How to I prevent this error from recurring?
I am using Eclipse Indigo with Subversive SVN Connectors 2.2.2, Subversive SVN Team Provider 0.7.9 and SVNKit 1.3.5 Implementation 2.2.2.
This happenend beacuse you checked your eclipse metadata into source control and then moved it by changing those settings.
So first do an update to get the meta files back. If you watch the svn console youl see something like: Restoring FILENAME
After you have them back and assuming your project is still set to put the meta data in a separate folder then you can do an svn delete on them and commit the deletions.
Set up an svn:ignore on all eclipse metadata ie:
.project
.settings
.buildpath
.refactorings
If i were you i would close eclipse and do this all from the command line so it doesnt confused.:
cd /path/to/project/root
svn up
svn rm .project .settings .buildpath .refactorings
svn commit .project .settings .buildpath .refactorings -m "Deleting eclipse metadata."
svn propedit svn:ignore .
# this will open an editor ignored files are one per line so your file should look like
# the following without the "#" signs
#
# .project
# .settings
# .buildpath
# .refactorings
svn commit . -m "Adding ignores to eclipse metadata files."
I use v 3.4.2 of Eclipse and Subversion (using svn 1.4.6 on the server), and I'm having problems understanding the specific options (Depth, Ignore ancestry, etc) and how to merge changes from the trunk into the branch, and back again.
Also, when conflicting changes are present, Subversion seems to break - in the compare editor for the conflicting file, my Local File contains SVN text (e.g. <<<<<<< .working) which obviously don't appear in the actual working copy file. If I go back to my Resource view, I see a whole bunch of SVN temporary files. Is this a bug somewhere, or am I doing something wrong?
The "breakage" as you describe it is the standard way that subversion works - when the merge results in line conflicts, SVN keeps both sides of the conflicts and puts them in the source file for you to review. You have to edit your conflicted file, examine your version of the conflict vs. the repository's version and edit it so that only one set remains (remove the <<<< line, the >>>> line, the ===== line and all the conflicting code lines that you don't want to have). After that right click your source file and choose "mark as merged". following that you can commit your merged file. This is called manual merging and you must complete that when there are conflicts.
The bunch of temporary files are the original source files from either side and they should help you to resolve the conflict - you should have a file ending with ".mine" which is your original clean version of the source file and a file ending with ".rXXXXX" (where XXXX is a subversion revision number) which is the repository's original clean version of the source file. When you "mark as merged" these files will be gone.
Eclipse has a nice graphics tool that you can use to resolve the conflict using a compare style editor, but it has some quirks and it takes some practice and understanding of the tool in order to use it effectively. If you want to try it is available under the file's RMB menu->Team->Edit Conflicts.
I think you'll probably find that those lines such as <<<<< .working do appear in your actual working copy file. This is how Subversion lets you know which parts of your text need to be manually edited because of a merge conflict.
You can read more about merge workflow in the Resolve Conflicts section of the excellent Version Control with Subversion book.
Please note: This is a question about the Eclipse plugin Subversive, and not about Subversion itself. Please do not change the title to be about 'Subversion'.
So I deleted a file that I really shouldn't have.
I've found various approaches to restoring the file outside of Eclipse/Subversive, but I was wondering if there was a best/easiest-to-use/history-restoring way to restore the file using the Subversive tool.
Select the folder in the project that contained the deleted files.
Right click, select Team > Merge...
On the URL tab, set the URL to the server URL for the same folder.
In Revisions, select Revisions and enter a range that includes the deletion, e.g. 1000-1001, or use the Browse button to select them.
In Revisions, enable Reversed merge
Click Preview and check that it shows an Added entry for the files you plan to restore.
Click OK - Eclipse switches to SVN Merge in the Synchronize view.
In the Synchronize view, right click the files you want and select Accept
In the Synchronize view, use the Synchronize SVN icon to switch from SVN Merge to SVN, where you can see the restored file as an outgoing change.
If you have already submitted the remove then it's now time to roll back to the earlier version. In Subversion you do that with "svn merge", where you merge "backwards" from the current to the previous version.
Say you did this:
$ svn rm file.txt
$ svn ci -m "don't need that file"
Committed revision 1325.
Now you want to undo this and restore the old revision 1324, i.e. the state just before the remove (the dot is for 'current directory'):
$ svn merge -r1325:1324 .
If you are unsure you can do a dry-run first, where svn will print the output of the command, but not actually do anything:
$ svn --dry-run merge -r1325:1324 .
The result should indicate that the file is being added (again):
A file.txt
you could switch to revision where this file was exist. Edit/copy this file and switch back to the head revison and commit it here.
Also you could merge changes beetween two revisons - head and last revision file was exist in repository and apply changes to your working copy.
Just "Show History" on the folder, file was existing in. Then click through the history and find the lost file.
I guess you're hoping to not resort to the command line but in case it's useful as a last resort, see this question for how to do it from the command line: What's a simple way to undelete a file in subversion?
Easier: try to commit, Eclipse will show you the dialog with the changed files, click on the one you want to delete with the right button and pick "Revert".
I had a similar issue, I deleted a set of files related to a feature that after a couple of months I want to recover.
The most straightforward solution in my case was to check out in a separate directory the whole project as it was before the file were deleted.
To do this from the Eclipse Repository View go to your project, right click "Check Out As...", in the modal window write the destination folder, select a suitable date of the past in which the deleted file existed (weird, my plugin does not give the possibility to choose a given revision..) and check out.
Now you can easily search, find and copy-paste the files you want to recover.