recreatable indices, knits in pack repos, and pull speed

Robert Collins robertc at
Sun Aug 5 23:10:47 BST 2007

So with the pack repo fully functional I'm now looking at making the
indices recreatable from the .pack. There are roughly two sorts of
changes here.

The first sort is a trivial transformation - take a copy of the parents
and line ending information, and put it in the .pack *somehow*. This
doesn't change what we consider derived vs core data, but it does make
the index explicitly non-precious. So we can try different index
schemes, we can try getting the graph data directly from the pack (as
long as the move of data to the pack was sufficiently well done that
there isn't a big performance overhead attempting that - beyond the
obvious extra IO). More on this below.

The second sort of change is to alter what we currently record to make
things like the per-file graph completely reconstructable - or flag it
as reconstructable for given revisions, or something. And actually stop
recording the per-file graph completely, making it up on demand instead.
I'm not quite ready to tackle this - my feeling is that the indices
should be optional before doing this.

To move data into the knits hunks in the pack, there are several
approaches I've thought of so far:
 - write a B record before the knit zip hunk, with the information
needed there.
 - write a line with the information before the knit zip in same B
record in the pack
 - alter the knit zip to contain the information as part of the knit zip

I think the third option is really the cleanest, but I'm worried about
the overhead of decompressing and recompressing - it will make push-pull
comparisons harder than they are today, because rather than having the
same source format and different targets, one will need to pull natively
between two pack repos to avoid the transcoding overhead.

And as I think its nicer to the user to do recompression at 'pack' time,
not arbitrary pulls, I'm wondering if I can avoid that transcoding


GPG key available at: <>.
-------------- 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 : 

More information about the bazaar mailing list