Mercurial > hg
changeset 28590:b0b9f6b0a777
help: document sharing of revlog header with revision 0
The previous docs were incorrect about there being a discrete header
on revlogs.
| author | Gregory Szorc <gregory.szorc@gmail.com> |
|---|---|
| date | Sat, 19 Mar 2016 15:17:33 -0700 |
| parents | c4c7be9f0554 |
| children | f29cab5c519c |
| files | mercurial/help/internals/revlogs.txt |
| diffstat | 1 files changed, 12 insertions(+), 4 deletions(-) [+] |
line wrap: on
line diff
--- a/mercurial/help/internals/revlogs.txt Sat Mar 19 16:45:52 2016 -0400 +++ b/mercurial/help/internals/revlogs.txt Sat Mar 19 15:17:33 2016 -0700 @@ -31,7 +31,8 @@ ----------- 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 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 @@ 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 @@ 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 @@ 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.