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