Bazaar dirstate locking (was: lock_* API change)

[Stephen J. Turnbull]

Eli Zaretskii writes:

 > > This should not be a problem.  The only thing you should be doing in
 > > the bound branch is merging changes from another branch.
 > 
 > That's what I do.  But after the merge, I need to commit to the master
 > branch, which is remote, and that takes time.  Since I don't want to
 > mix changesets of unrelated changes, I commit each one by itself, each
 > with its own commit message describing the general idea of the
 > change.
 > 
 > > If you still have problems with that, don't use a bound branch; use
 > > push which will batch the commits into a single push.
 > 
 > I don't understand what you are suggesting here.  Care to elaborate?

Arrgh.  You *really* *really* *really* should be using git, you know.

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.  The best you can do in
Bazaar is something like initialize

bzr init-repo
bzr branch ssh://savannah/emacs trunk
bzr branch trunk work

and let's suppose that "work" is used only for short term tasks.  Ie,
it ends up 100% synchronized to trunk a couple of times a week, at
least.

Then this workflow:

$ cd work
# hack hack hack
$ bzr commit -m "Task #1."
# hack hack hack
$ bzr commit -m "Task #2."
$ cd ../trunk
$ bzr pull ssh://savannah/emacs
$ bzr merge ../work
$ bzr commit -m "Eli's Tuesday shipment of code."
$ bzr push

will give you a separate commit message for each changeset, but *not*
on the mainline.  I gather commits on the mainline are a requirement
for you, so that won't really do.

What you need to do to get log entires for your commits on the
mainline is to do a rebase:

$ cd work
# hack hack hack
$ bzr commit -m "Task #1."
# hack hack hack
$ bzr commit -m "Task #2."
$ cd ../trunk
$ bzr pull ssh://savannah/emacs
$ cd ../work
$ bzr rebase ../trunk
$ cd ../trunk
$ bzr pull ../work
$ bzr push &
$ cd ../work

And now in the work directory you're up-to-date with trunk and your
own work, and are free to do whatever you want without fighting the
locks.  Yes, that's a lot more typing than

$ cd trunk
$ bzr bind ssh://savannah/emacs                # one time only
# hack hack hack
$ bzr commit -m "Task #1."
# hack hack hack
$ bzr commit -m "Task #2."

But the part from the first cd ../trunk to the last cd ../work is
completely standard and scriptable unless you get a merge conflict
when rebasing or pulling, and AIUI that will happen (in a different
way) in a bound branch, too.

 > >  > 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; that should *all* be done in Emacs, saved to a file
(say .msg), and used via "bzr commit -F .msg".  If you want the junk
that bzr commit puts in the message when it calls the editor directly,
AFAIK you can just initialize the file with the output of "bzr ls -R
-V --unknown".

 > >  > 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.  Sometimes it's possible to
do all the expensive stuff offline, without locking the database, and
then lock only for long enough to snap the final link into place.  But
the organization required to accomplish that takes away a lot of
freedom from the database implementers.