SVN how to resolve new tree conflicts when file is added on two branches

Question

When merging a couple of branches (using SVN 1.6.1) where a file has been added on both branches (and then worked on in those separate branches) I'm getting one of the new tree conflicts:

      C foo.txt
  >   local obstruction, incoming add upon merge

I need the changes from both branches, but the tree conflict doesn't give me the usual .working, .merge-left & .merge-right files -- which is understandable due to the nature of the conflict. There are quite a few of these conflict, and ones where a delete of the same file has occurred on each branch, but they're simple to resolve.

How can I resolve this issue? The SVN redbean book (for 1.6) doesn't cover this situation.

Pelkey

Answer 1

As was mentioned in an older version (2009) of the "Tree Conflict" design document:

XFAIL conflict from merge of add over versioned file

This test does a merge which brings a file addition without history onto an existing versioned file.
This should be a tree conflict on the file of the 'local obstruction, incoming add upon merge' variety. Fixed expectations in r35341.

(This is also called "evil twins" in ClearCase by the way):
a file is created twice (here "added" twice) in two different branches, creating two different histories for two different elements, but with the same name.

The theoretical solution is to manually merge those files (with an external diff tool) in the destination branch 'B2'.

If you still are working on the source branch, the ideal scenario would be to remove that file from the source branch B1, merge back from B2 to B1 in order to make that file visible on B1 (you will then work on the same element).
If a merge back is not possible because merges only occurs from B1 to B2, then a manual merge will be necessary for each B1->B2 merges.

Bink

The "tree conflict" design doc is link rotted :( – Drury

The funny thing is that even if both added files are identical they still show up as conflicting. This should really not be flagged as a conflict. – Seniority

@Seniority So funny I'm dying right now. Dying for my old friend git... – Leprosy

Answer 2

I found a post suggesting a solution for that. It's about to run:

svn resolve --accept working <YourPath>

which will claim the local version files as OK.
You can run it for single file or entire project catalogues.

Spherical

Thanks, this also solves: C foo.txt > local add, incoming add upon update – Alongside

thanks it worked for me as well but i had to do this: svn resolve --accept working FILENAME – Marxist

yeah you need a file name. It accepts '.' (the current directory). I also needed to do this recursively so: "svn resolve --accept working --recursive ." resolves everything in favour of your working copy (dangerous! You may be blowing away other people's changes when you do this, as always when resolving conflicts ) – Gratiana

I use an alias I've created to list all of the tree-conflicted files: alias mtc='stat | awk "BEGIN { FS=\" \" } /^.{6}C/ { print \$NF }"' Then I can use this as the argument to the resolve command, like this: svn resolve --accept working $(mtc) – Donn

In fact you need to specifiy also the resource e.g.: svn resolve --accept working path/index.html – Iorio

I have new file added in feature branch. When I merged it to trunk I get above issue. But it do not add that new file to trunk. If I use --accept working then conflict is resolved. but new file do not show up in trunk. – Congeneric

Answer 3

What if the incoming changes are the ones you want? I'm unable to run svn resolve --accept theirs-full

svn resolve --accept base

Humeral

I think I have misunderstood the question. 'base' is, indeed, equivalent to 'theirs-full' when using 'svn resolve' but it doesn't solve your problem. What I did instead, was to divide it into two parts: 1) Delete my local conflicting directory (or file), 2) Merge. This should run without conflict, and since 'the incoming changes are the ones you want', I wouldn't care about the deleted items – Humeral

Answer 4

I just managed to wedge myself pretty thoroughly trying to follow user619330's advice above. The situation was: (1): I had added some files while working on my initial branch, branch1; (2) I created a new branch, branch2 for further development, branching it off from the trunk and then merging in my changes from branch1 (3) A co-worker had copied my mods from branch1 to his own branch, added further mods, and then merged back to the trunk; (4) I now wanted to merge the latest changes from trunk into my current working branch, branch2. This is with svn 1.6.17.

The merge had tree conflicts with the new files, and I wanted the new version from the trunk where they differed, so from a clean copy of branch2, I did an svn delete of the conflicting files, committed these branch2 changes (thus creating a temporary version of branch2 without the files in question), and then did my merge from the trunk. I did this because I wanted the history to match the trunk version so that I wouldn't have more problems later when trying to merge back to trunk. Merge went fine, I got the trunk version of the files, svn st shows all ok, and then I hit more tree conflicts while trying to commit the changes, between the delete I had done earlier and the add from the merge. Did an svn resolve of the conflicts in favor of my working copy (which now had the trunk version of the files), and got it to commit. All should be good, right?

Well, no. An update of another copy of branch2 resulted in the old version of the files (pre-trunk merge). So now I have two different working copies of branch2, supposedly updated to the same version, with two different versions of the files, and both insisting that they are fully up to date! Checking out a clean copy of branch2 resulted in the old (pre-trunk) version of the files. I manually update these to the trunk version and commit the changes, go back to my first working copy (from which I had submitted the trunk changes originally), try to update it, and now get a checksum error on the files in question. Blow the directory in question away, get a new version via update, and finally I have what should be a good version of branch2 with the trunk changes. I hope. Caveat developer.

Tobias