[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: Karl Fogel <kfogel_at_collab.net>
Date: 2001-05-21 22:10:45 CEST

Greg Stein <gstein@lyra.org> writes:
> Personally, I don't see a reason for propagating CVS' notion of having a
> shortcut for every darned subcommand. "rm" and "mv" ... okay. "co" and "ci"
> are from RCS days... maybe. But things like "df" and "di" for diff? Oy. And
> "unad" for "unadd"?? That takes the cake :-) Ah... I see how that came
> about... lose the "ad" for "add" too :-)
>
> I'd like to advocate being *much* more restrictive with the aliases for
> subcommands. We could/should probably lose half of the aliases we have
> defined right now.

Which ones, specifically?

In the specific case of "ad" and "unad", yeah, +1, they're probably
silly, and one has to wonder if "ad" really gets used even in CVS. I
think we'd be on safe ground getting rid of those shortcuts.

But in general, people do save time by typing shortcuts. I use some
of them myself in CVS, I know other people who use other ones. And if
we're going to have short synonyms, then they need to be strictly
defined from the outset. We can't just go with unique prefixes,
because as other commands are added later, they will interfere with
people's existing reflexes.

Short aliases don't do any harm, and in cases where the basic command
is more than a few letters long, having at least one short alias does
some good. Therefore in general, I think we shouldn't be afraid to
make aliases.

But again, it has to be evaluated for each command. When a user makes
a habit, they are no longer reasoning from generally applicable
principles -- they're just doing what they're used to. So in matters
like this, we need to give habituation potential more thought than
some theoretical consistency.

(And if a bunch of people post saying they use "cvs ad", that ought to
tell us something, too. :-) )

-K

---------------------------------------------------------------------
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.