96

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.

DEfusion
  • 5,533
  • 5
  • 44
  • 60

4 Answers4

167

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.

MarmiK
  • 5,639
  • 6
  • 40
  • 49
lukmdo
  • 7,489
  • 5
  • 30
  • 23
  • 2
    Thanks, this also solves: C foo.txt > local add, incoming add upon update – lazysoundsystem Jul 09 '10 at 20:25
  • 6
    thanks it worked for me as well but i had to do this: svn resolve --accept working FILENAME – ajacian81 Nov 20 '10 at 21:47
  • 5
    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 ) – Harry Wood Jul 06 '11 at 11:46
  • 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)` – Earl Jenkins Oct 25 '12 at 17:47
  • 1
    In fact you need to specifiy also the resource e.g.: `svn resolve --accept working path/index.html` – Tomasz Kuter Sep 06 '13 at 13:43
  • 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. – Durgaprasad Oct 24 '17 at 05:30
40

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.

Community
  • 1
  • 1
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
9

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

svn resolve --accept base

Gabriel F. T. Gomes
  • 101
  • 1
  • 6
  • 5
    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 – Gabriel F. T. Gomes Feb 23 '11 at 08:41
3

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.

dewtell
  • 1,402
  • 10
  • 14