On Tue, 31 Jul 2007, C. Michael Pilato wrote:
> 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.
That'd be great, Mike.
- Dan
- application/pgp-signature attachment: stored
Received on Wed Aug 1 00:36:32 2007