How to 'fix' a SVN branch/tree conflict?

Question

I took over a software project and decided to put everything under SVN (on Assembla) using Tortoise SVN. The trunk is under ROOT. So the trunk contained the whole application (w

Answer 1

This answer should help.

Else, do you use a tortoise SVN client 1.6.x? It seems it has problems if the SVN server is less than 1.5.6...

Answer 2

It seems like some changes made at the level of the directory structure on the trunk were not absorbed into the dev branch before attempting the merge back into the trunk. This may have caused the tree conflict in your case.

I found this section of the SVN book very helpful and it contains methods of resolving a situation like yours. Hope this helps. http://svnbook.red-bean.com/nightly/en/svn.tour.treeconflicts.html

[EDIT] ADDITIONAL INFO:

---

Have you already run svn resolved on the workspace where you actually overwrote/resolved the conflicting versions? There may be files/folders still marked "conflicted" on your problematic workspace (the one where you actually performed the merge ) - So once you have looked through those and resolved the conflicts by hand, you can run svn "resolved". I use the subversion command line client for my merges - but I have verified and this option is available on tortoise as well. This should knock off the conflict status and let you proceed. goodluck.

Answer 3

In general, SVN's merging support can only handle using a feature branch once. That is, you work in it and merge changes from trunk into it, and then use svn merge --reintegrate to merge it back into trunk when you're done.

After that, if you want to keep working, you need to create a new branch to work on. I think that you can delete the old one and make a new one in its place without losing data if you want to keep the same repository path, but you may want to try with a test repo first just in case the svn:merge info gets screwy.

This isn't perfect. See this post from when the current merge semantics were introduced for more detailed info.

Also, beware of any use of svn cp or svn mv for purposes other than branch and merge -- if you do this, you'll need to delete the spurious svn:merge properties they create (on both branch and trunk if need be) before running the reintegrate or it will fail will tree conflict messages.

On the whole, svn's branch and merge is still pretty weak compared to the distributed VCS family (git, hg, bzr, darcs, etc), but if you follow these guidelines it does the job.