Can't resolve tree conflict with SVN

Question

I recently encountered a very weird behavior of subversion.

I just merged my local copy of a branch with a remote branch. Everything went smooth, but I've got 1 tree conflict (local delete, remote update).

Okay, thought I, modified the working copy appropriately and ran "svn resolve --accept=working -R .".

Subversion told that it has resolved my problems and "svn st" no longer showed any issues. So, I tried to commit, but svn told me that one of the inner folders (inside my conflicted one) was out of date and suggested to svn up, BUT it made the folder to be in conflict again!

What shall I do to get out of this visious circle?

Hautemarne

might want to review the answers and accept a different answer – Ultravirus

Answer 1

This may or may not help, but sometimes an "svn cleanup" will fix weird metadata issues. If you check out a clean working copy, does the clean copy have the same issue? If so then the previous answer sounds like a step in the right direction

Pitterpatter

Ah, thanks, I ust forgot about cleanup... Need to try this one. – Hautemarne

Answer 2

~/sandbox/jabira > svn resolve  --accept=theirs-full testClient/
svn: warning: Tree conflicts can only be resolved to 'working' state; 'testClient' not resolved

~/sandbox/jabira  > svn resolve  --accept=working testClient/
Resolved conflicted state of 'testClient'

Hope this help

Muscatel

Thanks it helped! I guess it is easy to misinterpret the warning message from svn, that svn is messed up. Actually it is an instruction what to do in this case. – Khartoum

Answer 3

This is what worked for me to abandon all local changes and go with the files from the server repository:

svn update --accept theirs-full

svn resolve --accept theirs-full <pathname>

This message appears: W155027: Tree conflict can only be resolved to 'working'

Unintuitive next step but this actually cuts the catch-22:

svn resolve  --accept=working <pathname>

NOW revert all the "working" changes recursively. This undid all my local changes.

svn revert -R .

Back to normal, with no errors:

svn update

Kami

Answer 4

You can use an other way than the svn resolve command:

1. Create a patch of the conflicted file. (or a backup of your version of the conflicted folder with svn export ...)
2. Update your repository (svn update)
3. Apply the patch previously done (or replace the conflicted file/folder with the backup)
4. Commit the change (svn commit)

Placatory

That's actually what I've end up with :( – Hautemarne

When svn is not working normally, it means that the .svn folder is messed up. Svn cleanup command can help but it never work for me so I am using this method everytime... (sad). Dont forget to mark this post as "accepted answer" if it work (or else this question will still remain as unanswered) – Placatory

Answer 5

You probably didn't have your folders updated when you did the merge, or there was a conflict somewhere before the merge. To fix, you'd have to revert your trunk (target folder) to the previous revision. Then run clean-up on that folder. Then run cleanup on the branch folder (source folder). Then update both folders again. If you're getting lines in red in any workflow, then you need to revert those files first, then get them into the state that you want them in. Then update the folders (yes, once again). Finally perform the merge again.

Workshop