# HG changeset patch # User Gregory Szorc # Date 2016-03-19 22:17:33 # Node ID b0b9f6b0a7773e200f264664af61795ccfc1c3c5 # Parent c4c7be9f0554f0414bdfc475141e5a19b4137f76 help: document sharing of revlog header with revision 0 The previous docs were incorrect about there being a discrete header on revlogs. diff --git a/mercurial/help/internals/revlogs.txt b/mercurial/help/internals/revlogs.txt --- a/mercurial/help/internals/revlogs.txt +++ b/mercurial/help/internals/revlogs.txt @@ -31,7 +31,8 @@ File Format ----------- A revlog begins with a 32-bit big endian integer holding version info -and feature flags. +and feature flags. This integer is shared with the first revision +entry. This integer is logically divided into 2 16-bit shorts. The least significant half of the integer is the format/version short. The other @@ -70,8 +71,10 @@ 00 02 00 01 00 03 00 01 RevlogNG + inline + generaldelta -Following the 32-bit header is *index* data. Inlined revision data is possibly -located between index entries. More on this layout is described below. +Following the 32-bit header is the remainder of the first index entry. +Following that are remaining *index* data. Inlined revision data is +possibly located between index entries. More on this layout is described +below. RevlogNG Format --------------- @@ -83,6 +86,8 @@ or between index entries (as opposed to Each index entry is 64 bytes. The byte layout of each entry is as follows, with byte 0 being the first byte (all data stored as big endian): +0-3 (4 bytes) (rev 0 only) + Revlog header 0-5 (6 bytes) Absolute offset of revision data from beginning of revlog. 6-7 (2 bytes) @@ -120,6 +125,9 @@ If revision data is not inline, then raw separate byte container. The offsets from bytes 0-5 and the compressed length from bytes 8-11 define how to access this data. +The first 4 bytes of the revlog are shared between the revlog header +and the 6 byte absolute offset field from the first revlog entry. + Delta Chains ------------ @@ -190,4 +198,4 @@ hash of a revision: 1. Hash the parent nodes 2. Hash the fulltext of the revision -The 20 byte node ids of the parents are fed into the hasher in ascending order. \ No newline at end of file +The 20 byte node ids of the parents are fed into the hasher in ascending order.