Reputation: 2483
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?
Upvotes: 28
Views: 46517
Reputation: 305
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
Upvotes: 8
Reputation: 661
~/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
Upvotes: 47
Reputation: 18990
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.
Upvotes: 0
Reputation: 3821
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
Upvotes: 8
Reputation: 6768
You can use an other way than the svn resolve command:
Upvotes: 5