Brian W. Fitzpatrick wrote:
> On Dec 17, 2007 3:13 PM, Steve Sisak <sgs@codewell.com> wrote:
>> At 12:37 PM -0600 12/17/07, Brian W. Fitzpatrick wrote:
>>> On Dec 17, 2007 12:11 PM, Steve Sisak <sgs@codewell.com> wrote:
>>>> I can see that, for consistency, every command ought to be able to
>>>> accept authentication credentials.
>>> This sounds like a remarkably foolish consistency to me.
>> Please provide a specific example why, given that svn is a revision
>> control system that normally requires authentication to do anything
>> with the repository?
>
> Just because 75% of your commands use the option doesn't mean that all
> of them should. By this argument, since commands "normally" take the
> --revision argument, they all should.
I've been following this thread, trying to reserve final judgment. I feel
compelled to point out that this analogy isn't a very strong one. The
options in question are arguably quite generic in nature. Whether the
process should prompt the user, regardless of what it is doing. What auth
credentials and storage limitations should be employed, regardless of what
it is doing. There's nothing particularly generic about a revision, partly
because --revision means different things to different subcommands.
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. But, the fact that we have a runtime configuration area at
all means that as a community we have decided that some options are of the
sort that a user would want to specify for each and every invocation of
Subversion on his/her system. We've just saved them the trouble of all that.
On the other hand we have the command-line switches, which affect only a
single invocation of 'svn'. We've tried to ensure that 'svn' fails when
provided a switch that doesn't apply, presumably so folks don't get into the
habit of providing extraneous switches that today are impotent but tomorrow
might grow meaning (and not the meaning they intended), to the confusion of
the user.
Clearly, there's some call for something in the middle. Surely we can find
it. CVS found it -- it's called the global option space. It's basically
command-line switches that apply to a more fundamental layer of the
operation of the CVS client, and the client against its server, that is
subcommand inspecific. Many (like myself) don't like the global option
space. But why? Well, *my* beef with it is not that there are global
options -- it's that the option code overlap with the per-command option
space. I mean, we all are familiar with 'cvs -d /some/root co -d somedir',
right? Anyway, I posit that these options we're fussing about today are of
the same sort -- global in nature and intent, per-command only because we
intentionally don't have separate option spaces in Subversion.
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.
--
C. Michael Pilato <cmpilato@collab.net>
CollabNet <> www.collab.net <> Distributed Development On Demand
Received on Tue Dec 18 16:57:24 2007