Given two branches:
-A---@yca---------------------------@rN----------->
| | | | | | ^
copy subtree-and-cherrypick-merges |
| | | | | | reintegrate
| | | | | | merge
V V V V V V |
---B---------------------------------------->
Ever since 1.7.0, --reintegrate merges from 'B' to 'A' are allowed to proceed if
the previous merges from 'A' to 'B' have effectively synced all operative
changes between A@yca and A@N. Even if these previous merges were made up of
cherrypicks and subtree merges that left fragmented mergeinfo from ^/A on B, as
long as these gaps represented inoperative changes on ^/A the reintegrate merge
worked. See issue #3577 for more details.
With the forthcoming 1.8 release the above behavior is still present if we use
the deprecated --reintegrate option. If however, we let the new automatic merge
logic determine whether to use a 'sync' style or 'reintegrate' style merge, then
the automatic merge uses the former, even if the mergeinfo gaps are inoperative.
This can result in spurious conflicts as has already been noted in our own
repository: http://svn.haxx.se/dev/archive-2013-02/0459.shtml
Here is a simple example (starting with a vanilla Greek test tree:
>svn copy ^^/A ^^/B -m "Branch 'A' from 'B'."
Committed revision 2.
>echo trunk edit > A\mu
>svn ci -m "trunk edit"
Sending A\mu
Transmitting file data .
Committed revision 3.
>svn up -q
>echo branch edit > B\D\H\psi
>svn ci -m "branch edit"
Sending B\D\H\psi
Transmitting file data .
Committed revision 4.
>svn up -q
>svn merge ^^/A B --show-revs eligible
Subcommand 'merge' doesn't accept option '--show-revs ARG'
Type 'svn help merge' for usage.
>svn mergeinfo ^^/A B --show-revs eligible
r3
>svn merge ^^/A B -c3
--- Merging r3 into 'B':
U B\mu
--- Recording mergeinfo for merge of r3 into 'B':
U B
>svn ci -m "Effectively sync B with A via a cherrypick merge."
Sending B
Sending B\mu
Transmitting file data .
Committed revision 5.
>echo Yet another trunk edit > A\mu
>svn ci -m "Another trunk edit."
Sending A\mu
Transmitting file data .
Committed revision 6.
>svn up -q
### Explicitly requesting a reintegrate merge still works as
### Subversion determines that B is synced with A through r3
### and the merge is ^A@3 ^B@6:
>svn merge ^^/B A --reintegrate
--- Merging differences between repository URLs into 'A':
U A\D\H\psi
--- Recording mergeinfo for merge between repository URLs into 'A':
U A
>svn diff
Index: A/D/H/psi
===================================================================
--- A/D/H/psi (revision 6)
+++ A/D/H/psi (working copy)
@@ -1 +1 @@
-This is the file 'psi'.
+branch edit
Index: A
===================================================================
--- A (revision 6)
+++ A (working copy)
Property changes on: A
___________________________________________________________________
Added: svn:mergeinfo
Merged /B:r2-6
### But an automatic merge, based a naive reading of the mergeinfo
### tries to merge ^A@1 ^B@6, resulting in a conflict:
>svn revert -Rq .
>svn merge ^^/B A
--- Merging r2 through r6 into 'A':
C A\mu
U A\D\H\psi
--- Recording mergeinfo for merge of r2 through r6 into 'A':
U A
Summary of conflicts:
Text conflicts: 1
Conflict discovered in file 'A\mu'.
Select: (p) postpone, (df) diff-full, (e) edit, (m) merge,
(mc) mine-conflict, (tc) theirs-conflict, (s) show all options: p
Bug
Critical