Comment 6 for bug 98836

For the doing-things-while-commit-editor-is-in-use case, a relatively clean fix is:

1. dirstate-lock the tree, determine the changed files and directories, and calculate a checksum for the overall change (for all I know, bzr does so at this stage already; if not, it certainly could)

2. Release the lock, but remember the checksum, and bring up the commit editor.

3. When the user is done editing, resume the commit, but use the checksum to confirm that the change to be committed is exactly the same one remembered from step 1. If it's not the same, then fail with an error:

  "Someone (maybe you?) changed the tree while you were writing the
  commit message. Your commit message has been saved in foo.txt.
  Please try committing again, after confirming that the exact
  changes you intend to commit are still present."

I agree that ideally, read-only operations would always be possible, and that the overall dirstate lock problem should be solved. But this one particular symptom apparently bites a lot of users, and can be fixed another way pretty easily.