Re: Passing unused opts to every command considered harmful

At 9:10 AM -0800 12/17/07, David Glasser wrote:
>If the 'help' output implies too strongly that any command that takes
>--non-interactive absolutely has a way to be interactive right now
>(for example), then perhaps that needs to be changed.

I can see the logic of argument consistency across commands -- maybe
a compromise would be to segregate the generic commands which in the
help text.

For instance (text stolen from "svn help status"):

Valid options:
   -u [--show-updates] : display update information
   -v [--verbose] : print extra information
   -N [--non-recursive] : operate on single directory only
   -q [--quiet] : print as little as possible
   --no-ignore : disregard default and svn:ignore property ignores
   --incremental : give output suitable for concatenation
   --xml : output in XML
   --config-dir arg : read user configuration files from directory ARG
   --ignore-externals : ignore externals definitions

Ignored options (accepted but not currently implemented):
   --username arg : specify a username ARG
   --password arg : specify a password ARG
   --no-auth-cache : do not cache authentication tokens
   --non-interactive : do no interactive prompting

I can see that, for consistency, every command ought to be able to
accept authentication credentials.

I can also seen some very options commands that ought to apply
consistently to any command where they are implemented and otherwise
ignored:

   -v [--verbose] : print extra information
   --non-interactive : do no interactive prompting

Also, --non-interactive should be a constraint and generate an error
if the command is not capable of non-interactive operation.

-------------------

It also might make sense to have the (documentation) concept of
"Common Options", defined as "options that may apply to any command
(but, if implemented, behave this way)".

Then the help text and documentation could list 3 sections:

Command options:

Common Options:

Ignored Options:

By having common options all documented in one place, it would cut
down on the amount of copy/paste in the documentation and see what is
truly unique for each command.

Just a couple thoughts.

HTH,

-Steve

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Mon Dec 17 19:13:39 2007