To do this, youre going to have to start passing more complicated arguments to svn merge. If creating branches from trunk, you cannot have two release branches and keeping the release branches alive with reintegrate When the second release branch is merged to the trunk, the first release branch can no longer be merged to trunk with. Sooner or later, once you get the hang of branching and merging, youre going to have to ask Subversion to merge specific changes from one place to another. You can get it to not barf, by adding a judicious -record-only to the merge that should be a no-op. Im a svnmerge.py user, trying to understand core svn merging. Reintegration handling changed in Subversion 1.8, but the same bug is shown in Subversion 1.6 and 1.7 (good old homebrew). All the individual changes were merged back cherry-pick style, so why is there merge conflict? branching pattern where the trunk contains ongoing development and branches contain releases. But the sync merge seems incompatible with a. The files are identical - there’s nothing to merge. Subversion requires you to do a sync merge from your trunk to a branch, before you can do a reintegrate merge from the branch back to the trunk. Svn: E155015: Aborting commit: '/path/to/subversion_testing/client_data/wc/one/testfile.txt' remains in conflict Svn: E155015: Commit failed (details follow): Svn: E200015: The operation was interrupted Svn: E155027: Unable to resolve conflicts on '/path/to/subversion_testing/client_data/wc/one/testfile.txt' (mc) my side of conflict, (tc) their side of conflict, Select: (p) postpone, (df) show diff, (e) edit file, (m) merge, Its not able to correctly absorb new trunk changes. Recording mergeinfo for merge of r2 through r13 into 'one':Ĭonflict discovered in file 'one/testfile.txt'. Once a -reintegrate merge is done from branch to trunk, the branch is no longer usable for further work.
Mergeinfo, after merge of all the individual commits (out of order)Ĭontents of testfile.txt on branch 'one':Ĭontents of testfile.txt on branch 'two' (they are the same, as a result of merges):Īttempt redundant merge of branch two into branch one (individual commits are merged already, and files at HEAD revision are idential):