|
Size: 2306
Comment:
|
Size: 1444
Comment:
|
| Deletions are marked like this. | Additions are marked like this. |
| Line 1: | Line 1: |
| This page describes the second iteration of the bundle format, tentatively called HG19 (since we hope to include it with Mercurial 1.9). | <<Include(A:dev)>> |
| Line 3: | Line 3: |
| Bundles consist of the following sections: * A bundle header, describing the version and features present in the data. * Changegroup sections for the changelog, the manifest and each relevant filelog. * Optionally, a footer containing an index for more efficient random access? |
This page describes the current plan to get a more modern and complete bundle format. (for old content of this page check [[BundleFormatHG19]]) |
| Line 10: | Line 7: |
| == Sections == For each section, the offsets are given relative to the beginning of the section. Fields with unknown length are assigned constants a, b, c etc. |
(current content is copy pasted from 2.9 sprint note) |
| Line 13: | Line 9: |
| === Header === The bundle header has the following format: |
=== New bundle format === |
| Line 16: | Line 11: |
| || '''Offset''' || '''Size''' || '''Type''' || '''Description''' || ||<)> 0 ||<)> 4 || string || Bundle format version. Always contains "HG19". || ||<)> 4 ||<)> 2 || string || Compression type. Either "BZ", "GZ" or "UN". || ||<)> 6 ||<)> 4 || uint || Length of feature string, in bytes. || ||<)> 10 ||<)> a || string || Bundle features (or requirements). A list of newline separated strings describing features present in the bundle (unterminated). || |
* lightweight * new manifest * general delta * bookmarks * phase boundaries * obsolete markers * >sha1 support * pushkey * extensible for new features (required and optional) * progress information * resumable? * transaction commit markers? It's possible to envision a format that sends a change, its manifest, and filenodes in each chunk rather than sending all changesets, then all manifests, etc. capabilities |
| Line 22: | Line 27: |
| === Changegroup sections === The changegroup sections has the following format: |
=== New header === |
| Line 25: | Line 29: |
| || '''Offset''' || '''Size''' || '''Type''' || '''Description''' || ||<)> 0 ||<)> 4 || uint || Number of changelog entries. || ||<)> 4 ||<)> b || group || Changegroup containing changelog entries. || ||<)> b + 4 ||<)> 4 || uint || Number of manifest entries. || ||<)> b + 8 ||<)> c || group || Changegroup containing manifest entries. || ||<)> b + c + 8 ||<)> 4 || uint || Number of filelog changegroups (note: not the number of entries). || |
{{{#!C type Header struct { length uint32 lNode byte node [lNode]byte |
| Line 32: | Line 35: |
| Then, for each filelog, the following: | // if empty (lP1 ==0) then default to previous node in the stream lP1 byte p1 [lP1]byte |
| Line 34: | Line 39: |
| || '''Offset''' || '''Size''' || '''Type''' || '''Description''' || ||<)> 0 ||<)> 4 || uint || Number of filelog entries. || ||<)> 4 ||<)> 4 || uint || Length of filename, in bytes. || ||<)> 8 ||<)> d || string || Filename (unterminated). || ||<)> d + 8 ||<)> e || group || Changroup containing filelog entries. || |
// if empty, nullrev lP2 byte p2 [lP2]byte |
| Line 40: | Line 43: |
| == Changegroups == ... |
// if empty, self (for changelogs) lLinknode byte linknode [lLinknode]byte // if empty, p1 lDeltaParent byte deltaParent [lDeltaParent]byte } }}} We'll modify the existing changegroup type so it can pretend to be a new changegroup that just has a variety of empty fields. Progress information fields might be optional. ---- CategoryNewFeatures |
Note:
This page is primarily intended for developers of Mercurial.
This page describes the current plan to get a more modern and complete bundle format. (for old content of this page check BundleFormatHG19)
Contents
(current content is copy pasted from 2.9 sprint note)
New bundle format
* lightweight * new manifest * general delta * bookmarks * phase boundaries * obsolete markers * >sha1 support * pushkey * extensible for new features (required and optional) * progress information * resumable? * transaction commit markers?
It's possible to envision a format that sends a change, its manifest, and filenodes in each chunk rather than sending all changesets, then all manifests, etc. capabilities
New header
type Header struct {
length uint32
lNode byte
node [lNode]byte
// if empty (lP1 ==0) then default to previous node in the stream
lP1 byte
p1 [lP1]byte
// if empty, nullrev
lP2 byte
p2 [lP2]byte
// if empty, self (for changelogs)
lLinknode byte
linknode [lLinknode]byte
// if empty, p1
lDeltaParent byte
deltaParent [lDeltaParent]byte
}We'll modify the existing changegroup type so it can pretend to be a new changegroup that just has a variety of empty fields. Progress information fields might be optional.