[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Issue #2853, do_single_file_merge() lacks comprehensive "Replace-style merge" capability due to lack of attention to ancestry

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2007-07-31 17:00:52 CEST

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.

C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on Tue Jul 31 16:59:21 2007

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.