Prior to 1.5.5, the merge --reintegrate option would not work if the merge
source had any subtree mergeinfo.
In 1.5.5 (http://svn.apache.org/viewvc?view=revision&revision=874165) we made
improvements that allowed reintegrate merges in that case so long as the subtree
mergeinfo on the source reflected that the same ranges were previously merged
from the target to the source across the entire source tree, e.g.:
1) Start with a /trunk with explicit subtree mergeino
2) copy /trunk to /branches/b1
3) Work continues on /trunk and /branches/b1
4) sync merge all available revisions from /trunk to /branches/b1
5) Reintegrate /branches/b1 back to /trunk.
These improvements assumed that all the sync merging previously done to the
branch was at the *root* of the branch and that all subtrees' mergeinfo was
updated, regardless of whether the subtree was affected by the merge.
In http://svn.apache.org/viewvc?view=revision&revision=878767 "unrelated"
improvements were made such that when a merge is performed, only subtrees
affected by the merge have their mergeinfo updated. This was not backported but
will be part of 1.7.
The reintegrate logic needs to take this new behavior into account. In the
above use case in step 4, the sync merges no longer record mergeinfo on every
subtree without exception; if the subtree is unaffected its mergeinfo is not
altered. So when the reintegrate merge is attempted in step 5, an error will
occur, because based strictly on the source's mergeinfo, it appears that the
source is not completely synced up with the target.
fyi, the error will look something like this:
C:\SVN\trunk-wc>svn merge ^^/branches/feature-branch-3 . --reintegrate
..\..\..\subversion\svn\merge-cmd.c:358: (apr_err=195016)
..\..\..\subversion\libsvn_client\merge.c:9416: (apr_err=195016)
svn: Reintegrate can only be used if revisions 40491 through 40561 were
previously merged from svn:///S.T.O.MIRROR/trunk to the reintegrate source, but
this is
not the case:
branches/feature-branch-3
Missing ranges: /trunk:40491-40493,40543-40544
branches/feature-branch-3/subversion
Missing ranges: /trunk/subversion:40491-40492,40543-40544
branches/feature-branch-3/subversion/bindings/javahl
Missing ranges: /trunk/subversion/bindings/javahl:40491-40492,40543
branches/feature-branch-3/subversion/svn
Missing ranges: /trunk/subversion/svn:40491,40543-40544
branches/feature-branch-3/subversion/svn/conflict-callbacks.c
Missing ranges: /trunk/subversion/svn/conflict-callbacks.c:40543-40544
branches/feature-branch-3/subversion/tests/cmdline/patch_tests.py
Missing ranges: /trunk/subversion/tests/cmdline/patch_tests.py:40491-40492,40544
It would be desirable to improve the reintegrate logic so that it can determine
if the "missing" sync merges are inoperative. If that is the case, it can
safely allow the reintegrate merge to proceed. This will also allow the use
case where all the "sync" merges are done as subtree merges, but effectively all
the changes have been merged from trunk to the branch.
If we don't do this, reintegrate will return to its pre 1.5.5 status of being
largely useless when dealing with subtree mergeinfo. Users will be left only
with the two-URL merge "workaround", which works perfectly well, but for better
or worse, people like the simplicity that --reintegrate offers.
Bug
Major