DOCS Bundle format 4 aka 1.0alpha
Martin Pool
mbp at sourcefrog.net
Fri Jun 22 07:13:56 BST 2007
On 6/22/07, Aaron Bentley <aaron.bentley at utoronto.ca> wrote:
> ===============
> Bundle format 4
> ===============
I think you could add an overall summary of how things fit together.
If I understand correctly that is:
a merge directive contains:
* a merge command
* an overview diff (optionally?)
* a base-64-encoded bzipped bundle which is a
* container file which contains a series of records, each with a
storage type and name, and containing some headers
* one info record
* file records
* inventory records
* revision records
* signature records
It sounded on irc like you decided not to store the testaments?
> Format 4 records revision and inventory records in their repository
> serialization format. This minimizes translation and compression costs
> in the common case, where the sender and receiver use the same serialization
> format for their repository. Steps have been taken to ensure a faithful
> conversion when serialization formats are mismatched.
I think current inventory and revision records have their own version
marker at the start. You could check that when inserting them and we
should make sure we continue with that in the future.
> The bundle format subdivides a pack record body into a bundle header and body.
> The header contains a Bencoded dict of values. It is separated from the body
> by a newline.
>
> :record_kind: The storage strategy of the record. May be "fulltext" (the
> record body contains the full text of the value), "mpdiff" (the record body
> contains a multi-parent diff of the value), or "header" (the record body is
> empty).
> :parents: Used in fulltext and mpdiff records. The revisions that should be
> noted as parents of this revision in the repository. For mpdiffs, this is
> also the list of build-parents.
> :sha1: Used in mpdiff records. The sha-1 hash of the full-text value.
These headers seem somewhat redundant with the container names, except
that the latter can be indexed and are required to be unique. I
wonder if that's a useful distinction? At any rate having your
headers here probably makes sense for now.
--
Martin
More information about the bazaar
mailing list