views:

7233

answers:

5

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).

Thanks.

Dean

A: 

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...

Laurynas Biveinis
I'd thought about downgrading my client back to 1.5, but svn has this nasty habit of changing the working copy format with each new version and my 1.6 working copy will not work with a 1.5 client. I may have to downgrade the client and do a new checkout.
Dean Schulze
+4  A: 

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.

Wim Coenen
I just had "Attempt to add tree conflict that already exists" doing a brand new merge.Followed by "Error reading spooled REPORT request response"
fiddlesticks
-1 : I get this error on a fresh merge with no previous merges. I believe it is two tree conflicts in the same merge causing the issue.
darreljnz
+5  A: 

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
Dean Schulze
tree conflicts: think of a directory as a text file with each subdir as a line. Now, add and delete lines from that file and merge - you'll get a conflict. This is exactly what's happening with tree conflicts, its just that the merge editor is non-existent (obviously as the answer is to copy dirs to the right place and mark as resolved).
gbjbaanb
+1  A: 

I'm facing the same issue: svn: Attempt to add tree conflict that already exists

After such a message I then resolve all the conflicts with 'svn resolve --accept', and commit. So I get a clean svn status report.

Then I relaunch the merge command to be able to finish it, and svn goes trough exactly the same process as in the previous merge and all the conflicts I did solve reappear.

This drives me crazy, I can't merge!

Subversion isprobably right, but then I don't understand how I could better solve the conflicts than by using svn resolve.

help very welcome!!

/nodje

+1  A: 

Same problem here "Attempt to add tree conflict that already exists" - after resolving conflicts svn complains again about the same files with another merging attempt. This effectively blocks any merges. This is driving me nuts!

calder
This seems to be a known issue of sorts in Subversion, which looks like it should have been fixed back in June last year: http://svn.haxx.se/dev/archive-2009-06/0178.shtmlHowever, I can't see it mentioned in any of the release change notes: http://svn.apache.org/repos/asf/subversion/tags/1.6.11/CHANGESSo I'm wondering whether it ever got released...
zcrar70