packs and knits

Robert Collins robertc at robertcollins.net
Thu Aug 2 05:39:29 BST 2007


I'm starting to look at making the pack indices completely optional.
This is simply expressed as:
"Given a pack a correct, complete, index can be created from it."

Now the indices currently contain data that isn't in the knit raw
records - the parent data and compressed-against pointer specifically.

So there are some options:
 - put the versionid, parent and compression meta data into the knit raw
records
 - put that data into the pack names 
 - add a new pack type that can store more complex headers
 - put the parent and compression metadata into a separate pack record
that is adjacent to the one it describes

There are in my view several sets of data here. There is data about the
raw record - 'it is the data for getting the text (fileid, revision)'.
And there is data about using the raw record - 'It was compressed
against the text (fileid, revision)'. And finally there is derived data
(or derived in principal) - 'the per file graph parents for this are
(list of parents)'.

Now, we don't want derivable data in the packs *eventually*, but I think
a good start would be to get to the point of having optional indices.
Then we can work on making semi derived data cleanly rederivable.

Now, currently there can only be one representation of a knit delta to
construct a given text, so it makes sense to me to name the record
('text', fileid, revisionid). (for a revision knit that would be
('revision', revisionid, etc) - just namespacing.

However the compression details and parent details are not clear to me
as things usefully or accurately summarised, and definately the former
is not needed unless one is actually decompressing. The parent details
are more useful for commit - but currently we index those so I'm
comfortable putting both the parent and compression information into the
knit record data itself, not as a name.

If this makes sense I'll put a patch together to do a Pack version bump
and API bump to allow tuple based naming. If it all makes sense but that
bump doesn't seem nice, I'll escape tuples down into names instead.

-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/20070802/0bfeb1d5/attachment.pgp 


More information about the bazaar mailing list