On Dec 18, 2007 9:30 AM, C. Michael Pilato <cmpilato@collab.net> wrote:
> Am I arguing for a global option space? Uh -- *heck* no. I think we need
> only pay attention to the dangers of extraneous per-subcommand options, and
> see if there's really any risk there. That is, if we define --username to
> be the username Subversion will use against the server, that's pretty
> generic, and we can say that it means the same thing across all operations
> today, and reasonably project that it will continue to mean the same thing
> across all operations in the future. The same is, I think, true of the
> other options in question here. In my opinion, then, (which is now as old
> as these works I'm typing, having talked myself into it just now), there's
> no real danger in letting those global-like options exist in all
> subcommands. 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.
Hm, maybe you're right. If 'svn help subcommand' clearly showed me a
grouping of 'global options' that sort of lined up with stuff in
~/.subversion/config, and made that group distinct from the
'subcommand options' that were specific to the subcommand, then I
guess things would be a bit tighter for the user. They still have no
way of knowing whether a command talks to the repository, but I guess
that's not the end of the world.
---------------------------------------------------------------------
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:49:55 2007