[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

RE: Mixed Direction Merges and Range Compaction (Was: Auto-selection of merge source URL)

From: Paul Burba <pburba_at_collab.net>
Date: Tue, 8 Jan 2008 06:13:41 -0800

> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato_at_collab.net]
> Sent: Monday, January 07, 2008 10:16 PM
> To: Paul Burba
> Cc: Mark Phippard; David Glasser; dev_at_subversion.tigris.org
> Subject: Re: Mixed Direction Merges and Range Compaction
> (Was: Auto-selection of merge source URL)
>
> Did we ever decide what to do about this:

Hi Mike,

No, looks like your previous mail was the last thought on this. So what
to do? You posed three related questions:

1) Allow mixed directions?

2) Perform range sorting?

3) Perform range compaction?

No matter what combination we choose we are sure to make someone unhappy
but I don't have much feel for which choice will cause the least
unhappiness. That hedging aside, I think we should:

A) Disallow mixed directions, seriously is *anyone* clamoring for this?

B) Sort and compact ranges. This is easy to explain and understand.
While it robs power users of some potential tricks, they can still, as
you pointed out previously, execute multiple merge commands instead.

Any objections? If not I can make this change.

Paul
 
> 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.
> >> 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. :-)
> >

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-01-08 16:56:46 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.