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. This is an example session which illustrates problem 2 (no _MTN/options are changed manually): l10:get_option8:databasee 1:m:31:/home/tkeller/private/test.mtn 1:l:1:0 o1:d34:/home/tkeller/private/monotone.mtne l10:get_option8:databasee 2:m:31:/home/tkeller/private/test.mtn 2:l:1:0 l10:get_option8:databasee 3:m:35:/home/tkeller/private/monotone.mtn 3:l:1:0 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 could surely prevent that the last thing happens, 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 :( Thomas. -- GPG-Key 0x160D1092 | tommyd3...@jabber.ccc.de | 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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Monotone-devel mailing list Monotone-devel@nongnu.org http://lists.nongnu.org/mailman/listinfo/monotone-devel
