svn merge functionality broken by tree conflicts

Question

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

Childish

SVN didn't add tree conflicts as a feature; they are intrinsic to the nature of revision control. Now, you could make the point that SVN does a poor job handling and/or messaging about tree conflicts, but at least it DOES detect them and tries to let you know what's going on. – Assembled

Answer 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

Childish

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

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

Hopfinger

I just had "Attempt to add tree conflict that already exists" doing a brand new merge. Followed by "Error reading spooled REPORT request response" – Bigamous

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

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

Siskind

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

Answer 4

Hey Guys I had exactly the same issue, tree conflicts when I was trying to do a svn merge. It turns out Laurynas was absolutely correct. It was occurring because the svn repository was an old version. On the server I went into the directory {repopath}\db\format and inside the format file it contained "2".

All I did was do a

svnadmin upgrade {repopath}

which was pretty painless.

After I did that, when I tried to use merge tracking, I didn't get any more tree conflicts! Thanks for the tip!

Mulciber