Re: [Monotone-devel] Re: [bug #28789] Cached workspace files between consecutive executed workspace commands

[Stephen Leake]

Thomas Keller <address@hidden> writes:

> Am 19.04.2010 13:37, schrieb Thomas Keller:
>> 
>> Follow-up Comment #1, bug #28789 (project monotone):
>> 
>> From revision 0db915193923a54f43d91a67688e2fc4f8641683 the situation is now a
>> little different, but not better for _MTN/options:
>> 
>> If a stdio instance runs and f.e. the branch in _MTN/options changed from
>> some.branch to some.other.branch, then the first execution of
>> 
>>   l10:get_option6:branche
>> 
>> returns (correctly) some.other.branch, but also directly overwrites
>> _MTN/options again with the wrong (old) branch some.branch, so that the next
>> execution of this command returns some.branch again.
>> 
>> We have a little chicken-egg problem here - one the one hand we want to reset
>> the (global) options for a command back to the original values (so if command
>> 1 changes some global option, command 2 does not suffer its setting and 
>> cannot
>> even undo it, f.e. --ignore-suspend-certs), on the other hand we want the
>> original options get updated when the "outside" world, f.e. _MTN/options
>> changes...
>
> To discuss this issue a little further, maybe its not really a
> chicken-egg, but a consistency problem, because we'd f.e. treat the
> change of the database of a workspace differently:
>
> 1) if the db is changed via _MTN/options, we'd pick it up for the first
> command following the change and then (errornously) revert it back to
> the original value
>
> 2) if the db is changed via global option (o1:d7:foo.mtne), we'd
> correctly only use it for the particular command and fall back to the
> original value for any next command, unless the executed command is now
> a workspace-using one - then we (errornously) save the db option to
> _MTN/options and re-use it for the next command, obviously the options
> were resetted previously.
>
> ...
>
> Even worse now as soon as the stdio process itself is closed, the
> original program options are saved back to _MTN/options, so the database
> is reset to /home/tkeller/private/test.mtn again...

I think the guiding principle should be that sequential automate stdio
commands should have the same result as the same/equivalent commands
executed from the command line in a bash shell.

> I could surely prevent that the last thing happens, 

That would be good.

> but I'm unsure if all this implicit _MTN/options changing should
> happen at all for automate commands (maybe there should be an
> equivalent to get_option, named set_option if we really want to write
> back command options...?)
>
> Clearly, all this options-changing-related code gets more and more messy
> and unmaintainable the more we hack on it :(

Which argues for my suggestion; never write the _MTN/options file,
unless creating a new workspace, or global option --save-options is
given. Both cases should affect subsequent automate stdio commands.

A separate set_option automate command might be useful, but less
consistent with the shell command-line behavior. It could have a
non-automate version, I suppose. Or perhaps you are suggesting that we
should have set_options command, but not --save-options global option;
no command should write to _MTN/options?

-- 
-- Stephe