Kevin Pilch-Bisson <kevin@pilch-bisson.net> writes:
> Working away at being able to pass options to diff, and have come into a
> (small) problem. Because of the way apr_getopt works, we either need to
> enumerate every option that could be passed to diff, or we need to set
> our apr_getopt_t's err field to 0, and handle APR_BADCH. This implies that
> APR will no longer handle invalid options for us.
>
> My idea was to follow the second approach, adding an UNKNOWN_OPTIONS variable
> to each subcommand's svn_cl__cmd_desc_t. Then after we have determined the
> subcommand, we error out if that subcommand doesn't expect unknown options.
>
> Does this sound reasonable?
Hmmmm. Mike Pilato and I aren't so happy about this.
Presently, our command-line client has a single global "switch-space".
We've explicitly committed ourselves to this model, because we think
CVS's two switch-spaces (global vs. subcommand) leads to a *lot* of
confusion. (Especially with switches like "-d".)
Now we have a situation where you want to pass arbitrary switches to a
particular subcommand; your proposal sort of implicitly creates a
second subcommand switch-space... but I think it's far worse than
that. Instead of openly declaring it, we'd just let unrecognized
options "slip through" to this secretive second space. I think this
is just asking for trouble. I mean, what if someday we decide to add
a global "-u" switch. Ooops, suddenly this switch is no longer
"unrecognized" and thus no longer passed through to diff. And we
wouldn't discover this bug right away, either.
My feeling is: either have two switch-spaces, and be open about it, or
have one, and be open about it. And I definitely vote for staying on
the present course with one global space. I'm not sure that as GNU
diff evolves, that Subversion *must* be able to take advantage of
every new switch that it grows. Choose a reasonable subset of GNU
diff switches, and reserve them in the Subversion global switch-space.
We'll deal with the consequences.
Thoughts?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:39 2006