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: 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.)

I would imagine that using the workflow Karl and I presented in
EmacsForBzrDevs, where all real work (including bzr log and bzr status
as well as actual editing) is done in a separate workspace, and the
only thing you ever do in the bound branch is stage changes between
the upstream repo and your workspace, would give you that.  After all,
that's what it is designed to do.

With luck, Robert's patch will pan out and you'll be able to continue
using the bound branch as a local workspace without too much pain.  As
I wrote to Ben, though, my instinct is that it is "abuse", and you
will run into other annoyances.  I hope I'm wrong, because you clearly
would like to continue doing things your way.

 > >  > >  > 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.

That's your choice; there are alternative workflows that would work
better with respect to dirstate locking in current editions of bzr.  I
pointed out one, but there are many.

 > > 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.

Well, that depends on what it wrote to the database, doesn't it?  I
infer from the fact that Robert says he has a patch that whatever it
wrote is not problematic here, so it should be possible to remove the
lock.  Of course, he's not making any promises that it won't destroy
your local branch until it's been tested a little in practice.  I
suppose it's also theoretically possible that corruption in the local
database could be pushed upstream to the bound branch, so maybe you
don't want to test it on your Emacs branches.