Reading time: 2 – 4 minutes
I’ve written several times about how I recommend avoiding long lived feature branches. But, if you have to use these, you might run into a problem with subversion identifying unmergable tree conflicts. I think this has been fixed in current versions of subversion, but let me walk through a conceptual scenario of what was happening when you get this error message:
Error message:
svn: Attempt to add tree conflict that already exists
svn: Error reading spooled REPORT request response
(Using svn, version 1.6.4 (r38063) compiled Aug 7 2009, 03:47:20)
It starts when you have a branch and a cherry-picked merge from the branch to trunk.
Next, you want to merge all of the branch, to trunk. And you’re using subversion merge tracking.
Subversion really does two merges: one up to the cherry pick, one after the cherry pick.
But, if there were tree conflicts in both the merge before and after the cherry pick, subversion (as of an older version we used last year) would die. I hope this is out of date, and you can avoid the problem with newer versions.
I had to recompile subversion from source, hacking in some special logging and then forcing it to continue after the merge conflict. Read more on the mailing list here and search for jawspeak or paul_hammant. With my patch, it would log a special message, continue, and not die.
Resolve it by manually fixing the tree conflicts (some of these scripts might help you), and mark the conflicts as resolved.
Moral of the story? Use Trunk Based Development, and not feature branches.