branch locking mk2.

[Robert Collins]

On Thu, 2006-02-16 at 00:37 -0600, John A Meinel wrote:
> This sounds like you are just downloading the last X bytes from the
> remote knit. Is that how you are guessing what data you need?

As a current sketch, yes. Essentially read a good guesstimate from the
end and if that fails work back in larger and larger blocks. http tells
you the size on the first read, so we could in some cases jump to
reading the entire remaining index. 

its roughly a loop: 
 we want revision X to be constructed locally:
   find revision X in the index by reading end to start 
   do we have all X's ancestors in our weave yes: done, insert X
                                             no: push the ancestors into
a queue of needed revisions and continue.
   
I'm going to spend some time with Martin tomorrow and see if we can get
some traction on the points you've raised - right now I'm up to my
armpits in upgrade(). 

Also note that I think we could not optimise for say 4-5 months with no
concerns. But I do think that having a format that lets use optimise
when we choose to would be very very cool.

As for revision id references in the annotations, I suggest that:
 * a delta against the previous text will preserve its mapping table
 * we can update the mapping table of the previous revision as part of
the delta.

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/f80c0dee/attachment.pgp