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.

Scarify

Can you give a recipe to reproduce this problem starting from an empty repository? – Krever

I will try and find some time today to make a new repo and test this out and get the same results and post back. Thanks. – Scarify

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

Asco

In this way you are suggesting to svn to resolve the conflict (--resolve), accepting the working copy inside your sandbox (--accept working), recursively (-R), starting fron the current directory (.) HTH – Asco

in TortoiseSvn, selecting "Resolved" on right click, actually resolves this issue. – Webfoot

I can confirm it works: Right-click the problematic folder in Windows Explorer (if you're using Windows)->choose TortoiseSvn->Resolved. Thanks a lot understack. – Disposable

does this not blindly just accept the working copy? I mean I feel like I can't tell where issues exist with these conflicts, but if I just resolve and accept working will it not just erase other people's work? – Buddhology

Resolving tree conflict caused by 'svn switch' is dangerous. The sever code may be cover with local file after committing. – Sonneteer

The only addition to make is if you don't want that to apply to your current directory, is specifying a directory name by appending it ...--accept working -R dir/to_resolve/conflict – Schismatic

One cause of this happening could be that you svn rm'd a directory that you thought was no longer needed, but somebody else added a new file that is needed. When you update your working copy you should get a tree conflict. If you just blindly accept your solution (deleting the directory) then you'll be removing that person's file. There is no magic "do the right thing" button. You have to understand what it is that you're doing, why that conflicted with the latest version, and how to properly resolve it. – Spinthariscope

@bamccaig in my answer I suggested to read the manual to understand what's happening as a first statement. A lot of people (like me when I found out the answer) need to solve the dir removal problem so I gave a quick solution for that and it seems to be helpful. I never suggested anyone to avoid thinking like "just do like me" so I can't see your point here. – Asco

I just added a bold to the statement "committing your working dir" in order to emphasize that... you will commit your working dir :) and hopefully avoid mistakes. – Asco

If I do this, it won't change anything anybody else is working on, right? I just want to be up to date, I don't want to change anything for others. – Lenient

Doing this it will commit YOUR working directory specified (if you use . it means the current one) on the server repository regardless to why the conflict has been generated so please be careful. With svn is easy to generate a conflict with your own changes: in that case you can use this way without caring too much. – Asco

@JessTelford, I'm not sure about your statement, the question is "Is there any way to avoid this in the future?", not "How can I hide the symptom?". Am I the only one wanting to understand and avoid problems, instead of sweeping them under the rug? – Customer

@TWiStErRob, I'd argue this symptom is indicative of issues inherent in SVN as a version control tool. Personally, the way to 'avoid' this issue in the future would be to use git. Since that is most likely not a practical option for the asker, then dealing with the situation as this answer describes is the best option. – Confidential

Its a problem for git too, if someone deletes a folder that you want to add a file to, what can git do? answer: nothing useful, it requires human intervention to say "this is what we meant", which is nothing svn, git or any other SCM can decide for itself. – Sadie

I did this, and I presume I must have mistakenly done it while the files in question were absent. Now they are missing, and NOTHING I do seems to bring them back. Re-do with --accept theirs-full: nope; svn revert: nope. rm -rf the directory they're in and svn update it back: nope. I know, I could read the manual letter-by-letter and climb an enormous learning curve to understand what's actually going on but it's easier to nuke the WHOLE repo and check it out again, which in the end was the only thing that worked. This feature is a landmine. Mercurial all the way from now on. – Clog

I tried to emphasise as much as I could that using this command you are *committing your workdir" as it is (without files in your case). I'll try to state it even more clearly. Luckily enough SVN has the duty to remember each file we committed so it's been possible to recover them. – Asco

@Sadie No, git isn't as retarded as subversion, there's no such thing as tree conflict for git. – Myrilla

@Myrilla are you quite sure about that, they may call it something different but merging folder changes can be impossible for an algorithm to work out. – Sadie

@Sadie I've just used a temp local git repo to merge my SVN tree conflicts. – Myrilla

