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

Re: ugly aliases (was: Re: CVS update: MODIFIED: libsvn_wc ...)

From: Greg Stein <gstein_at_lyra.org>
Date: 2001-05-22 01:03:52 CEST

On Mon, May 21, 2001 at 06:13:02AM -0500, Jeremy Blosser wrote:
> Greg Stein [gstein@lyra.org] wrote:
> > On Mon, May 21, 2001 at 03:10:45PM -0500, Karl Fogel wrote:
> > > (And if a bunch of people post saying they use "cvs ad", that ought to
> > > tell us something, too. :-) )
> >
> > Yah... it'll tell us there are a bunch of kooks out there in the world :-)
>
> </lurk>
>
> I've never used 'cvs ad' because I didn't realize it was there. At the
> risk of being a kook, I'll probably start using it now that I know about
> it. There's benefit to me in just knowing there is a 2-char abbrev for
> each subcommand -- it limits what my brain thinks it has to consider when
> switching to and remembering the abbreviations. It may seem silly in the
> case of 'add' vs. 'ad', but I think there is some merit in it. As an
> abbreviation it doesn't make any less sense than 'ci' for 'commit', and

"ci" is short for "checkin", and has historical relevance to RCS. Same for
"co" being "checkout". Those aren't abbreviations so much as aliases /
synonyms.

>...
> I know I'm a nobody here, but if it doesn't affect the footprint

Everybody is a somebody when it comes to usability. Committing code is a
little different :-)

>...
> Oh, and keep 'di' over 'df', certainly. CVS uses 'di', and 'df' has a
> completely unrelated prior meaning in Un*x.

That seems to be the direction; as Mo said, CVS uses 'di'. I'm with you: I
was surprised at the "df" in there.

Cheers,
-g

-- 
Greg Stein, http://www.lyra.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:30 2006

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.