During a sync merge, if a the merge source has a replacement in the eligible
revisions to be merged, then the merge is split into two parts. For example, in
our own repository we have a feature branch 'multi-layer-moves' copied from
trunk and then a replacement of trunk made to revert an unwanted change:
trunk-->r1239018-->r1243459-->1295003-->r1295004-->r1295006------>
| | | Unwanted ^ |
| | | Change | |
| | | | |
| | | | |
| | +----------------------+ sync
copy sync Replacement merge
| merge to revert |
| | r1295004 |
| | |
| | |
| v v
+---->multi-layer-moves------------------------------->
branch
When we next try to sync the branch with trunk, the replacement cause the merge
to be split into two editor drives, first for trunk -r1243459:1295003, and then
for trunk -r1295003:1296385. This is apparent to the user in the merge output:
>svn merge ^^/subversion/trunk . --accept=theirs-conflict
--- Merging r1243460 through r1295003 into '.':
U get-deps.sh
U Makefile.in
U COMMITTERS
<snip>
U INSTALL
U CHANGES
U autogen.sh
--- Recording mergeinfo for merge of r1243460 through r1295003 into '.':
U .
--- Merging r1295004 through r1296385 into '.':
U notes\subversion-design.html
G subversion\libsvn_fs\fs-loader.c
U subversion\libsvn_subr\cache-inprocess.c
U subversion\libsvn_subr\svn_mutex.c
<snip>
U tools\server-side\svnpubsub\svnpubsub\server.py
U tools\dev\windows-build\Makefile
G CHANGES
--- Recording mergeinfo for merge of r1295004 through r1296385 into '.':
G .
The new mergeinfo recorded to describe this merge does not include
'/subversion/trunk:r1295004-1295005' because those changes were not merged to
the branch (not should they be, since they are not part of
^/subversion/trunk@1296385's history!):
vanilla>svn diff --depth empty
Index: .
===================================================================
--- . (revision 1295172)
+++ . (working copy)
Property changes on: .
___________________________________________________________________
Modified: svn:mergeinfo
Merged /subversion/trunk:r1243460-1295003,1295006-1296385
However, the notifications give the impression that indeed
'/subversion/trunk:r1295004-1295005' was merged and recorded as such:
--- Merging r1295004 through r1296385 into '.':
--- Recording mergeinfo for merge of r1295004 through r1296385 into '.':
Ideally the notifications would correspond with the recorded mergeinfo, and
start at r1295006, like this:
>svn merge ^^/subversion/trunk . --accept=theirs-conflict
--- Merging r1243460 through r1295003 into '.':
U get-deps.sh
U Makefile.in
U COMMITTERS
<snip>
U INSTALL
U CHANGES
U autogen.sh
--- Recording mergeinfo for merge of r1243460 through r1295003 into '.':
U .
--- Merging r1295006 through r1296385 into '.':
U notes\subversion-design.html
G subversion\libsvn_fs\fs-loader.c
U subversion\libsvn_subr\cache-inprocess.c
U subversion\libsvn_subr\svn_mutex.c
<snip>
U tools\server-side\svnpubsub\svnpubsub\server.py
U tools\dev\windows-build\Makefile
G CHANGES
--- Recording mergeinfo for merge of r1295006 through r1296385 into '.':
G .
Bug
Critical