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