"Jonathan S. Shapiro" wrote:
> 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.
OK. As some may guess, I have thought a lot about "options".
Basically, a program or suite (like SVN for example) provides
a huge collection of functionality. The goal is to provide
a method by which a user can communicate to the program which
of those functions need to be performed. We can
write a unique program (shell script) for every
possible permutation of functionality. It would make the
command lines very simple. It has other problems, though.
We can also provide command line options to control every
conceivable variation in behavior, too. That is actually
okay. It is okay as long as all or nearly all of the
options are not required, have useful defaults, and are
documented in obvious ways. "Obvious" to me means *both*
``man svn'' *and* ``svn --help''. ``info svn'' is a convention
less than two decades old, so it is not quite obvious enough.
Especially since there are so many installations that do not
have such configured. [[enhancement idea for info: when invoked
as ``info mumble'', if it does not have a mumble doc, check for
a mumble man page and exec man if found. Probably for another
forum, tho....]] Anyway, that is why AutoOpts includes automated
man pages.....
> I understand the argument for why, however bad the command set,
> a cvs-like command interface is a useful transition tool.
> My experience suggests that it is the wrong thing to do.
It is doing much the same functionally, so users will need to
communicate the desire for having much the same thing happening.
If CVS has a well known way for requesting something be done,
it is not at all clear we should provide new and better ways for
asking for the same thing. Minimize differences. But use your
brain, too :-).
> 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).
Nearly all the options should be specifiable from RC files and
environment variables. *AND* they should be specified using
straight forward transforms of the command and option names.
e.g. the RC file should be .svnrc and the option identifiers
in that file should be the long option names. The environment
variables should be SVN_CMD_MUMBLE for the --mumble option of
the svn ``cmd'' command. It is not clear to me why you make a
distinction here, and the boundary between them would be very
fuzzy, to say the least.
> 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.
It should be possible to specify loading of project-specific
configuration from project-local RC files. But you should always
be ABLE to over-ride via environment variables (i.e. session values)
and command line options.
> 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.
It is probably a little painful to determine an option's validity
before it can be determined which command is really being invoked.
In other words, you can easily move the "global" options to after
the (sub)command name, but not vice-versa. (Well, ok, it is a
computable problem. Such "flexibility" just is not worth the effort.)
> 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.
Again, not completely. CVS performs a function that SVN is intended to
supersede. Where convenient (using our brains to decide such), we should
not find new and better ways of specifying the same thing. In a couple
days, I will post the CVS options, augmented with long options for all
options. First thing to do with it is chop away all the dinkleberries.
Then we can tweak the things that do need improvement and add in
specifications for things one cannot do with CVS.
Cheers,
Bruce
Received on Sat Oct 21 14:36:11 2006