Bazaar dirstate locking (was: lock_* API change)

[Robert Collins]

I think it may help to clarify things a little; I'll touch up the bug
when I'm not travelling.

There are three objects bzr distinguishes in most user operations:
WorkingTree
Branch
Repository

They have some differences when it comes to locking (discussing our
primary core code only):

WorkingTree:
 - uses an OS lock on *reads* on the .checkout/dirstate file. I have
an experimental branch that drops this lock, and fixes the bug in
question. It needs polish and testing but seems promising. So far I've
received zaroo feedback about it.
 - currently single writer no readers or many readers. The above
mentioned branch (which is linked to the bug earlier in this thread, I
think - if not, look for 'dirstate2') changes that to singler writer,
many readers

Branch:
 - reads are unlocked, the object layer takes care of providing a
consistent view of the data
 - writes take out a long lock for the duration; changing the branch
tip is something we don't want races on.
 - single writer, many readers

Repository:
 - reads are unlocked, the object layer takes care of providing a
consistent view of the data and catching up with transactions
committed during a read only operation by another writer.
 - writes spool an atomic change and take a fine grained lock to
insert the change into the repository
 - many writers many readers

That is - we totally support highly concurrent use of a single
repository locally or over the network; we support only one person
pushing to a single *branch* at a time whether locally or remotely,
and we have a bug where a writer in a working tree (which includes
commit) locks out all readers and also enforces local-only access to
the working tree.

I'd be delighted to mentor someone working through the rest of the
work needed to close this bug off; I may get to it in slack time
myself - its a pretty annoying limitation.

HTH,
Rob