[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Diff options

From: Branko Čibej <brane_at_xbc.nu>
Date: 2001-09-04 19:42:33 CEST

What he said. I couldn't put it better myself.

Oh, and +1 for '--diff-options="--foo --bar"', too.

Ben Collins-Sussman wrote:

>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
>

-- 
Brane �ibej   <brane_at_xbc.nu>            http://www.xbc.nu/brane/
---------------------------------------------------------------------
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

This is an archived mail posted to the Subversion Dev mailing list.