C. Michael Pilato wrote:
> 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?
> 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.
Note that 'svn diff -r2:1 URL' produces the same kind of problem.
But if at a theoretical level discover_and_merge_children() is sane in its
assumptions, there's no reason why do_single_file_merge() couldn't take a
flag to force the interpretation of the arguments into an "I'm a subset of a
directory merge" mode, used only when not called as part of a file-targeted
'svn merge' invocation. In fact, I'll go ahead and add that mode now, and
we can deal with the theoretical implications later. This should solve your
revert test problem.
C. Michael Pilato <firstname.lastname@example.org>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Tue Jul 31 17:19:57 2007