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 down into the trunk and any of the files that were added to my trunk after the creation of my branch were flagged as a "tree conflict". Is there a way to avoid this in the future?

I don't think these are being properly flagged.

Solution 1

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.

Solution 2

Subversion 1.6 added Tree Conflicts to cover conflicts at the directory level. A good example would be when you locally delete a file then an update tries to bring a text change down on that file. Another is when you you have a subversion Rename of a file you are editing since that is an Add/Delete action.

CollabNet's Subversion Blog has a great article on Tree Conflicts.

Solution 3

In my experience, SVN creates a tree conflict WHENEVER I delete a folder. There appears to be no reason.

I'm the only one working on my code -> delete a directory -> commit -> conflict!

I can't wait to switch to Git.

I should clarify - I use Subclipse. That's probably the problem! Again, I can't wait to switch...

Solution 4

I don't know if this is happening to you, but sometimes I choose the wrong directory to merge and I get this error even though all the files appear completely fine.

Example:

Merge /svn/Project/branches/some-branch/Sources to /svn/Project/trunk ---> Tree conflict

Merge /svn/Project/branches/some-branch to /svn/Project/trunk ---> OK

This might be a stupid mistake, but it's not always obvious because you think it's something more complicated.

Solution 5

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

View more solutions