svn merge functionality broken by tree conflicts

43,393

Solution 1

The problem turned out to be that I had chosen the parent/ directory as the source of the merge instead of the parent/trunk/ directory. It was user error, but the tree conflict message is confusing. If svn had just gone ahead and done the merge I would have seen the problem instantly.

Tree conflicts have introduced new message semantics that will take some getting used to.

Thanks for the pointer to the Tortoise documentation on Tree Conflicts. It is the only documentation I've seen that addresses working on branches. The example given doesn't explain why I got tree conflicts on the files I had modified on the branch, however. The tree conflict messages are going to take some getting used to.

It looks like all you do in most cases is mark the tree conflicts resolved, and in these cases it looks like tree conflicts are just noise.

Mark Phippard says that an older server version won't cause tree conflicts. The server only needs to be updated if you want merge tracking support and your server is pre-1.5. Apparently merge tracking is the only thing missing from older svn servers:

http://eclipse.open.collab.net/ds/viewMessage.do?dsForumId=62&dsMessageId=332448

Solution 2

svn: Attempt to add tree conflict that already exists

Subversion is complaining because after you did a merge which generated a conflict, you then did the same merge again. SVN tried to add a conflict but noticed that the conflict has already been created by the previous merge operation. So it correctly outputs a warning.

If you do a merge operation and you are not happy with the result, then before trying something else you should first revert the local changes.

As for the original tree conflict: to understand why the behaviour is different from the older clients and how to resolve such conflicts, you must read the section on tree conflicts in the svn book. The tortoiseSVN manual also has a good topic on tree conflicts.

Solution 3

I have a wild guess that you are observing a bad interaction between the 1.6 client and the 1.3 server. The tree conflict detection is a new feature of 1.6. Also, the merge support has been changed at 1.5 (and made much more usable then).

I'd try upgrading the server and repo format to 1.6, another thing to try is to use a 1.5 (no tree conflicts) or a 1.4 (and no new merge neither) client.

Again, this is all a guess and might not be really useful...

Share:
43,393
Dean Schulze
Author by

Dean Schulze

Updated on March 17, 2020

Comments

  • Dean Schulze
    Dean Schulze about 4 years

    I don't know when the svn team decided to inflict tree conflicts on us but it has completely broken the merge functionality of svn.

    I have a branch and I want to merge the latest changes from the trunk into the branch. I've already done one such merge, but this one fails because of a tree conflict. Here's the command:

    $ svn --force merge -r 3185:3192 svn://chamar2/rx-services/SAMS .
    svn: Attempt to add tree conflict that already exists
    

    The first time I tried this merge (without the --force) it only created the tree conflict and did not merge anything. Now it just reports the message above.

    If I do svn status on the branch working copy it shows all the files that have changes that have not been merged back to the trunk yet. Of course, the purpose of my branch is to do these changes where they are not yet in the trunk.

    What were they thinking when they did this?

    I haven't found any usable information on what causes tree conflicts and how I can continue to work now that svn has created these things.

    Is there a way to tell svn to forget about tree conflicts and just do the merge like it used to?

    I'm using a 1.6 client and an older svn server (probably 1.3.1).