On Thu, 2008-08-28 at 13:04 +0200, Stefan Sperling wrote:
> On Wed, Aug 27, 2008 at 03:09:15PM -0400, Karl Fogel wrote:
> > Neels Hofmeyr <neels_at_elego.de> writes:
> > > The second one could be paraphrased: "To make it easier to type a
> > > subcommand". IMHO, `setprop' sits much better in my brain, to the degree
> > > that it involuntarily turns `propset' around do `setprop'.
> > >
> > > Once that's there, I'd expect `sp' to work as well.
> >
> > But alias space doesn't come free, remember. Someday later, we might
> > want 'sp' for "show patch". Or whatever, I don't know -- the point is,
> > if we expand too many commands into large equivalence classes, those
> > classes will inevitably start to interfere with future commands.
> >
> > I think that introducing "setprop" is not actually a good idea. The
> > vast majority of people are not even using the command-line client at
> > all; of those who are, very few have complained about this. I
> > understand that for them it's a real issue -- I am not trying to deny
> > this. But I'm not sure the cost of fixing it is worth the gain. Having
> > "setprop" does imply having "sp"; having "sp"; likewise with "getprop"
> > and "gp". We shouldn't close off alias space for such small gains.
>
> Another obvious alternative to a patch to Subversion would be
> an 'svn' wrapper script that does the setprop -> propset etc.
> translation.
>
> Given that apparently only few people really care about this, and
> that there is resistence in the developer community towards this change,
> should we just tell people to create such a wrapper script / shell
> function instead?
Certainly - if individuals want to create their own wrappers and aliases
for "svn" and/or its subcommands, they are welcome to do so.
I didn't speak up before but I am also -1 on adding more aliases. Mainly
because they create more entropy which makes various scripting,
communication and maintenance tasks more burdensome without adding a
corresponding amount of value. For example, the book gets longer, the
examples get more inconsistent, or inconsistent with what a user prefers
to type, the wrapper scripts that people write around "svn" get longer,
the patch reviews start having bikeshed discussions about which we
should prefer and promote in examples and in our maintained scripts, and
so on.
Also because it is an open-ended specification: there is no limit to the
number of aliases that people could claim to be "useful", so the
"improvement" could never be "complete".
I do accept that the command "setprop" may be easier to remember than
(or at least as easy as) "propset". If we'd had it that way around from
the start, we might not be having this discussion. It's just that I
believe the various small disadvantages of adding more aliases would
accumulate to make the whole Subversion universe in the end worse than
(or at least no better than) the way it is now where the problem is just
that some commands are less easy to remember than we would like.
(The fact that we already have some aliases that don't serve a useful
purpose, such as "praise", perhaps makes some people think it would be
OK to go on adding more aliases, and doesn't help my argument, but it's
too late to remove them now.)
> If so, we could close issue #3268 as WONTFIX.
+1. Done.
- Julian
> I personally still think it's a usability issue with our command
> line client, and would like to see the whole set of aliases added.
>
> But there is no point in adding them unless there is consensus among
> developers about this change, which does not seem to be in sight.
>
> Stefan
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe_at_subversion.tigris.org
For additional commands, e-mail: dev-help_at_subversion.tigris.org
Received on 2008-08-28 14:10:02 CEST