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

Re: cmd line stuff (was: CVS update: ...)

From: Jonathan S. Shapiro <shap_at_eros-os.org>
Date: 2000-10-18 17:54:37 CEST

All this option discussion leads me to offer a completely unsolicited
opinion:

    Options are the last refuge of a poor design.

Okay, that's strong, and I don't think it's a serious problem with the SVN
folks, but it sometimes provokes people into thinking.

I understand the argument for why, however bad the command set, a cvs-like
command interface is a useful transition tool. My experience suggest that it
is the wrong thing to do.

SVN clearly operates differently from CVS. People using cvs commands will
expect CVS behavior, and will be rudely surprised. It is better to create a
new, coherent command set and explain to CVS users how to use it.

And please note the emphasis on "coherent". In this regard, I am concerned
about some of the options discussions. I see two kinds of options being
discussed:

1. UI options -- things that impact visible behavior. Example: degree of
chattiness or choice of editor. I have no problem with this, but I think
that they should have regular, clearly-comprehensible names and should also
be possible to specify in something like a ".svnrc". My only thought on
these is that UI options are best in moderation.

2. Options that change semantics. Examples: the defaults for whatever
replaces the CVSIGNORE variable. These introduce changes in behavior across
users. If buried in a config file, they can sometimes impact whether you and
I can get the same output from the same command. (In the particular case of
CVSIGNORE we got bit by this regularly until we learned to stop using it).

Two thoughts on the second category:
a) Such options are actually project-wide policy issues. They should NEVER
be specified from the command line or from a local config file.
b) Such options should be minimized, and unless completely vital should be
ommitted until justified by user experience.

And finally: in a new interface all options should conform to getopts. This
positional crud causes real users (even relatively experienced ones) to make
mistakes.

Concrete suggestion: before implementing a command line client, post a
complete list of the commands, the options, and which options can be handed
to which commands. I will try to offer specific (and hopefully helpful)
feedback. The first piece of which is that the CVS interface sucks rocks
and should be completely tossed. I know it started clean and evolved as
these things do. Let's learn from the evolution rather than carry it around
as a burden.

Jonathan
Received on Sat Oct 21 14:36:11 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.