tags:

views:

904

answers:

2

Hi, 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?

A: 

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.

Greg Hewgill
Surely Eclipse is smart enough to open it up properly in the Compare Editor - I have junior developers that will panic if they see that!
mbelos
I can't comment on the smartness of Eclipse (I use vim).
Greg Hewgill
Ah ok - yeah it's the Eclipse plugin that's starting to cause me some headaches, although I think I have a workaround happening. Thanks!
mbelos
+2  A: 

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.

Guss
Also do note that Subversive has a bug in the merge dialog - you normally want to merge only the revisions since the last copy (the branching) and subversive should detect that automatically when you choose "stop on copy" in the merge dialog, but due to a bug Subversive will try to merge all revisions. To workaround it try selecting the specific revisions options, click "choose" to show the history dialog and then cancel and go back to "stop on copy" - that should do the trick.
Guss
Yep I was aware of how Subversion works with the .rXXX and .mine, but Eclipse was "breaking" it by actually saving those to my working copy. I'm getting a little closer with selecting the actual revisions in the Merge dialog though, so thanks for pointing that out!
mbelos
Just for reference, I needed to select the '2 URL' tab in the Merge dialog box. Selecting the Head Revisions worked fine...
mbelos
You shouldn't need to use "2 URLs" - You should merge from 1 URL to a working copy of another URL. The conflict resolution files do get stored in your working copy (otherwise how will you access them?) but they will never be committed back to the repository, even if you try to.
Guss