Re: [Monotone-devel] nvm.options

[Stephen Leake]

Timothy Brownawell <address@hidden> writes:

> On 07/20/2010 05:44 AM, Stephen Leake wrote:
>> Timothy Brownawell<address@hidden>  writes:
>>
>>> On 07/18/2010 08:19 AM, Stephen Leake wrote:
>>>> Tim,
>>>>
>>>> Just letting you know I've been keeping up with nvm.options, and it all
>>>> looks very good so far.
>>>
>>> I think it's ready to merge now. See anything I missed?
>>
>> The per-command defaults are not there, but that could wait for later.
>>
>> Otherwise looks good.
>
> There's a CMD_PRESET_OPTIONS that's currently only used once (for
> diff). Was there supposed to be something else as well?

Ah. I totally missed that (so much for my thorough review process.
Sigh).

That looks good, and I don't think there are any other options that need
it at the moment.

The options no-unknown/unknown are defined twice - once as

SIMPLE_OPTION(unknown ...)

once as

OPTSET_REL(automate_inventory_opts, no_unknown)
SIMPLE_OPTION(no_unknown ...)

That seems like it could be a problem, but it seems to work.

I went back the the email thread; there is one issue that was brought
up but not resolved:

Change --conflicts-file/--resolve-conflicts-file/--resolve-conflicts to:

   --resolve-conflicts             resolve conflicts non-interactively
   --resolve-conflicts-file <arg>  use the given file instead of _MTN/conflicts

dropping --conflicts-file.

But I think that's best left for another time.

We need a NEWS entry, and something in monotone.texi. How about this:

NEWS
        New Features

        - Options can now be overridden; you can specify --no-unknown
          --unknown on the command line. Similarly, you can specify
          --no-unknown in the get_default_command_options hook, then
          change it to --unknown on the command line.

monotone.texi, in Command Reference header:

    Many command options come in pairs that affect the same value. For example,
    @command{mtn log} takes a @var{brief} option; this can be reversed by
    @var{no-brief}. This is convenient when building command strings
    automatically; @command{mtn log --brief --no-brief} is the same as
    @command{mtn log}.

    It also helps when setting options in the
    @var{get_default_command_options} hook; those options can be
    overridden on the command line. For example, if
    @var{get_default_command_options} specifies @var{brief} for
    @command{log}, you can override that with @command{mtn log
    --no-brief}.

    The command descriptions describe the most important options for each
    command, and only one of each pair of options. For a complete list of
    options, see the online help (@command{mtn help cmd}), or the manpage.


We could modify the description of _every_ command that now has a
resettable option. Tedious, but do-able. But perhaps we should consider
generating the command options from the help texts, automatically? This
would be a modification of the 'mtn manpage' command. That way the info
manual would be as complete as the online help.

Or maybe it's ok as is.

I scanned thru the Tutorial; I did not see a good place to use an
overridden option. I don't think we want to specify the
get_default_command_options hook in the tutorial.

--
-- Stephe