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?
>
> 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.
>
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 <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Tue Jul 31 17:19:57 2007