[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: Branko Čibej <brane_at_apache.org>
Date: Thu, 10 May 2012 09:58:42 +0200

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 09:58:52 CEST

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.