You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by "C. Michael Pilato" <cm...@collab.net> on 2008/01/08 03:16:07 UTC
Re: Mixed Direction Merges and Range Compaction (Was: Auto-selection
of merge source URL)
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.
>> 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 <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Mixed Direction Merges and Range Compaction (Was: Auto-selection
of merge source URL)
Posted by David O'Shea <da...@s3group.com>.
On 08/01/2008 14:36, David Glasser wrote:
> On Jan 8, 2008 9:28 AM, C. Michael Pilato <cm...@collab.net> wrote:
>> I think I favor doing no pre-processing *at all* of the requested ranges.
>> Let users ask for what they want; let them get what they asked for. So,
>> allow mixed revisions, allow dupes, allow overlaps -- the whole shebang.
>> Remember, we do our range looping high in the call stack of a merge
>> operation. If our merge tracking can't deal with these conditions in a
>> single 'svn merge' invocation, it can't deal with them across multiple 'svn
>> merge' invocations (and is therefore pretty much useless).
>
> This does seem reasonable. On the other hand, I am still attracted to
> the original reason for suggesting no mixed directions, which is to
> provide a different default merge source URL for forward vs reverse
> merges.
What about doing this but mandating a source URL in the case of mixed
directions?
David.
--
David O'Shea
The information contained in this e-mail and in any attachments is confidential and is designated solely for the attention of the intended recipient(s). If you are not an intended recipient, you must not use, disclose, copy, distribute or retain this e-mail or any part thereof. If you have received this e-mail in error, please notify the sender by return e-mail and delete all copies of this e-mail from your computer system(s).
Please direct any additional queries to: communications@s3group.com.
Thank You.
Silicon and Software Systems Limited. Registered in Ireland no. 378073.
Registered Office: South County Business Park, Leopardstown, Dublin 18
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Mixed Direction Merges and Range Compaction (Was: Auto-selection
of merge source URL)
Posted by "C. Michael Pilato" <cm...@collab.net>.
Branko Čibej wrote:
> C. Michael Pilato wrote:
>> Yeah, see, choosing a different source based on revision direction still
>> strikes me as ... unwise, to put it nicely. Interactive merge source
>> selection (issue 3065), baby!
>>
>> The more I think about it, the more I realize that as a general rule
>> I'm in
>> favor of the command-line client providing the most powerful interface
>> possible to the user. If it can be done in Subversion, it can be done --
>> perhaps with a complex syntax -- through the command-line client. If you
>> want your Subversion to be warm and fuzzy with rounded edges and foam
>> padding and (try to) think for you, find and embrace a GUI that has a
>> Not-So-Advanced mode, or write wrapper scripts around 'svn'. It's much
>> easier to wrap a complex thing with a layer of simplification than the
>> reverse.
>>
>
> Can't find an appropriate smiley for how reading that made me feel ...
>
> Why'd we want to insist on doing something in one cmdline invocation
> when it can be done just as well in two? Or in a slightly more
> philosophical mood ... why double the complexity to quadruple the number
> of bugs?
I removed range compaction in r28871. But I probably have a usage message
to update, too, now that I think about it.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Mixed Direction Merges and Range Compaction (Was: Auto-selection
of merge source URL)
Posted by Branko Čibej <br...@xbc.nu>.
C. Michael Pilato wrote:
> Yeah, see, choosing a different source based on revision direction still
> strikes me as ... unwise, to put it nicely. Interactive merge source
> selection (issue 3065), baby!
>
> The more I think about it, the more I realize that as a general rule I'm in
> favor of the command-line client providing the most powerful interface
> possible to the user. If it can be done in Subversion, it can be done --
> perhaps with a complex syntax -- through the command-line client. If you
> want your Subversion to be warm and fuzzy with rounded edges and foam
> padding and (try to) think for you, find and embrace a GUI that has a
> Not-So-Advanced mode, or write wrapper scripts around 'svn'. It's much
> easier to wrap a complex thing with a layer of simplification than the reverse.
>
Can't find an appropriate smiley for how reading that made me feel ...
Why'd we want to insist on doing something in one cmdline invocation
when it can be done just as well in two? Or in a slightly more
philosophical mood ... why double the complexity to quadruple the number
of bugs?
-- Brane
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Mixed Direction Merges and Range Compaction (Was: Auto-selection
of merge source URL)
Posted by "C. Michael Pilato" <cm...@collab.net>.
David Glasser wrote:
> On Jan 8, 2008 9:28 AM, C. Michael Pilato <cm...@collab.net> wrote:
>> Paul Burba wrote:
>>>> -----Original Message-----
>>>> From: C. Michael Pilato [mailto:cmpilato@collab.net]
>>>> Sent: Monday, January 07, 2008 10:16 PM
>>>> To: Paul Burba
>>>> Cc: Mark Phippard; David Glasser; dev@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.
>> I think I favor doing no pre-processing *at all* of the requested ranges.
>> Let users ask for what they want; let them get what they asked for. So,
>> allow mixed revisions, allow dupes, allow overlaps -- the whole shebang.
>> Remember, we do our range looping high in the call stack of a merge
>> operation. If our merge tracking can't deal with these conditions in a
>> single 'svn merge' invocation, it can't deal with them across multiple 'svn
>> merge' invocations (and is therefore pretty much useless).
>
> This does seem reasonable. On the other hand, I am still attracted to
> the original reason for suggesting no mixed directions, which is to
> provide a different default merge source URL for forward vs reverse
> merges.
Yeah, see, choosing a different source based on revision direction still
strikes me as ... unwise, to put it nicely. Interactive merge source
selection (issue 3065), baby!
The more I think about it, the more I realize that as a general rule I'm in
favor of the command-line client providing the most powerful interface
possible to the user. If it can be done in Subversion, it can be done --
perhaps with a complex syntax -- through the command-line client. If you
want your Subversion to be warm and fuzzy with rounded edges and foam
padding and (try to) think for you, find and embrace a GUI that has a
Not-So-Advanced mode, or write wrapper scripts around 'svn'. It's much
easier to wrap a complex thing with a layer of simplification than the reverse.
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Re: Mixed Direction Merges and Range Compaction (Was: Auto-selection of merge source URL)
Posted by David Glasser <gl...@davidglasser.net>.
On Jan 8, 2008 9:28 AM, C. Michael Pilato <cm...@collab.net> wrote:
> Paul Burba wrote:
> >> -----Original Message-----
> >> From: C. Michael Pilato [mailto:cmpilato@collab.net]
> >> Sent: Monday, January 07, 2008 10:16 PM
> >> To: Paul Burba
> >> Cc: Mark Phippard; David Glasser; dev@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.
>
> I think I favor doing no pre-processing *at all* of the requested ranges.
> Let users ask for what they want; let them get what they asked for. So,
> allow mixed revisions, allow dupes, allow overlaps -- the whole shebang.
> Remember, we do our range looping high in the call stack of a merge
> operation. If our merge tracking can't deal with these conditions in a
> single 'svn merge' invocation, it can't deal with them across multiple 'svn
> merge' invocations (and is therefore pretty much useless).
This does seem reasonable. On the other hand, I am still attracted to
the original reason for suggesting no mixed directions, which is to
provide a different default merge source URL for forward vs reverse
merges.
--dave
--
David Glasser | glasser@davidglasser.net | http://www.davidglasser.net/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Re: Mixed Direction Merges and Range Compaction (Was: Auto-selection
of merge source URL)
Posted by "C. Michael Pilato" <cm...@collab.net>.
Paul Burba wrote:
>> -----Original Message-----
>> From: C. Michael Pilato [mailto:cmpilato@collab.net]
>> Sent: Monday, January 07, 2008 10:16 PM
>> To: Paul Burba
>> Cc: Mark Phippard; David Glasser; dev@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.
I think I favor doing no pre-processing *at all* of the requested ranges.
Let users ask for what they want; let them get what they asked for. So,
allow mixed revisions, allow dupes, allow overlaps -- the whole shebang.
Remember, we do our range looping high in the call stack of a merge
operation. If our merge tracking can't deal with these conditions in a
single 'svn merge' invocation, it can't deal with them across multiple 'svn
merge' invocations (and is therefore pretty much useless).
--
C. Michael Pilato <cm...@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
RE: Mixed Direction Merges and Range Compaction (Was: Auto-selection of merge source URL)
Posted by Paul Burba <pb...@collab.net>.
> -----Original Message-----
> From: C. Michael Pilato [mailto:cmpilato@collab.net]
> Sent: Monday, January 07, 2008 10:16 PM
> To: Paul Burba
> Cc: Mark Phippard; David Glasser; dev@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@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org