Bazaar dirstate locking (was: lock_* API change)

[Eli Zaretskii]

> From: "Stephen J. Turnbull" <stephen at xemacs.org>
> Cc: robertc at robertcollins.net,
>     bazaar at lists.canonical.com,
>     monnier at iro.umontreal.ca
> Date: Sun, 16 May 2010 16:37:32 +0900
> 
> You're right, if that's the way you want to do things, it's going to
> be very hard to do it efficiently in Bazaar.

Is there any "other way" to do things, which still puts all the commit
messages on the mainline in the master repository, and doesn't use
rebase?  (I don't want to use rebase because I still want to see all
my local commits as branches from mainline, once I merge and commit to
the master repository.)

>  > >  > 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.
> 
> I don't understand why bzr is involved at all when you are editing the
> commit message

Because I invoke "bzr commit" from outside Emacs, and edit the message
when it pops via emacsclient.

>  > >  > And dirstate is locked for all that time.
>  > > 
>  > > dirstate needs to be locked until a commit is complete.
>  > 
>  > I don't see why.  I especially don't see why it needs to be locked for
>  > readers, such as "bzr status" and "bzr log".
> 
> Huh?  For the same reason you always lock a database when writing to
> it: it's inconsistent until you're done.

When writing to the database, yes.  But why is it locked while bzr is
waiting for emacsclient to return?  bzr does nothing during this time
but wait.