Re: [Monotone-devel] [bug #29576] mtn tries to rewrite options file every time

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> Am 17.04.10 13:09, schrieb Stephen Leake:
>>> 2) Only save those options back to _MTN/options which have actually been
>>> given by the user on the command line - this would probably need a little
>>> fiddling with the <someopt>_given flag we set even for options from
>>> _MTN/options (or we leave that alone and find another way to determine which
>>> options have been given by the user and which not). Note that there is also 
>>> a
>>> hook which returns default command options for a command.
>>> Alternatively we could always save back the options to _MTN/options unless
>>> another global command line option is given, f.e. --skip-options-saving or
>>> something similar.
>> 
>> I think "--no-save-options" would be a better name.
>
> Ok.
>
>> A more radical option:
>> 
>> 2b) For an existing workspace, only save the options if some global
>> command line option is given; --save-options. Any command that creates a
>> new workspace, and thus a new _MTN/options, saves options.
>> 
>> This is similar to 'mtn sync --set-default'.
>> 
>> I prefer 2b. I find that the _only_ time I want _MTN/options written is
>> when I first create the workspace, or when I go behind mtn's back and
>> edit _MTN/options directly; all of the other writes of _MTN/options just
>> get in my way.
>
> This is a problem for mtn update or mtn commit - if the current working
> branch is switched (either actively by giving --branch or inactively
> because the revision you update to is on another branch) _MTN/options
> might not get updated.

For update, changing _MTN/options makes sense. Perhaps it should ask the
user to confirm if --save-options is not specified, or fail if
--no-save-options is.

For commit, it may mean I've realized the current work really belongs on
another branch, but I'm going to revert this workspace to the original
branch. Either way, the user should have explicit control of what
happens to _MTN/options.

>> But then there is no way to specify --save-options (short of --norc);
>> why is get_default_command_options hook not overridden by command line
>> options? That means the name is misleading; it's not specifying
>> "default" options, it's specifying "final" options.
>
> This is only partially a problem of the hook. The options system simply
> has no general code to accept --no-<something> options which would
> switch the default of the --<something> value to the opposite.

Ah, right. It would be a lot of work to add that, I guess.

> Also, get_default_command_options() has a bit of a chicken-egg problem -
> the hook needs the name of the command for which it should supply
> options, but we can only get them after we've initially parsed the
> command line and its global options first. Maybe the name is indeed a
> bit misleading then.

There could also be a get_global_options hook, which would be
appropriate for --no-save-options.

-- 
-- Stephe