I think what's really bothering fitz (and me) is that we've made a
tradeoff here. We used to have a really 'tight' commandline UI. We
decided from day one that all options would be global, and that their
position in the commandline wouldn't matter. It also meant that each
subcommand had a very succinct list of options that it understood, and
rejected all others. Both of these design decisions were aimed at
making the CLI more usable: no more CVS-like confusions ("does the -d
come before or after the URI?"), and no more confusion about whether
an option was appropriate for a subcommand or not. 'svn help
subcommand' was clear and consise.
Now it feels like we'd traded some of this tightness for the sake of
making it easier for developers to write testing scripts, putting
developers before users. The new design feels like a premature
optimization ("someday all commands might make use of these
switches..."), and users can't run 'svn help subcommand' to get a
sense of say, whether a command actually has the potential to talk to
a repository or not.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 18 16:16:47 2007