Issue 75: Cached workspace files between consecutive executed workspace commands

Reported by Thomas Keller, Feb 1, 2010

(This entry was imported from the savannah tracker, original 
location: https://savannah.nongnu.org/bugs/index.php?28789)

If two workspace commands are executed consecutive via stdio and 
data have been changed in the meantime by an external process (f.e. 
bookkeeping files such as _MTN/options or .mtn-ignore), the second 
command won't see the updated values.

For .mtn-ignore the problem is the ignore_file() lua hook which 
caches the once read .mtn-ignore file for the whole session.

For _MTN/options the problem cannot be fixed easily since the 
workspace ctor has to get a flag if it should or should not write 
back options to _MTN and several automate commands (f.e. automate 
select) cannot change this behaviour themselves because they call 
into common code paths (f.e. selectors.cc, the h: selector).

monotone version:
-----------------
mtn 0.46 and all versions before

Comment 1 by Thomas Keller, Apr 19, 2010

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