Paul Burba wrote:
>> +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.
>
> Mike,
>
> Regardless of whether we limit ourselves to only one direction, you seem
> to think it preferable to simply apply the merges requested in exactly
> the order requested and not do anything "clever" re compaction.
If that was the impression I gave, I'm sorry. Let me see if I can provide a
more well-formed opinion.
We currently have multiple variables in our requested range handling.
First, we have the question of whether or not to allow mixed directions.
Secondly is the question of whether or not to perform range sorting.
Finally, whether or not we perform range compaction. In my opinion, the
decision made in this space must be made with all of these variables in mind
-- that is, we can't make them independently.
For example, in my opinion, it's fine to allow mixed directions and limited
range compaction (only that which doesn't affect order) without range
sorting. In other words, do exactly as we were told to do, avoid only the
obviously unnecessary steps:
-c5 -c6 -c7 => 4:7
-c5 -c6 -c9 -c7 => 4:6, 8:9, 6:7
It's also fine to do range sorting and full compaction without allowing
mixed directions, because we can make a case for ranges of the same
direction obeying the ordering of the source, but no similar case can be
made in the mixed-direction scenario.
In the end, of course, remember that the user doesn't *have* to employ the
use of multiple revision ranges in a given 'svn merge' invocation. They can
just as easily call 'svn merge' multiple times.
So, all that to say that what I think is Right is a complicated matter. :-)
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Tue Dec 4 18:19:45 2007