bzr, rsync, and atomic operations

[John Arbash Meinel]

Matthieu Moy wrote:
> Hi,
> 
> I'm wondering how bzr operations support concurrent accesses. For
> example, what happens if someone does a "branch" or a "pull" from a
> branch, if I do a "commit" or a "push" at the same time.
> 
> AFAIK, rsync is atomic file-wise, but not for the complete directory.
> 
> So, what's the situation? Are concurrent read-write accesses
> supported? If not, is it in the TODO list?
> 
> Thanks,
> 

Well, for bzr, almost all writes to a file are done through "AtomicFile"
which means it writes to a temporary and copies it across.

It locks/unlocks ".bzr/branch-lock" to prevent multiple bzr processes
from stepping on each other.

In the older v4 version of storage, it would fill the text-store, then
create the inventory entry, then create the revision entry, then update
.bzr/revision-history.

Which meant that if it was interrupted somewhere, you would end up with
extra stuff (an extra text-store entry, extra inventory-entry, etc), but
that wouldn't propagate up as a branch change (since revision-history
wasn't modified).

This should still be true with the weave format, so the text weaves are
updated to add a new entry, then the inventory.weave is updated, then an
entry is added to the revision-store, and finally the revision-history
is updated.

If we were using a "smart" rsync to do the pull, it would pull in the
opposite order (get .bzr/revision-history, then all files in
revision-store, then inventory.weave, then all text weaves).
Which would guarantee a consistent view, even without locking. However,
without that, I think it would be possible to pull .bzr/revision-history
after it was updated, but to have grabbed the text weave before it was.
(If you start pulling the weaves, then they are updated, and before you
are finished, .bzr/revision-history is done).

So basically, I want to say that *local* accesses should all be properly
serialized because of .bzr/branch-lock (read and write locks are taken
as appropriate).

bzr branch and bzr pull should both work correctly, since they operate
in the correct order (revision-history, then revision-store, then
inventory, etc).

I have a plugin that provides "bzr rpull" which uses rsync. I probably
should update that to make sure it does the updates in the correct order.

But yes, if you are using raw rsync it might be possible to get an
inconsistent state.

John
=:->
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051013/ef9aad83/attachment.pgp