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

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> Follow-up Comment #1, bug #29576 (project monotone):
>
> I understand where you're heading - but the problem is the underlying
> "architecture" of this feature. _MTN/options is supposed to save options which
> the user entered on command line to avoid that he has to enter them again -
> while it makes no difference for it whether or not the triggered command has a
> readonly-style or even needs the listed options in _MTN/options or whether the
> usage of an option would even be considered harmful (f.e. mtn status -d
> path/to/other.db ends up rewriting _MTN/options even if the other db does not
> (!) contain the base revision of the workspace).
>
> So if anybody wants to pick that up, we should discuss how we improve the
> situation here. I'd propose two changes:
>
> 1) Save any given options back to _MTN/options at the very end of the
> execution (f.e. in monotone.cc) _after_ it has been clear that no exception
> occurred - so we don't remember possibly harmful settings.

This certainly makes sense.

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

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.

Use case for editing _MTN/options directly: a workspace is on a target
disk, NFS mounted to either a Windows box or a Linux box. The absolute
paths to the database and keydir are different for the two NFS mounts.
However, "~/..." works in both cases. But if I manually set it to
"~/...", mtn happily overwrites that with the (wrong) absolute path.

I suppose --no-save-options is more backward-compatible, and I could put
it in my get_default_command_options hook. 

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.

-- 
-- Stephe