Why am I getting tree conflicts in Subversion?

Question

I had a feature branch of my trunk and was merging changes from my trunk into my branch periodically and everything was working fine. Today I went to merge the branch back d

Answer 1

What's happening here is the following: You create a new file on your trunk, then you merge it into your branch. In the merge commit this file will be created in your branch also.

When you merge your branch back into the trunk, SVN tries to do the same again: It sees that a file was created in your branch, and tries to create it in your trunk in the merge commit, but it already exists! This creates a tree conflict.

The way to avoid this, is to do a special merge, a reintegration. You can achieve this with the --reintegrate switch.

You can read about this in the documentation: http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate

When merging your branch back to the trunk, however, the underlying mathematics are quite different. Your feature branch is now a mishmash of both duplicated trunk changes and private branch changes, so there's no simple contiguous range of revisions to copy over. By specifying the --reintegrate option, you're asking Subversion to carefully replicate only those changes unique to your branch. (And in fact, it does this by comparing the latest trunk tree with the latest branch tree: the resulting difference is exactly your branch changes!)

After reintegrating a branch it is highly advisable to remove it, otherwise you will keep getting treeconflicts whenever you merge in the other direction: from the trunk to your branch. (For exactly the same reason as described before.)

There is a way around this too, but I never tried it. You can read it in this post: Subversion branch reintegration in v1.6

Answer 2

Until today, for since at least 3 months ago, I regularly encountered hundreds of tree conflicts when attempting to merge a branch back into the trunk (using TortoiseSVN 1.11). Whether rebased or not, BTW. I've been using TortoiseSVN since its v1, back in 2004, and I used to reintegrate branches all the time. Something must have happened recently I suppose?

So today I ran this simple experiment, and I found what was creating these crazy conflicts:

1. I forked off the trunk @393;
2. I modified tens of files randomly, as well as creating new ones;
3. I committed. Now @395 (a colleague forked off at 394 to perform his own stuff).
4. Then I tried to reintegrate the branch back into the trunk, test only; following TortoiseSVN's recommendation in the wizard: "to merge all revisions (reintegrate), leave that box empty". To achieve this, I right-clicked onto the trunk folder, and chose "TortoiseSVN > Merge, from /path/to/branch", and I left the rev range empty, as advised on the dialog.

Discussion: (see attachment)

all revisions... of what? Little did I know that the client must have been referring to "all revisions of the target! (trunk)", as, in the process of reintegrating that branch, I saw the mention "Merging revisions 1-HEAD"! OMG. Poor Devil, you're falling to your death here. That branch was born @393, can't you read its birth certificate, for God's sake?

Resolution:

1. Contrarily to what's advised by the wiz, do specify a range, that covers ALL revisions of...the branch's life! therefore, 394-HEAD;
2. now run that merge test again, and get a cigar. ().

Moral: I can't comprehend why they still haven't fixed that bug, because it is one, I'm sorry. I should take the time to report this with them.

Answer 3

This can be caused by not using the same version clients all over.

Using a version 1.5 client and a version 1.6 client towards the same repository can create this kind of problem. (I was just bitten myself.)

Answer 4

If you encounter tree conflicts which do not make sense because you didn't edit/delete/come anywhere near the file, there is also a good chance that there was an error in the merge command.

What can happen is that you previously already merged a bunch of the changes you are including in your current merge. For instance, in trunk someone edited a file, and then later renames it. If in your first merge you include the edit, and then in a second merge include both the edit and the rename (essentially a remove), it will also give you a tree conflict. The reason for this is that the previously merged edit then appears as your own, and thus the remove will not be performed automatically.

This can occur on 1.4 repositories at least, I'm not sure whether the mergetracking introduced in 1.5 helps here.

Answer 5

I had this same problem, and resolved it by re-doing the merge using these instructions. Basically, it uses SVN's "2-URL merge" to update trunk to the current state of your branch, without bothering so much about history and tree conflicts. Saved me from manually fixing 114 tree conflicts.

I'm not sure if it preserves history as well as one would like, but it was worth it in my case.

Answer 6

I found the solution reading the link that Gary gave (and I suggest to follow this way).

Summarizing to resolve the tree conflict committing your working directory with SVN client 1.6.x you can use:

svn resolve --accept working -R .

where . is the directory in conflict.

WARNING: "Committing your working directory" means that your sandbox structure will be the one you are committing, so if, for instance, you deleted some file from your sandbox they will be deleted from the repository too. This applies only to the conflicted directory.

In this way, we are suggesting SVN to resolve the conflict (--resolve), accepting the working copy inside your sandbox (--accept working), recursively (-R), starting from the current directory (.).

In TortoiseSVN, selecting "Resolved" on right click, actually resolves this issue.