Bazaar dirstate locking (was: lock_* API change)

[Stephen J. Turnbull]

Eli Zaretskii writes:
 > > From: "Stephen J. Turnbull" <stephen at xemacs.org>
 > > Cc: robertc at robertcollins.net,
 > >     bazaar at lists.canonical.com,
 > >     monnier at iro.umontreal.ca
 > > Date: Sat, 15 May 2010 21:19:42 +0900
 > > 
 > > When you write "commit", do you mean *commit* or do you mean *push*?
 > 
 > I mean "bzr commit", but when I send my changes upstream, I do that in
 > a bound branch.

This should not be a problem.  The only thing you should be doing in
the bound branch is merging changes from another branch.  If you still
have problems with that, don't use a bound branch; use push which will
batch the commits into a single push.

 > When I commit to a local branch, it is indeed much faster, but still
 > far from microseconds, even if I don't take my time editing the commit
 > message.  And dirstate is locked for all that time.

dirstate needs to be locked until a commit is complete.  In principle
you could shave some off that on both ends, but it's not going to be
easy.

AFAICS, dirstate should not need to be locked for a push, except that
you need to be able to read the revid of the tip.  Once you have the
revid, I guess you have to read-lock the packs which could mean (a) no
repacks until unlocked, or (b) along with the revid of tip you need a
list of pack files and corresponding index files (a few extra
microseconds to read that list) and they can't be deleted until you're
done with the push.