On Thu, Feb 06, 2020 at 03:37:10PM -0500, Daniel Dickison wrote:
> Strangely, the conflict goes away if you flip the order of steps 2 and 3,
> or commit the merge from step 4 first.
I would say it is working as designed, but the design has its flaws.
As you have found out, the basic problem is that unlike when developers
work on the same branch, SVN does not enforce an 'svn update' style
operation when merges and commits interleave.
This is indeed a problem but it is not easy to fix in SVN itself.
If this happens to your team a lot you might want to let your developers
know about the issue and show them how to work around it.
An easy way to work around it is the following, which essentially
simulates the missing 'svn update' style step. After a merge, and
before committing this merge, if the other branch has new changes
which were not yet merged, merge those changes as follows to "catch up":
svn merge -r0:HEAD ^/the/other/branch
Patch for your script:
--- merge-interleave-3.sh Fri Feb 7 08:19:28 2020
+++ merge-interleave-4.sh Fri Feb 7 08:29:59 2020
@@ -111,6 +111,7 @@
${SVN} merge ${URL}/branches/branch1 wc # Step 5
${SVN} pl -v -R wc
${SVN} commit wc -m 'Merge branch1 into trunk' # Step 6
+${SVN} merge -r0:HEAD ${URL}/trunk wcb
${SVN} commit wcb -m 'Merge trunk into branch1' # Step 7
# Step 8. edit A/mu one more time in trunk.
Note that I'm using -r0:HEAD to force a "sync merge" at that point.
Once the merge to the other branch has been committed, Subversion will
try to run the 'reintegrate' strategy which will refuse to operate on
a working copy which already contains local modifications.
To understand why your problem is happening, look at the generated mergeinfo.
With your script, the mergeinfo generated by the merge into 'wc' lacks r5:
Properties on 'wcb':
svn:mergeinfo
/trunk:2-4
Properties on 'wc':
svn:mergeinfo
/branches/branch1:2-4
As you point out, when merges and commits are done sequentually it works
as expected. Mergeinfo contains this instead:
Properties on 'wcb':
svn:mergeinfo
/trunk:2-4
Properties on 'wc':
svn:mergeinfo
/branches/branch1:2-5
r5 is the revision which records the merge from trunk to the branch.
Without r5 in trunk's mergeinfo, 'svn merge' will pick a merge strategy
that includes r5, which includes 'Edit 1'.
Which is why I see no way to fix this in SVN itself.
If we made SVN record r5 during the original merge (before r5 existed),
that would be wrong.
And if we made SVN skip A/mu edits from r5 during the conflicting merge,
that would be wrong, too.
So to me it looks like this needs to be handled by synchronizing
your developers. Sorry :-/
$ svn log -r5 --diff ^/
[...]
Index: branches/branch1/A/mu
===================================================================
--- branches/branch1/A/mu (revision 4)
+++ branches/branch1/A/mu (revision 5)
@@ -1 +1 @@
-This is the file 'A/mu'.
+Edit 1 of A/mu in trunk
Index: branches/branch1
===================================================================
--- branches/branch1 (revision 4)
+++ branches/branch1 (revision 5)
Property changes on: branches/branch1
___________________________________________________________________
Added: svn:mergeinfo
## -0,0 +0,1 ##
Merged /trunk:r2-4
------------------------------------------------------------------------
Received on 2020-02-07 08:44:35 CET