Bazaar dirstate locking

[Eli Zaretskii]

> From: Ben Finney <ben+bazaar at benfinney.id.au>
> Date: Mon, 17 May 2010 10:17:37 +1000
> 
> Eli Zaretskii <eliz at gnu.org> writes:
> 
> If you want to shift that time outside the transaction, Stephen gave an
> alternative workflow: edit the message, save it to a file (e.g.
> ‘bzrcommit’), *then* invoke commit as ‘bzr commit --file "bzrcommit"’.

Sorry, that's entirely backwards, and on top of that it burdens me
with taking care of temporary files, instead of letting Bazaar handle
that.  This alternative is fine as a fire escape, but I really don't
like tools that force me using it as a main workflow.

> > >  > 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?
> 
> Because the “commit” transaction has already begun. The database is
> locked until that transaction completes.

Sounds like a bad misfeature to me.  Again, I'm talking about readers
only.