bzr info -vv statistics display

[Eric Siegerman]

On Tue, 2011-02-08 at 05:24 -0500, Eli Zaretskii wrote:
> Btw, "bzr break-lock" says that "bzr info" can be used to show locks.
> Is that still true?  I couldn't see any locks no matter how many times
> I invoked "bzr info", but maybe that's because no one committed
> anything in that period of time.

I just tested this by typing "bzr commit" in one window and then,
while the log-message editor was open, trying "bzr info -v" in
another.  In 2.3.0, that dies of:
    bzr: ERROR: Could not acquire lock \
        "/tmp/bt/a/.bzr/checkout/dirstate": \
        [Errno 11] Resource temporarily unavailable

Not exactly what the docs contemplate, but it does inform you :-/

I then killed the commit and message-editor processes, after
which "bzr info -v" said:
    Lock status:
      working tree: locked
            branch: locked
        repository: unlocked

and "bzr break-lock" duly broke both locks, after asking my
permission for each in turn.

Attempting to "bzr break-lock" while a(nother) commit is still
waiting for its log message yields:
    bzr: ERROR: The lock for '/tmp/bt/a' is in use and cannot \
        be broken.

So it's smart enough to only break stale ones.  That at least is
very reassuring.


BTW, the combination of locks held by a commit at the
prompt-for-log-message state makes sense.  One wouldn't want two
simultaneous commits, at any stage, to the same branch/wt.

The repo, however, is (potentially) shared among many branches,
and one doesn't want a user typing a log message in one to block
commits to all of them.  I believe how that works is that once
the log message is available and the commit can proceed, it
writes the new revision to a new, one-revision pack file and
corresponding index files (in .bzr/repository/packs and
.../indices respectively), without locking; then locks the repo
only momentarily while it adds that new pack to the master list
in .../pack-names.

The same goes for a pull or merge from a branch that's backed by
a different repo, but only one new pack need be created, no
matter how many revisions are being brought in.  (IIUC, pull and
merge when both branches are in the same shared repo don't
involve any repository updates in the first place, so the
repo-locking question doesn't arise.)

Autopacking later coalesces those tiny pack files into fewer,
larger ones, thus keeping the total number of live packs under
control.

  - Eric