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

Re: Name change for "--merge-sensitive" to account for more general usage

From: David James <james_at_cs.toronto.edu>
Date: 2007-05-31 23:58:54 CEST

On 5/31/07, Daniel Rall <dlr@collab.net> wrote:
> On Thu, 31 May 2007, Mark Phippard wrote:
>
> > On 5/31/07, Daniel Rall <dlr@collab.net> wrote:
> > >[Re-posting with meaningful subject line.]
> > >
> > >The root of the problem pointed out here is that
> > >'svn merge --merge-sensitive' looks odd.
> > >
> > >On Tue, 29 May 2007, David James wrote:
> > >
> > >> On 5/29/07, Daniel Rall <dlr@collab.net> wrote:
> > >> >On Thu, 24 May 2007, Karl Fogel wrote:
> > >> >
> > >> >> "David James" <james@cs.toronto.edu> writes:
> > >> >> > I know this is a bikeshed, but, how about "--merge-smart"? This flag
> > >> >> > makes the merge command smarter -- it teaches the merge command to
> > >> >> > look at your merge history and figure out what revisions to merge.
> > >> >> > Without this flag, the merge command acts dumb and doesn't guess.
> > >> >> >
> > >> >> > This flag name could work for "svn info" and "svn log" as well.
> > >> >>
> > >> >> Then just "--smart", maybe?
> > >> >>
> > >> >> http://pink.bikeshed.com/
> > >> >
> > >> >"smart" doesn't give a nod to the fact that we're adhering to merge
> > >> >history.
> > >>
> > >> How about "--track-merge-history" or "--smart-merge-tracking" then?
> > >> These names are longer than "--merge-smart" and "--smart" but might
> > >> indicate the purpose of the flag a bit better.
> > >
> > >"--track-merge-history" is a perfect description for the use cases
> > >we're currently targeting, implemented via the following subcommands:
> > >
> > > blame
> > > log
> > > merge
> > >
> > >It's only 4 characters longer than "--merge-sensitive", and we have a
> > >short option ("-g"). Would anyone be adverse to switching, or does
> > >anyone have a better suggestion?
> >
> > I think the problem is that ultimately the usage of this option in the
> > merge scenario is a little different than the others. That being
> > said, I am still in favor of trying to use one option.
> >
> > I personally still prefer --merge-sensitive to the other propsals, but
> > do not feel strongly and agree it could be better. How about
> > --follow-merge-history or --use-merge-history instead of --track?
>
> Of those, I pefer --use-merge-history. I also think it leaves less
> possibility for ambiguity, in relation to --track-merge-history (and
> is also more brief).

+1. Go for it!

Cheers,

David

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Thu May 31 23:59:03 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.