monotone-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Thomas Keller
Subject: Re: [Monotone-devel] [bug #29576] mtn tries to rewrite options file every time
Date: Sat, 17 Apr 2010 14:34:38 +0200
User-agent: Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; de; rv:1.9.1.9) Gecko/20100317 Lightning/1.0b2pre Thunderbird/3.0.4

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.

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

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.

Thomas.

-- 
GPG-Key 0x160D1092 | address@hidden | http://thomaskeller.biz
Please note that according to the EU law on data retention, information
on every electronic information exchange might be retained for a period
of six months or longer: http://www.vorratsdatenspeicherung.de/?lang=en

Attachment: signature.asc
Description: OpenPGP digital signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]