never. Don't resolve an issue by sticking your head into the sand. This is what accepting conflicts is. – Yawn

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

Camala

Neither of these examples you give pertain to my situation. Perhaps my description is not clear? – Scarify

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

Oriflamme

Same problem from the SVN command-line client, so it's not Eclipse. – Stonewort

I have the same problem with NetBeans and SVN. Delete directory -> conflict. – Disposable

Same problem here... very very annoying... have to REVERT, update, delete and commit... – Backwardation

I discovered a great trick with IntelliJ Idea when I get tree conflicts. I shelf all my changes (this is the same as creating a patch of my changes and then rolling them back). Then I do a svn update to get the latest changes from Subversion. After that I un-shelf my changes (same as applying the patch) and viola! – Esposito

I seem to have the same issue using svn client 1.7.9 on Ubuntu 12.04.4 LTS against Assembla repos. – Eddaeddana

Had the same issue, which was solved for me when updating to svn server >= 1.9.5. Refer to its change log. – Diarmuid

I have somewhat opposite problem. Whenever svn update gets new added file, it shows up as conflict and not just simple addition. I don't even know how to get around this issue other than manually reverting added files. – Azaria

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

Zeeba

For people looking at this, if you right click in some-branch sources to check in your changes, then try to merge in the parent folder in trunk you will see this. To resolve it, go to the sources folder in your trunk folder and merge to that. – Hero

Answer 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

Secretariat

Downvoted because --reintegrate option has been deprecated in Subversion 1.8. Beginning with SVN 1.8 such kind of merges are automatic! – Tribadism

Upvoted because a lot of people still use subversion<1.8 – Browse

I think adding SVN version information to the answer would be in order. – Lesialesion

1.8 here and it wouldn't work without this solution. – Myrilla

Upvoted because this answers the question as to why this happens. – Josselyn

This poor management from the client is a disgrace: it is an algo for God's sake, and the human shouldn't need to remove any rebased file to make it happy. Can't the client notice that we're talking about the same file on both trunk and the branch, and it could just skip it, instead of complaining that it is in the way? See my resolution further down. – Yawn

Answer 6

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

Incidentally

Answer 7

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.

Yawn

Answer 8

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.

Seaton

Answer 9

I came across this problem today as well, though my particular issue probably isn't related to yours. After inspecting the list of files, I realized what I had done -- I had temporarily been using a file in one assembly from another assembly. I have made lots of changes to it and didn't want to orphan the SVN history, so in my branch I had moved the file over from the other assembly's folder. This isn't tracked by SVN, so it just looks like the file is deleted and then re-added. This ends up causing a tree conflict.

I resolved the problem by moving the file back, committing, and then merging my branch. Then I moved the file back afterward. :) That seemed to do the trick.

Gaunt

Answer 10

I had a similar problem. The only thing that actually worked for me was to delete the conflicted subdirectories with:

svn delete --force ./SUB_DIR_NAME

Then copy them again from another root directory in the working copy that has them with:

svn copy ROOT_DIR_NAME/SUB_DIR_NAME

Then do

svn cleanup

and

svn add *

You might get warnings with the last one, but just ignore them and finally

svn ci .

Kaleb

Answer 11

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.

Salpingotomy

History is why we use VCSs... or am I missing something? – Customer

Answer 12

A scenario which I sometimes run into:

Assume you have a trunk, from which you created a release branch. After some changes on trunk (in particular creating "some-dir" directory), you create a feature/fix branch which you want later merge into release branch as well (because changes were small enough and the feature/fix is important for release).

trunk -- ... -- create "some-dir" -- ...
     \                                  \-feature/fix branch
      \- release branch

If you then try to merge the feature/fix branch directly into the release branch you will get a tree conflict (even though the directory did not even exist in feature/fix branch):

svn status
!     C some-dir
      >   local missing or deleted or moved away, incoming file edit upon merge

So you need to explicitly merge the commits which were done on trunk before creating feature/fix branch which created the "some-dir" directory before merging the feature/fix branch.

I often forget that as that is not necessary in git.

Seyler