> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato@collab.net]
> Sent: Tuesday, December 04, 2007 10:30 AM
> To: Daniel Rall
> Cc: Paul Burba; David Glasser; dev@subversion.tigris.org
> Subject: Re: Auto-selection of merge source URL
>
> Daniel Rall wrote:
> > On Mon, 03 Dec 2007, Paul Burba wrote:
> >
> >>> From: Daniel Rall [mailto:dlr@collab.net]
> > ...
> >>> 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
>
> becomes
>
> 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.
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. Hmmm,
why not? That puts more power in the user's hands and it certainly
makes it easy to understand how multiple ranges are applied.
The question is, which matters more:
A) Power user Fred wants to do something clever re the order of multiple
ranges merged and is thwarted. Fred inundates the dev list with hate
mail.
B) Newbie Bob has some time saved because he requested two overlapping
ranges. Unfortunately Bob doesn't realize this so can't actually
appreciate it. And even if he did, he is unaware that the dev list
exists, so can't shower us with praise in any case.
'A' no? I think all my compaction stuff was a solution in search of a
problem...If we do dump it, it looks easy to do too, amounting more or
less to the removal of compact_merge_ranges() from
normalize_merge_sources().
Do you envision *any* checking/compaction of requested ranges at all,
(e.g. -r5:10 -r10:15 --> -r5:15), or just do literally what the user
asks?
Paul
> --
> C. Michael Pilato <cmpilato@collab.net>
> CollabNet <> www.collab.net <> Distributed
> Development On Demand
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 4 17:59:31 2007