bzr pull when someone is updating repository

John A Meinel john at arbash-meinel.com
Fri Nov 11 15:01:41 GMT 2005


John Yates wrote:
>> When updating a branch (with commit or push), the first thing updated is
>> each individual text weave. Weaves are updated by creating a new one,
>> and renaming it into place, which should be atomic on most systems.
> 
> What happens if there are two updates occurring in parallel?  Devo A
> creates new weave WA from W0, devo B creates weave WB, devoid of any
> devo A edits.  Devo A successfully performs his rename.  What happens
> when devo B attempts a rename a moment later?

When doing a push or commit there is a lock taken out.
On the local system this is just an OS lock on .bzr/branch-lock, over
remote this is creating the file .bzr/branch-lock.write-lock in an
exclusive mode.

The reason they aren't the same is because it is rare that people will
access a branch both locally and from remote at the same time. We might
clean that up, but with the OS lock, it will clean itself up if the
process dies, a remote lock will just stay there.

> 
>> After that, the inventory is written (so that you can reference the new
>> texts), and that weave is atomically replaced.
>> Next, the revision-store is updated with the new revision information,
>> and the last step is to update the revision-history to include this new
>> revision.
>>
>> The way you prevent corruption when downloading is by getting the files
>> in the reverse order.
> 
> As a low-level programmer who has had to wrestle with weakly-ordered
> memory systems I must point out that this strategy implicitly assumes
> ordering properties that may or may not be satisfied by the combination
> of communication channel and server file system.

Are you saying that if I do a rename, the server may give an old version
of the file? I realize that on a windows filesystem we may have to get a
 lot more creative (since rename cannot overwrite an existing file, and
you can't delete an open file). We do have some other ideas in the
pipeline. But I'm curious what you specifically feel we are missing.

John
=:->


> 
> /john


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 249 bytes
Desc: OpenPGP digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20051111/b9d01861/attachment.pgp 


More information about the bazaar mailing list