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

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Robert Collins wrote:
> ...the simplest
> way forward here is to fix the root cause, not work around it - the good
> and the perfect are in harmony.

I think there are a couple of candidates for "root cause".

One is that we acquire the commit message late in the process.  We
introduced that behaviour because some users complained that if a commit
failed, their carefully-typed message wasn't used.  If we acquired the
commit message before taking out the tree lock, we could address many of
these use cases.  And we could cache the commit message and
auto-populate the editor with it next time.  The downside is that we
would be unable to show status or diff information in the commit window.

If we assume we want to continue doing late prompting, another possible
root cause is dirstate's design.  AIUI, the goal was to allow in-place
rewriting of the dirstate, but no client has ever implemented it.  If we
just drop the os lock, retaining the directory-based lock, will we risk
any data integrity?

Do we even need the tree lock?  We certainly don't need to read from the
user files by that point, because the revision is almost entirely
committed.  We do need to write, however-- we need to update the tree
last-revision and the parent trees.  That means rewriting the dirstate.
 Would it be enough simply to detect changes to the dirstate file and
abort if substantive changes are made?  I imagine just reading the
dirstate file is cheap enough.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.9 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEARECAAYFAknEQ8MACgkQ0F+nu1YWqI25SQCdEpOrVomAFIN+W4OI0I1flC+E
2MQAoIQRO23CG4RrkThzuxz5F8RSWPhX
=5pvv
-----END PGP SIGNATURE-----