branch locking mk2.

[Robert Collins]

On Wed, 2006-02-15 at 22:09 -0600, John A Meinel wrote:
> 
> There will probably be some control files that are still atomically
> replaced, like revision-history (as long as that exists).
> Also, I don't know how we are trying to keep knit index files intact.
> I'm guessing we just expect that adding 1 line will be an atomic
> action,
> as long as we add less than X number of bytes.
> I can think of some things we could do (like adding a checksum +
> line-length at the beginning of each line, along with a line delimiter
> before the line (a simple newline could do)).
> Then we can throw out index lines that don't match their checksum. And
> the delimiter makes sure that we know where the entries start & stop. 

Right. The index has to be self delimiting and self verifiable as well
as not requiring a full download to retrieve revision references. I
haven't checked if this is the case yet. 

I.e. in the index we if we have
------ 
record A
------
partial record
------
record B
parent: revision in record A
------


firstly the partial record must not be able to confuse the parser.
secondly if I have the revision in record A, I must be able to tell what
it was without downloading its index entry. (Otherwise we scale
O(revisions) rather than (O(delta size))

hg uses the exact sized index records to achieve this AIUI, using file
size mod record size to determine if there is partial records present. 
That scales [with a low constant factor] linearly to revisions though,
which we want to avoid.

Rob

-- 
GPG key available at: <http://www.robertcollins.net/keys.txt>.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: This is a digitally signed message part
Url : https://lists.ubuntu.com/archives/bazaar/attachments/20060216/fbdae213/attachment.pgp