Solving the commit-editor-locks-stuff-up problem.

[Karl Fogel]

When 'bzr commit' brings up a commit message editor, bzr takes a
dirstate-lock for the duration of the editing session, thus preventing
other uses of the tree.

This is one symptom of http://bugs.launchpad.net/bzr/+bug/98836, but
it's a particularly visible symptom that multiple users have noticed.

In http://bugs.launchpad.net/bzr/+bug/98836/comments/6, I've outlined a
solution that I think would be pretty easy to implement.  Can we do
something like this, and get this user-visible bug out of the way?

Here's the proposal: When the user runs 'bzr commit', we

  1. Take out the dirstate-lock, 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."

Ideally, read-only operations would always be possible, and the overall
dirstate lock problem needs to be solved.  But this one symptom bites a
lot of users, and could be fixed this other way.  Let not the perfect be
the enemy of the good, and all that.

Thoughts?

-Karl