At 10:30 AM -0500 12/18/07, C. Michael Pilato wrote:
>Our runtime configuration area can be thought of us a collection of
>command-line switches that are always provided to the application. Never do
>all of those switches make sense for a given operation. Most of the time,
>only one or a small handful do. And yet they are basically there all the
>time. We don't make users provide different runtime configs that contain
>only the few relevant options for each invocation of Subversion. That would
>be obnoxious.
This is a much better wording of what I was trying to say.
(BTW, I don't have a strong opinion, but am trying to feel out the
edge cases -- don't mean to cause any offense)
>I would *prefer* that our usage messages group those
>separately -- call them out like global options that might not have any real
>affect on a given subcommand today. But I think we'll do just fine in
>allowing these globally-natured options to exist on all subcommands.
Likewise.
At 9:16 AM -0600 12/18/07, Ben Collins-Sussman wrote:
>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.
This could be addressed in the documentation.
Here's a straw man proposal:
Define a set of global options.
These are defined for all subcommands and either implemented or not
implemented by each subcommand.
If they implemented, their behavior is consistent with the global
definition (no reusing them for other purposes).
If an unimplemented but defined option is passed to a subcommand, it
is ignored.
"svn help subcommand" only lists implemented options.
The svn help text for each subcommand should get a separate section
documenting under which circumstances a command might talk to the
repository rather having the user guess based on the presence of
authentication subcommands.
(I could see the usefulness of a --local-only parallel to
--non-interactive that makes it a runtime error for a subcommand to
attempt to talk to the repository)
I could also see options being grouped into sections or suites
(authentication, interactivity, logging) in the svn help text where
the entire suite is present or not.
Optionally, global options could be listed separately from
subcommand-specific options, but only implemented options should be
listed. Their order should be consistent in the documentation of each
subcommand.
Note that I'm replacing the term "supported" with two terms "defined"
and "implemented" -- global options would be defined for all
subcommands but the documentation for a given subcommand would only
list those that were implemented.
Shoot away.
Cheers,
-Steve
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Tue Dec 18 17:31:55 2007