Menu
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.
719
The only way to resolve a tree conflict via Subversion is to accept the current state of the working copy. Thus, if the local version of a file or folder is not the preferred one, the Revert command should be run on it.
Merging ranges of revisionsEdit To merge a range of revisions, use svn merge -r start:end from to where start and end are revision IDs. This will merge all revisions starting at start+1 up to and INCLUDING end . Note: it will NOT include the first revision (ex: -r3:45 will merge 4 through 45).
To resolve a conflict do one of three things: Merge the conflicted text by hand (by examining and editing the conflict markers within the file). Copy one of the temporary files on top of the working file. Run svn revert FILENAME to throw away all of the local changes.
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.
147
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.
29
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
