Daniel Rall wrote:
> On Mon, 03 Dec 2007, Paul Burba wrote:
>>> From: Daniel Rall [mailto:firstname.lastname@example.org]
>>> On Fri, 30 Nov 2007, C. Michael Pilato wrote:
>>>> David Glasser wrote:
>>>>> How bad of an idea is making "svn merge" with reverse
>>>>> ranges default
>>>>> to the target and with forward ranges default to the other branch?
>>>>> In my mind that would match common uses well, though
>>>>> maybe it is too
>>>>> clever, and if the command can take multiple ranges (can it?)
>>>>> clearly doesn't work.
>>>> The command can take multiple ranges, and they can be of
>>>> mixed "direction".
>>> Is support for "mixed direction" ranges a good idea? What's
>>> the use case?
>> I had no particular use case in mind, it was simply a case of supporting
>> it didn't seem to have any negative repercussions (at the time!). I can
>> make the change to disallow it if that is preferred - I certainly have
>> no objections to limiting direction.
> Doing so would present a simpler, if less flexible, UI.
How so? As is, folks can merge what they want to merge. That our
implementation has to be a little more complex to deal with mixed range
directions is not a UI matter.
That said, because we disregard entirely the order of the requested ranges
provided by the user, we rob the user of doing anything really intricate.
They can't, for example, think:
"I need to undo this merge of a broken fix in r56 and then merge in
the right fix from r62"
We always handle reverse merges after forward ones, so:
svn merge -c-56 -c62
svn merge -c62 -c-56
and in the scnenario presented, is likely to conflict like crazy.
+1 from me on not trying to support mixed directions. The result will still
be imperfect because we'll again disregard the user's requested range order,
but I think we have a better chance of this being not a problem when all the
merges are in the same direction. We'll do all forward merges from oldest
to youngest, and reverse merges in the opposite order.
C. Michael Pilato <email@example.com>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Tue Dec 4 16:30:24 2007