Did we ever decide what to do about this:
C. Michael Pilato wrote:
> 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.
>> 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_at_collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on 2008-01-08 04:16:18 CET