Re: [Monotone-devel] overwriteable and negatable options

[Stephen Leake]

Timothy Brownawell <address@hidden> writes:

> On 06/13/2010 08:25 PM, Stephen Leake wrote:
>> I tweaked a couple comments, and enhanced tests/default_command_options
>> to show that command line options override get_default_command_options.
>>
>> However, the test is failing, because --verbose --no-verbose leaves
>> verbosity set at 1. I tried running in the debugger, but I can't see why
>> that's happening.
>
> The --verbose flag was in it's own optset, which was different from
> the one that the 'verbose' variable was is. So resetting didn't
> actually change the 'verbose' variable. It was in its own optset
> because 'db complete' used it, but since it's global I make 'db
> complete' not specifically take it and put in the same optset as the
> other verbosity options and the variable.

Ah, that makes sense.

Should 'full' also be in the verbosity optset? It's now deprecated, but
it might as well work with --no-verbose, and serve as an example of how
to do this right.

We should have a process for actually deleting deprecated stuff; that
means keeping track of what release it was first deprecated in. Then we
delete it two releases later, or one year later, or something. I guess
we can use mtn annotate for that, but a version field in the macro might
be better. It doesn't have to be part of the message, just a forced
comment that can be reviewed at release time.

I added HIDE on no-prefix, since I introduced that for testing a while
ago.

I think 'move-conflicting-paths' should have
'/no-move-conflicting-paths'; that is one I would like to set in
get_default_command_options. Is there some reason it doesn't?

GOPT(format_dates ...) could be GLOBAL_SIMPLE_OPTION?

I don't think we can change 'without-header', 'with-header' to
'with-header/without-header', because the resetter would also reset
'reverse'. We should probably add a comment about that. Or we could not
have 'with-header' and 'reverse' in the same optset; then they have to
be specified separately in CMD option lists.

Similarly for 'automate_inventory_opts' 'no-unknown' vs 'unknown'
'unknown'; we don't want 'no-unknown' to reset the other
automate_inventory_opts. I don't think this is a problem for these
particular options; we don't need resetters in general for automate
options.

This use of OPTSET for two different purposes (grouping and resetting)
will get confusing.

Would it be possible to specify the reset option name in the OPTSET
macro? That would be clearer. Each optset has a full options_type entry
in all_options, so the resetter could be stored there, rather than with
each individual option.

-- 
-- Stephe