How to accept 'theirs-conflict' to resolve tree conflict: Local add, incoming add upon merge

Question

I have come across the following basic Tree conflict: Local add, incoming add upon merge.

I know we can use svn resolve --accept working file to resolve it, but SVN prevent me to use accept their-conflict to accept the incoming version.

Can anyone tell me how to replace my local file by the incoming one? Is it possible using svn resolved file in any way?

Catholicism

One option is to move your local file out of the way, do an svn update, put your file back, and then do an svn commit. Granted it's probably not the "correct" way to do it, but it's probably a lot simpler than playing with the SVN commands. – Berghoff

@aroth, these files are already existed both in trunk and branch (background: I merge the branch to trunk weekly), in fact, I want to use the one in branch to overwrite the one in trunk, as you said, I need to delete these files in trunk, then commit, then merge them from branch, right? – Catholicism

@malenkiy_scot,No,for some history reasons,I didn't verify whether the steps which I indicated are right or not. The tree conflicts are caused by repeating merge, so I deleted the svn:mergeinfo property of the sub directory, let it inherit it's parent one(the correct one), it works in my situation. – Catholicism

Answer 1

The right thing to do is detect this problem in a previous --dry-run and delete the local conflicting dir with svn delete before doing the merge.

First scenario: Working copy with the merge already done. Solution: Delete the working copy, checkout a clean copy and do the right thing.

Second scenario: Already commited wrong directory, after svn resolve --accept=working.

You must svn delete the conflicting directory, and rerun the merge from the parent directory of the conflicting directory ignoring mergeinfo. Revert every object except the previous conflicting directory (now there isn't conflict). Check and commit the changes.

Ex. Working copy un WC folder. Your conflict in A/conflictDir directory:

cd A
svn delete conflictDir
svn merge --ignore-ancestry -rbeginRev:endRev <URLrepo/A>
svn -R revert `ls | grep -v conflictDir`
<... check ...>
svn ci -m "conflictDir fixed"

Colp

Answer 2

I had similar problem, where I svn update a file which has conflict with my local file. I want the remote copy to replace my local copy. What I did is svn delete file_name, and then svn revert file_name. It recovers to the remote copy. I am not sure if the first svn delete is necessary or not.

Herrin

It was for me, deleting the file just with rm caused the conflict to remain, but deleting it with svn delete and then restored it fixed the tree conflict. – Hydrogenous

These conflicts also occur on incoming delete. Then svn revert DIR will delete the directory and the conflict is gone. – Excision

Answer 3

Tree conflict on 'wp-content/plugins/cm-alpha/condensed-back.js'
> local file replace, incoming file edit upon update
Select: (mc) keep affected local moves,
    (r) mark resolved (breaks moves), (p) postpone,
    (q) quit resolution, (h) help: 

After I replied with r

Resolved conflicted state of 'wp-content/plugins/cm-alpha/condensed-back.js'
Summary of conflicts:
Tree conflicts: 0 remaining (and 1 already resolved)

... and it continued on with update

Updating 'wp-content/plugins':
A    wp-content/plugins/cm-jobs/both-ends/php/ajax-prc
U    wp-content/plugins/cm-eats/condensed-front.css
U    wp-content/plugins/cm-eats/condensed-front.min.css
U    wp-content/plugins/cm-estore/condensed-front.css
Updated to revision 304.
At revision 304.

Upon completion I did a 'before' look at the file in question with

ls wp-content/plugins/cm-alpha/condensed-back.js -l
-rwxrwxrwx 1 www-data www-data 793528 Oct 19 21:13 condensed-back.js

I then ran these 2 commands:

sudo svn delete condensed-back.js --force
sudo svn revert condensed-back.js

I then did a 'after' look at the file in question which confirmed it was in fact updated to the latest repo version

ls wp-content/plugins/cm-alpha/condensed-back.js -l
-rwxr-xr-x 1 root root 794427 Oct 25 22:08 condensed-back.js

As you can see the bytesize is different and the date is the most recent date. So this procedure worked as mentioned elsewhere in this post. I just wanted to show it procedurally to take any grey area out of the process.

Floccus