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

[Thomas Keller]

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

signature.asc
Description: OpenPGP digital signature