Daniel Rall wrote:
> Mike, r25891 doesn't appear to handle Replace support for the 'svn merge
> -r2:1 url' case which is blocking issue #2822 (by causing the failure
> for revert test #15 w/ the patch in that issue). This particular case
> does an implicit peg of HEAD, which is handled in the block above the
> one quoted below (in which you've fixed the Replace problem for
> history-sensitive merging).
>
> In r25889, you changed the merge test case written by Senthil to avoid
> this implicit use of a peg revision, and mentioned that "the jury is
> still out (for me) on whether or not that use case is expected to
> fail." Would you elaborate on this?
Sure.
Strictly speaking, and obeying the rules of the peg revision algorithm, 'svn
merge -r2:1 URL[@HEAD]' means "please apply, in reverse, the change made to
the line of history identified by URL@HEAD between revisions 1 and 2". In
the test case mentioned, this causes a bit of a problem. URL@HEAD only has
a single revision of history, r2 -- it doesn't exist in r1. A stretch in
the interpretation of the peg-rev algorithm *might* let us allow to treat
'svn merge -r2:1 URL@HEAD' as a removal of all the lines in URL@2, but
there's no support in the peg-rev algorithm whatsoever for referring to two
different lines of the history. File-replace is, therefore, incompatible
with that syntax.
I'm looking over the code in discover_and_merge_children(), and what I see
makes me suspicious. The code assumes that:
"dir@PEG -rM:N" == "dir/child1@PEG -rM:N" + "dir/child2@PEG -rM:N" + ...
Something tells me that simply isn't true.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Tue Jul 31 16:59:21 2007