branch locking mk2.

[Jan Hudec]

On Wed, Feb 08, 2006 at 14:01:26 -0600, John A Meinel wrote:
> Jan Hudec wrote:
> > There is this one issue that the locking does not solve, though. In
> > Arch, the lock directory was used as a staging area. So breaking it
> > actually destroyed the data prepared there, so the lock could always be
> > safely broken. Ie. it was really a transaction.
> > 
> > Now bzr still needs the ability to break stale locks -- with no safe way
> > to recognize a stale lock. Therefore it IMHO needs a way to make sure
> > the repository does not break even if it accidentaly breaks a non-stale
> > lock. Which the locking scheme by itself does not solve.
> 
> Yes, this is an issue. Robert's proposal at least has the ability that
> the bzr process which did the locking can be aware that it lost the lock.

Unfortunately it may still do some operations before it notices.

> We would have to redesign the storage layer to get transaction style
> locking. Which has been discussed, but has other tradeoffs.

Well, as long as weaves are used, full weave must be written each time,
so it would be possible to upload it to the lock directory and then move
it in place. That will be harder when knits go in.

However it's OK to require that some cleanup is done when you are
breaking a, hopefully stale, lock. Perhaps somethink like the following
would work:

 The writer moves file it writes to to the lock, modifies it there and
 moves it back.

 Reader knows that if it can't find a file that should be there, it
 should look at the lock and wait for it or read it there.

 Whoever breaks the lock must copy the correct data (for knits the head)
 to the new lock, so if the writer still has the old file open, it won't
 cause any harm.

But maybe the knits can really be safely manipulated by just carefuly
ordering the writes to the knit and the index.

-- 
						 Jan 'Bulb' Hudec <bulb at ucw.cz>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060209/de32aa71/attachment.pgp