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

Re: Auto-selection of merge source URL

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: 2007-12-04 16:30:05 CET

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.

-- 
C. Michael Pilato <cmpilato@collab.net>
CollabNet   <>   www.collab.net   <>   Distributed Development On Demand

Received on Tue Dec 4 16:30:24 2007

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.