You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by David Glasser <gl...@mit.edu> on 2007/05/24 21:12:22 UTC

Re: svn commit: r25113 - in trunk/subversion: svn tests/cmdline

On 5/22/07, dlr@tigris.org <dl...@tigris.org> wrote:
> Log:
> Exchange the more specific --suggested-source option introduced in
> r25112 for the --merge-sensitive/-g option (cherry picked out of the
> merge-sensitive-log branch), as requested by epg on IRC.

I think using --merge-sensitive here is pretty confusing.  Unless I'm
mistaken, you're suggesting:

$ svn merge --merge-sensitive

as a command people would be typing?  I know getting the short option
(-g) is nice, but if I saw --merge-sensitive as an option in "svn help
merge" my first thought would be "as opposed to what?
merge-insensitive merges?"

--dave

-- 
David Glasser | glasser@mit.edu | http://www.davidglasser.net/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

Posted by David James <ja...@cs.toronto.edu>.
On 5/31/07, Daniel Rall <dl...@collab.net> wrote:
> On Thu, 31 May 2007, Mark Phippard wrote:
>
> > On 5/31/07, Daniel Rall <dl...@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 <dl...@collab.net> wrote:
> > >> >On Thu, 24 May 2007, Karl Fogel wrote:
> > >> >
> > >> >> "David James" <ja...@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

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

Posted by Daniel Rall <dl...@collab.net>.
On Thu, 31 May 2007, Mark Phippard wrote:

> On 5/31/07, Daniel Rall <dl...@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 <dl...@collab.net> wrote:
> >> >On Thu, 24 May 2007, Karl Fogel wrote:
> >> >
> >> >> "David James" <ja...@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).

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

Posted by Mark Phippard <ma...@gmail.com>.
On 5/31/07, Daniel Rall <dl...@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 <dl...@collab.net> wrote:
> > >On Thu, 24 May 2007, Karl Fogel wrote:
> > >
> > >> "David James" <ja...@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?


-- 
Thanks

Mark Phippard
http://markphip.blogspot.com/

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

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

Posted by Daniel Rall <dl...@collab.net>.
[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 <dl...@collab.net> wrote:
> >On Thu, 24 May 2007, Karl Fogel wrote:
> >
> >> "David James" <ja...@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?

Re: svn commit: r25113 - in trunk/subversion: svn tests/cmdline

Posted by Daniel Rall <dl...@collab.net>.
On Tue, 29 May 2007, David James wrote:

> On 5/29/07, Daniel Rall <dl...@collab.net> wrote:
> >On Thu, 24 May 2007, Karl Fogel wrote:
> >
> >> "David James" <ja...@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?

Re: svn commit: r25113 - in trunk/subversion: svn tests/cmdline

Posted by David James <ja...@cs.toronto.edu>.
On 5/29/07, Daniel Rall <dl...@collab.net> wrote:
> On Thu, 24 May 2007, Karl Fogel wrote:
>
> > "David James" <ja...@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.

Cheers,

David

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: r25113 - in trunk/subversion: svn tests/cmdline

Posted by Daniel Rall <dl...@collab.net>.
On Thu, 24 May 2007, Karl Fogel wrote:

> "David James" <ja...@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.

Re: svn commit: r25113 - in trunk/subversion: svn tests/cmdline

Posted by Karl Fogel <kf...@red-bean.com>.
"David James" <ja...@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/

-Karl

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: r25113 - in trunk/subversion: svn tests/cmdline

Posted by David James <ja...@cs.toronto.edu>.
On 5/24/07, Daniel Rall <dl...@collab.net> wrote:
> On Thu, 24 May 2007, David Glasser wrote:
>
> > On 5/22/07, dlr@tigris.org <dl...@tigris.org> wrote:
> > >Log:
> > >Exchange the more specific --suggested-source option introduced in
> > >r25112 for the --merge-sensitive/-g option (cherry picked out of the
> > >merge-sensitive-log branch), as requested by epg on IRC.
> >
> > I think using --merge-sensitive here is pretty confusing.  Unless I'm
> > mistaken, you're suggesting:
> >
> > $ svn merge --merge-sensitive
> >
> > as a command people would be typing?  I know getting the short option
> > (-g) is nice, but if I saw --merge-sensitive as an option in "svn help
> > merge" my first thought would be "as opposed to what?
> > merge-insensitive merges?"
>
> The --merge-sensitive option really represents "merge info sensitive".
> So, the answer to your question would be "yes, as opposed to merge
> info-insensitive merges."
>
> --mergeinfo-sensitive is even more of a mouthful than
> --merge-sensitive.  Have a better naming suggestion?

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.

Cheers,

David

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org

Re: svn commit: r25113 - in trunk/subversion: svn tests/cmdline

Posted by Daniel Rall <dl...@collab.net>.
On Thu, 24 May 2007, David Glasser wrote:

> On 5/22/07, dlr@tigris.org <dl...@tigris.org> wrote:
> >Log:
> >Exchange the more specific --suggested-source option introduced in
> >r25112 for the --merge-sensitive/-g option (cherry picked out of the
> >merge-sensitive-log branch), as requested by epg on IRC.
> 
> I think using --merge-sensitive here is pretty confusing.  Unless I'm
> mistaken, you're suggesting:
> 
> $ svn merge --merge-sensitive
> 
> as a command people would be typing?  I know getting the short option
> (-g) is nice, but if I saw --merge-sensitive as an option in "svn help
> merge" my first thought would be "as opposed to what?
> merge-insensitive merges?"

The --merge-sensitive option really represents "merge info sensitive".
So, the answer to your question would be "yes, as opposed to merge
info-insensitive merges."

--mergeinfo-sensitive is even more of a mouthful than
--merge-sensitive.  Have a better naming suggestion?

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org