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. :)
Received on 2012-05-10 09:58:52 CEST