How to 'fix' a SVN branch/tree conflict?_问答_开发者

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 (which I tagged 1.0). For my first big feature I created a feature branch named "dev".

I could merge changes in the trunk branch into the dev branch without problem (as I was doing small bug fixes). Once my feature was complete, I did a merge back into the trunk branch. Everything was working fin up to this point. The new code under ROOT showed the new feature properly. But then I did a commit (of the result of the merge) and now every time I try to do a merge from the root or from the dev branch, SVN complains about "tree conflict" on many files. Even files that I did not touch since the merge. I tried to resolve the conflicts, without success.

I'm the only developer, so I don't really care about major changes to the repository. But I still want to keep the history of all files if it's possible.

What would be the best way to fix this issue? Is there a w开发者_运维技巧ay I could tag all the latest files in the ROOT trunk as the "definite" version of the file?

[EDIT] More information

Yes, 'main' and 'trunk' is the same thing. I have clarified my question
When you merged back from the feature branch, did you first do another merge from the trunk to aborb the latest trunk changes?" Yes. The trunk was up-to-date. And the dev branch had all the changes from the trunk.
"everything got screwed up on committing": What I meant was that the commit was fine, but then as soon as I started doing merge from the trunk/to the trunk, SVN complains about 'Tree conflicts'.
I have over 200 tree conflicts. So what I'm looking for is a "accept all" command

[EDIT] elhoim solution did not fix my problem. However, he was right with SVN version issues. Currently (2009-10-28), Assembla is using SVN v1.5.1 and my tortoiseSVN was v1.6. So that was the reason I was having so much tree conflict. I tried using the solution as provided by elhoim's link and it did not work (I tried a bunch of merge multiple times before trying the HEAD-to-HEAD merge. Some files didn't carry over to the root branch because of that).

Seeing that an HEAD-to-HEAD merge would still not work, I decided to simply delete all ".svn" files in my branch folder, copy the files into the ROOT folder and do a commit.

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

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.

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.