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

[Stephen Leake]

Zack Weinberg <address@hidden> writes:

> On Mon, Apr 19, 2010 at 3:52 PM, Stephen Leake
> <address@hidden> wrote:
>>>
>>> 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.
>
> I think we can probably come up with a list of operations (*not*
> necessarily a list of commands) that should modify the workspace, and
> say that nothing else does; 

Yes.

> but only writing it with a special option goes against user
> expectations 

Not this user :).

> and makes the shell command interface less usable. Things like "mtn up
> -r <revision not on the current branch>" really must continue to
> modify _MTN/options.

I never do that; it's not part of my workflow. My workflow strongly
identifies root directory names with branch names; changing the branch
of a workspace violates that, and introduces hard to find bugs. We just
had an instance of this at work; it took a couple hours before we
realized that one workspace had the wrong branch in it.

I do "mtn up -r", but if the revision is accidently from a different
branch, I'd like mtn to fail with an error about changing branches (to
catch accidental violations of the workflow), and require an explicit
option to make it work (to recover from violations). In this particular
case, --branch would make sense, but so would --save-options.

We'll never truly satisfy _all_ users with the default interface. But
that's what automate and Lua are for; we each get to customize to get
what we want. So as long as the base system allows complete
customization, I'll be happy.

In that vein, I'd like to be able to say "never overwrite _MTN/options
unless I give explicit permission". That will help find violations of my
workflow, and simplify working with NFS mounts. --no-save-options comes
close to that; I can put it in get_default_command_options. But then I
need a better way to give explicit permission; currently I have to say
--norc, which is overkill. Allowing --save-options to override the
earlier --no-save-options would be good.

In my Emacs front end, I have a list of options that are always
specified for mtn commands; in that case, giving explicit permission
means temporarily deleting --no-save-options from that list. Adding
--save-options would be simpler.

So I guess I'll add this to my todo list; implement a general
--[no-]<boolean_option> mechanism. Then the sequence --no-save-options
--save-options gives permission to write _MTN/options.

-- 
-- Stephe