[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: C. Michael Pilato <cmpilato_at_collab.net>
Date: Tue, 08 Jan 2008 09:51:31 -0500

David Glasser wrote:
> On Jan 8, 2008 9:28 AM, C. Michael Pilato <cmpilato_at_collab.net> wrote:
>> Paul Burba wrote:
>>>> -----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.
>> 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 <cmpilato_at_collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on 2008-01-08 16:17:35 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.