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
