On Mon, 08 Oct 2007, Paul Burba wrote:
...
> Let's say we have the following WC, just a greek tree with a copy of the
> 'A' dir at r2 followed by some simple text mods to some of the files
> under A in subsequent revisions:
...
> # Resultant mergeinfo looks good
> >svn pl -vR merge_tests-1
> Properties on 'merge_tests-1\A_COPY':
> svn:mergeinfo : /A:1,4-8
> Properties on 'merge_tests-1\A_COPY\D':
> svn:mergeinfo : /A/D:1,6
>
> === EXAMPLE 1 ==============================================
...
> >svn merge -r2:6 %URL%/A merge_tests-1\A_COPY
> --- Merging r3 into 'merge_tests-1\A_COPY':
> U merge_tests-1\A_COPY\D\H\psi
> --- Merging r4 through r5 into 'merge_tests-1\A_COPY':
> U merge_tests-1\A_COPY\D\G\rho
>
> >svn pl -vR merge_tests-1
> Properties on 'merge_tests-1\A_COPY':
> svn:mergeinfo : /A:1,3-8
> Properties on 'merge_tests-1\A_COPY\D':
> svn:mergeinfo : /A/D:1,3-6
>
> === EXAMPLE 2 ==============================================
>
> # ...Now revert the previous merge and try another.
> # This time revision 6 *is* mentioned in the
> # notification, even though it is *not* being
> # applied. Shouldn't the notification instead be
> # "--- Merging r7 through r10 into 'merge_tests-1\A_COPY':"?
> # ^^
> >svn merge -r5:10 %URL%/A merge_tests-1\A_COPY
> --- Merging r6 through r10 into 'merge_tests-1\A_COPY':
> U merge_tests-1\A_COPY\D\G\pi
> U merge_tests-1\A_COPY\D\G\tau
> U merge_tests-1\A_COPY\D\H\chi
Yup, we shouldn't apply r6 here, as all paths under the merge target
have already had r6 merged into them -- the notification's svn_merge_range_t
should have a "start" field of r6, which should be printed as r7 by the
cmdline client.
> >svn pl -vR merge_tests-1
> Properties on 'merge_tests-1\A_COPY':
> svn:mergeinfo : /A:1,4-10
> Properties on 'merge_tests-1\A_COPY\D':
> svn:mergeinfo : /A/D:1,6-10
>
> === EXAMPLE 3 ==============================================
I take it that this example starts from the initial mergeinfo, rather than
being a continuation of example 2?
> # Another problematic example where again r6 is mentioned:
> >svn merge -r2:10 %URL%/A merge_tests-1\A_COPY
> --- Merging r3 into 'merge_tests-1\A_COPY':
> U merge_tests-1\A_COPY\D\H\psi
> --- Merging r4 through r5 into 'merge_tests-1\A_COPY':
> U merge_tests-1\A_COPY\D\G\rho
Huh, why aren't the above two merges collapsed into a single merge and
notification ("Merging r3 through r5 into ...")? Or, since the second
merge is into D, why don't we say as much as part of the merge notification
(especially when A_COPY already contains those revs)?
> # Should be
> # "--- Merging r7 through r10 into 'merge_tests-1\A_COPY':"?
> --- Merging r6 through r10 into 'merge_tests-1\A_COPY':
> U merge_tests-1\A_COPY\D\G\pi
> U merge_tests-1\A_COPY\D\G\tau
> U merge_tests-1\A_COPY\D\H\chi
What about r7 and r8, which have already been merged into A_COPY?
> >svn pl -vR merge_tests-1
> Properties on 'merge_tests-1\A_COPY':
> svn:mergeinfo : /A:1,3-10
>
> ============================================================
>
> There are other examples, but they all deal with the start revision of
> the notification.
>
> Does anyone else think the behavior in example 2 and 3 is incorrect? Or
> is this acceptable?
Neither.
In both examples 2 and 3, the mergeinfo on a sub-tree path trims part of
the start of a requested merge from the actual merge performed (or at least
from its notification).
--
Daniel Rall
- application/pgp-signature attachment: stored
Received on Mon Oct 8 21:55:33 2007