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

Re: It's time to fix Subversion Merge

From: Mark Phippard <markphip_at_gmail.com>
Date: Tue, 12 Jul 2011 12:58:28 -0400

On Tue, Jul 12, 2011 at 12:52 PM, Hyrum K Wright <hyrum_at_hyrumwright.org> wrote:
> On Tue, Jul 12, 2011 at 11:47 AM, Mark Phippard <markphip_at_gmail.com> wrote:
>> On Tue, Jul 12, 2011 at 12:45 PM, Hyrum K Wright <hyrum_at_hyrumwright.org> wrote:
>>> On Tue, Jul 12, 2011 at 11:25 AM, Mark Phippard <markphip_at_gmail.com> wrote:
>>>> Finally, in your new design do not forget about things like log -g and
>>>> blame -g, as well as the mergeinfo command.  These features are all
>>>> necessary parts of a merge tracking plan and must have answers from
>>>> the first release.
>>> Really?  I think we should take whatever improvements we can get,
>>> rather than saying "oh, and you need to support all this legacy
>>> baggage as well."  While they are useful to some folks, I don't think
>>> they are can't-live-without-absolutely-must-have features.  I'm mean,
>>> if we're thinking outside the box, let's think Outside the BOX, and
>>> try not to pigeon hole ourselves.
>>> It would be interesting to see the usage of 'log -g' and 'blame -g'.
>>> I believe Tortoise uses them as the default under-the-hood, so that
>>> probably inflates the actual usage numbers quite a bit.
>> A new merge tracking design that does not support these features, or
>> at least have a very definite plan for supporting then, would be dead
>> on arrival.  If the design does not support these options then go back
>> to the drawing board.
>> These are absolute must have features.
> With all due respect, that's not your decision to make.  This
> consensus-based community gets to determine what are must-have
> features and what aren't.
> In reading this thread, it almost feels like there are two classes of
> merge users: power users and others, and they have different sets of
> requirements.  Certainly it's not a discrete set, but a continuum.
> Unfortunately, Subversion tries to serve the needs of both with a
> single paradigm, and it's not working too well.

I see us heading down the path of a classic engineering anti-pattern.
There is a tough problem to solve, so you decide to rewrite and focus
on that problem and along the way you toss aside existing things you
already support because you think they are not important.

Users of Subversion before we had merge tracking, and users of
Subversion since we have had merge tracking have made it very clear
that these options are important to them. You cannot come up with a
new merge design that does not account for these needs.

Mark Phippard
Received on 2011-07-12 18:59:02 CEST

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