Patchwork help: document sharing of revlog header with revision 0

login
register
mail settings
Submitter Gregory Szorc
Date March 19, 2016, 10:17 p.m.
Message ID <eab3e3960745c92f5d29.1458425870@gps-mbp.local>
Download mbox | patch
Permalink /patch/13967/
State Accepted
Headers show

Comments

Gregory Szorc - March 19, 2016, 10:17 p.m.
# HG changeset patch
# User Gregory Szorc <gregory.szorc@gmail.com>
# Date 1458425853 25200
#      Sat Mar 19 15:17:33 2016 -0700
# Node ID eab3e3960745c92f5d29c80ea1d456a28c440009
# Parent  1f3d9fe592151d4eab21282e87628ef655c67daf
help: document sharing of revlog header with revision 0

The previous docs were incorrect about there being a discrete header
on revlogs.
Danek Duvall - March 19, 2016, 10:42 p.m.
Gregory Szorc wrote:

> -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 remaining of the first index entry.

"remaining" -> "remainder"

Danek
Pierre-Yves David - March 19, 2016, 10:44 p.m.
On 03/19/2016 03:17 PM, Gregory Szorc wrote:
> # HG changeset patch
> # User Gregory Szorc <gregory.szorc@gmail.com>
> # Date 1458425853 25200
> #      Sat Mar 19 15:17:33 2016 -0700
> # Node ID eab3e3960745c92f5d29c80ea1d456a28c440009
> # Parent  1f3d9fe592151d4eab21282e87628ef655c67daf
> help: document sharing of revlog header with revision 0

pushed to the clowncopter, thanks.
Augie Fackler - March 19, 2016, 11:13 p.m.
On Sat, Mar 19, 2016 at 03:42:33PM -0700, Danek Duvall wrote:
> Gregory Szorc wrote:
>
> > -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 remaining of the first index entry.
>
> "remaining" -> "remainder"

Amended that in, thanks.

>
> Danek
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel@mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel

Patch

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
@@ -30,9 +30,10 @@  used to mean *does not exist* or *not de
 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
 short holds feature flags that dictate behavior of the revlog.
@@ -69,10 +70,12 @@  00 02 00 01
    RevlogNG + generaldelta
 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 remaining 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
 ---------------
 
@@ -82,8 +85,10 @@  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)
    Bit flags impacting revision behavior.
@@ -119,8 +124,11 @@  is no padding between it and the index e
 If revision data is not inline, then raw revision data is stored in a
 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
 ------------
 
 Revision data is encoded as a chain of *chunks*. Each chain begins with
@@ -189,5 +197,5 @@  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.