Thomas Keller <m...@thomaskeller.biz> 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 _______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel