Mercurial > hg
comparison mercurial/help/internals/revlogs.txt @ 29747:aba2bb2a6d0f
help: don't try to render a section on sub-topics
This patch subtly changes the behavior of the parsing of "X.Y" values
to not set the "section" variable when rendering a known sub-topic.
Previously, "section" would be the same as the sub-topic name. This
required the sub-topic RST to have a section named the same as the
sub-topic name.
When I made this change, the descriptions from help.internalstable
started being rendered in command line output. This didn't look correct
to me, as it didn't match the formatting of main help pages. I
corrected this by moving the top section to help.internalstable and
changing the section levels of all the "internals" topics.
The end result is that "internals" topics now match the rendering of
main topics on both the CLI and HTML. And, "internals" topics no longer
require a main section matching the name of the topic.
author | Gregory Szorc <gregory.szorc@gmail.com> |
---|---|
date | Sat, 06 Aug 2016 17:04:22 -0700 |
parents | 1111e84de635 |
children | 22d05b53b0e8 |
comparison
equal
deleted
inserted
replaced
29746:3dbc95f3eb31 | 29747:aba2bb2a6d0f |
---|---|
1 Revlogs | |
2 ======= | |
3 | |
4 Revision logs - or *revlogs* - are an append only data structure for | 1 Revision logs - or *revlogs* - are an append only data structure for |
5 storing discrete entries, or *revisions*. They are the primary storage | 2 storing discrete entries, or *revisions*. They are the primary storage |
6 mechanism of repository data. | 3 mechanism of repository data. |
7 | 4 |
8 Revlogs effectively model a directed acyclic graph (DAG). Each node | 5 Revlogs effectively model a directed acyclic graph (DAG). Each node |
26 Revlogs can be modeled as 0-indexed arrays. The first revision is | 23 Revlogs can be modeled as 0-indexed arrays. The first revision is |
27 revision #0 and the second is revision #1. The revision -1 is typically | 24 revision #0 and the second is revision #1. The revision -1 is typically |
28 used to mean *does not exist* or *not defined*. | 25 used to mean *does not exist* or *not defined*. |
29 | 26 |
30 File Format | 27 File Format |
31 ----------- | 28 =========== |
32 | 29 |
33 A revlog begins with a 32-bit big endian integer holding version info | 30 A revlog begins with a 32-bit big endian integer holding version info |
34 and feature flags. This integer is shared with the first revision | 31 and feature flags. This integer is shared with the first revision |
35 entry. | 32 entry. |
36 | 33 |
75 Following that are remaining *index* data. Inlined revision data is | 72 Following that are remaining *index* data. Inlined revision data is |
76 possibly located between index entries. More on this layout is described | 73 possibly located between index entries. More on this layout is described |
77 below. | 74 below. |
78 | 75 |
79 RevlogNG Format | 76 RevlogNG Format |
80 --------------- | 77 =============== |
81 | 78 |
82 RevlogNG (version 1) begins with an index describing the revisions in | 79 RevlogNG (version 1) begins with an index describing the revisions in |
83 the revlog. If the ``inline`` flag is set, revision data is stored inline, | 80 the revlog. If the ``inline`` flag is set, revision data is stored inline, |
84 or between index entries (as opposed to in a separate container). | 81 or between index entries (as opposed to in a separate container). |
85 | 82 |
127 | 124 |
128 The first 4 bytes of the revlog are shared between the revlog header | 125 The first 4 bytes of the revlog are shared between the revlog header |
129 and the 6 byte absolute offset field from the first revlog entry. | 126 and the 6 byte absolute offset field from the first revlog entry. |
130 | 127 |
131 Delta Chains | 128 Delta Chains |
132 ------------ | 129 ============ |
133 | 130 |
134 Revision data is encoded as a chain of *chunks*. Each chain begins with | 131 Revision data is encoded as a chain of *chunks*. Each chain begins with |
135 the compressed original full text for that revision. Each subsequent | 132 the compressed original full text for that revision. Each subsequent |
136 *chunk* is a *delta* against the previous revision. We therefore call | 133 *chunk* is a *delta* against the previous revision. We therefore call |
137 these chains of chunks/deltas *delta chains*. | 134 these chains of chunks/deltas *delta chains*. |
151 the previous revision. The *generaldelta* revlog feature flag (enabled | 148 the previous revision. The *generaldelta* revlog feature flag (enabled |
152 by default in Mercurial 3.7) activates the mode where deltas are | 149 by default in Mercurial 3.7) activates the mode where deltas are |
153 computed against an arbitrary revision (almost certainly a parent revision). | 150 computed against an arbitrary revision (almost certainly a parent revision). |
154 | 151 |
155 File Storage | 152 File Storage |
156 ------------ | 153 ============ |
157 | 154 |
158 Revlogs logically consist of an index (metadata of entries) and | 155 Revlogs logically consist of an index (metadata of entries) and |
159 revision data. This data may be stored together in a single file or in | 156 revision data. This data may be stored together in a single file or in |
160 separate files. The mechanism used is indicated by the ``inline`` feature | 157 separate files. The mechanism used is indicated by the ``inline`` feature |
161 flag on the revlog. | 158 flag on the revlog. |
170 The actual layout of revlog files on disk is governed by the repository's | 167 The actual layout of revlog files on disk is governed by the repository's |
171 *store format*. Typically, a ``.i`` file represents the index revlog | 168 *store format*. Typically, a ``.i`` file represents the index revlog |
172 (possibly containing inline data) and a ``.d`` file holds the revision data. | 169 (possibly containing inline data) and a ``.d`` file holds the revision data. |
173 | 170 |
174 Revision Entries | 171 Revision Entries |
175 ---------------- | 172 ================ |
176 | 173 |
177 Revision entries consist of an optional 1 byte header followed by an | 174 Revision entries consist of an optional 1 byte header followed by an |
178 encoding of the revision data. The headers are as follows: | 175 encoding of the revision data. The headers are as follows: |
179 | 176 |
180 \0 (0x00) | 177 \0 (0x00) |
185 zlib (RFC 1950) data. | 182 zlib (RFC 1950) data. |
186 | 183 |
187 The 0x78 value is actually the first byte of the zlib header (CMF byte). | 184 The 0x78 value is actually the first byte of the zlib header (CMF byte). |
188 | 185 |
189 Hash Computation | 186 Hash Computation |
190 ---------------- | 187 ================ |
191 | 188 |
192 The hash of the revision is stored in the index and is used both as a primary | 189 The hash of the revision is stored in the index and is used both as a primary |
193 key and for data integrity verification. | 190 key and for data integrity verification. |
194 | 191 |
195 Currently, SHA-1 is the only supported hashing algorithm. To obtain the SHA-1 | 192 Currently, SHA-1 is the only supported hashing algorithm. To obtain the SHA-1 |