The fix branch for this is merged now.

please don't make 'disapprove', or any other db command, affect the current workspace.

I often perform operations on the database from a workspace, just so I don't have to specify --db or --branch. But that doesn't mean I want that workspace changed.

This is one of the best features of monotone; separating repository operations from workspace operations. Let's keep it that way!

Your workflow is not my workflow; mtn should let us each customize things to support our own workflows nicely.

If your workflow does want some db commands to update the workspace, we need an --update-workspace option to enable that.

And, in general, support for option overwriting via --[no-]*, so you can put --update-workspace in the defaults, and override it on occasion.

Or the ability to write Lua wrappers to do the merge and update; that requires 'automate merge' (we have 'automate update').

For the original issue of avoiding unwanted divergence, change your workflow to always do 'mtn status; mtn heads' before 'commit'. Maybe 'status' could be enhanced to show heads info. Better to implement 'automate commit', and write a Lua wrapper to do the status display and user query before commit.

Oh, hm, it doesn't.

I don't particularly like the idea of making 'commit' become unpredictably interactive. It means there's an extra step between "commit, go back to coding" which is "wait to see if 'commit' asked anything", and it breaks "run 'make check && mtn ci -m foo && mtn sy', go do something else for a while while that runs", and it just doesn't seem that good an idea to have it be "you have to watch this to see if it needs input, but it usually doesn't".

So that leaves the other option, having 'merge', 'disapprove', 'merge_into_dir', 'propagate', and maybe 'explicit_merge', 'pull', 'sync', 'approve', and 'suspend' update the workspace (and take a --no-update flag to turn this off). But I like having things be orthogonal too (and suspect it helps with learning the concepts), and this would break that somewhat.

I suppose practicality is probably more important here than prettiness, so what would be good criteria for updating? Say, the base revision goes from being a head to not being a head (if it's already not a head, presumably the user did 'update -r ...' and wants it to stay there) and doesn't contain any uncommitted changes (making them possibly go through conflict resolution when they didn't ask for it seems impolite)? This still leaves the potential for confusion from having multiple workspaces (only one would be updated) and different behavior of non-workspace commands based on being in a workspace and on accidentally not being at a head revision (say because your last pull was done outside a workspace). Does the extra convenience outweigh the potential for extra (different) confusion?

I suppose I'll add '--update' and '--no-update' flags for those commands, and we can go bikeshed later on which should be the default.

+1 for that, but I'd personally wait with the second point until Derek landed the changelog editor branch in mainline (or if you want to go for it, base your work on his branch).