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

Re: Symmetric merge -- current test failures when enabled

From: Julian Foad <julianfoad_at_btopenworld.com>
Date: Thu, 10 May 2012 10:36:29 +0100 (BST)

In r1336529 I fixed the symmetric merge code to work with merging changes into a file from its own history, and in r1336559 I adjusted the tests that depended on a simple merge producing conflicts that the symmetric merge will not produce.  Now there are just these test failures:

FAIL:  merge_tests.py 78: dont merge revs into a subtree that predate it
FAIL:  merge_tests.py 88: subtree merges dont cause spurious conflicts
FAIL:  merge_tests.py 89: target and subtrees need nonintersecting revs
FAIL:  merge_reintegrate_tests.py 10: merge --reintegrate with subtree mergeinfo

- Julian

----- Original Message -----
> From: Branko Čibej <brane_at_apache.org>
> To: dev_at_subversion.apache.org
> Cc:
> Sent: Thursday, 10 May 2012, 8:58
> Subject: Re: Symmetric merge -- current test failures when enabled
> On 10.05.2012 09:36, Julian Foad wrote:
>> Branko Čibej wrote:
>>> On 09.05.2012 18:54, Julian Foad wrote:
>>>>   The second group concerns merging changes into a file from its own
> (past or
>>> future) history; this kind of merge isn't a 'sync' so
> shouldn't
>>> be handled by this code path.
>>> We keep coming back to this ... I still don't understand /why/ we
> would
>>> need more than one merge algorithm, or why the symmetric merge would
> not
>>> work correctly in this case.
>> Well, I was hand-waving a bit, meaning to dismiss this as some kind of
> simple side-issue, which I think it is.  I agree that, in principle, there need
> not be any other kind of merge.  In practice, however, we might want to bypass
> the part of the algorithm that traverses the merge graph and branching history
> to find an appropriate base, if we have a degenerate case where we know in
> advance what base to use, and if the source and target branches do not both
> exist as separate branches in the repository.
> Ah, OK. I was worried a bit there. :)
> By the way ... the logical shortcut for "svn merge -rX:X-1 . ." would
> be
> "svn revert -cX", with the difference that such a reversion
> doesn't
> really need to change the mergeinfo, because it's really more like "svn
> diff -c-X | svn patch".
> You probably don't want to enhance revert in this way, having your hand
> full of the merge code, but I though I'd toss the idea here as long as
> we're on the subject. :)
> -- Brane
Received on 2012-05-10 11:37:06 CEST

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