hgbook
view en/concepts.tex @ 112:2fcead053b7a
More. Concept. Fun.
| author | Bryan O'Sullivan <bos@serpentine.com> |
|---|---|
| date | Mon Nov 13 13:21:29 2006 -0800 (2006-11-13) |
| parents | 34b8b7a15ea1 |
| children | a0f57b3e677e |
line source
1 \chapter{Behind the scenes}
2 \label{chap:concepts}
4 Unlike many revision control systems, the concepts upon which
5 Mercurial is built are simple enough that it's easy to understand how
6 the software really works. Knowing this certainly isn't necessary,
7 but I find it useful to have a ``mental model'' of what's going on.
9 This understanding gives me confidence that Mercurial has been
10 carefully designed to be both \emph{safe} and \emph{efficient}. And
11 just as importantly, if it's easy for me to retain a good idea of what
12 the software is doing when I perform a revision control task, I'm less
13 likely to be surprised by its behaviour.
15 In this chapter, we'll initially cover the core concepts behind
16 Mercurial's design, then continue to discuss some of the interesting
17 details of its implementation.
19 \section{Mercurial's historical record}
21 \subsection{Tracking the history of a single file}
23 When Mercurial tracks modifications to a file, it stores the history
24 of that file in a metadata object called a \emph{filelog}. Each entry
25 in the filelog contains enough information to reconstruct one revision
26 of the file that is being tracked. Filelogs are stored as files in
27 the \sdirname{.hg/data} directory. A filelog contains two kinds of
28 information: revision data, and an index to help Mercurial to find a
29 revision efficiently.
31 A file that is large, or has a lot of history, has its filelog stored
32 in separate data (``\texttt{.d}'' suffix) and index (``\texttt{.i}''
33 suffix) files. For small files without much history, the revision
34 data and index are combined in a single ``\texttt{.i}'' file. The
35 correspondence between a file in the working directory and the filelog
36 that tracks its history in the repository is illustrated in
37 figure~\ref{fig:concepts:filelog}.
39 \begin{figure}[ht]
40 \centering
41 \grafix{filelog}
42 \caption{Relationships between files in working directory and
43 filelogs in repository}
44 \label{fig:concepts:filelog}
45 \end{figure}
47 \subsection{Managing tracked files}
49 Mercurial uses a structure called a \emph{manifest} to collect
50 together information about the files that it tracks. Each entry in
51 the manifest contains information about the files present in a single
52 changeset. An entry records which files are present in the changeset,
53 the revision of each file, and a few other pieces of file metadata.
55 \subsection{Recording changeset information}
57 The \emph{changelog} contains information about each changeset. Each
58 revision records who committed a change, the changeset comment, other
59 pieces of changeset-related information, and the revision of the
60 manifest to use.
62 \subsection{Relationships between revisions}
64 Within a changelog, a manifest, or a filelog, each revision stores a
65 pointer to its immediate parent (or to its two parents, if it's a
66 merge revision). As I mentioned above, there are also relationships
67 between revisions \emph{across} these structures, and they are
68 hierarchical in nature.
70 For every changeset in a repository, there is exactly one revision
71 stored in the changelog. Each revision of the changelog contains a
72 pointer to a single revision of the manifest. A revision of the
73 manifest stores a pointer to a single revision of each filelog tracked
74 when that changeset was created. These relationships are illustrated
75 in figure~\ref{fig:concepts:metadata}.
77 \begin{figure}[ht]
78 \centering
79 \grafix{metadata}
80 \caption{Metadata relationships}
81 \label{fig:concepts:metadata}
82 \end{figure}
84 As the illustration shows, there is \emph{not} a ``one to one''
85 relationship between revisions in the changelog, manifest, or filelog.
86 If the manifest hasn't changed between two changesets, the changelog
87 entries for those changesets will point to the same revision of the
88 manifest. If a file that Mercurial tracks hasn't changed between two
89 changesets, the entry for that file in the two revisions of the
90 manifest will point to the same revision of its filelog.
92 \section{Safe, efficient storage}
94 The underpinnings of changelogs, manifests, and filelogs are provided
95 by a single structure called the \emph{revlog}.
97 \subsection{Efficient storage}
99 The revlog provides efficient storage of revisions using a
100 \emph{delta} mechanism. Instead of storing a complete copy of a file
101 for each revision, it stores the changes needed to transform an older
102 revision into the new revision. For many kinds of file data, these
103 deltas are typically a fraction of a percent of the size of a full
104 copy of a file.
106 Some obsolete revision control systems can only work with deltas of
107 text files. They must either store binary files as complete snapshots
108 or encoded into a text representation, both of which are wasteful
109 approaches. Mercurial can efficiently handle deltas of files with
110 arbitrary binary contents; it doesn't need to treat text as special.
112 \subsection{Safe operation}
114 Mercurial only ever \emph{appends} data to the end of a revlog file.
115 It never modifies a section of a file after it has written it. This
116 is both more robust and efficient than schemes that need to modify or
117 rewrite data.
119 In addition, Mercurial treats every write as part of a
120 \emph{transaction} that can span a number of files. A transaction is
121 \emph{atomic}: either the entire transaction succeeds and its effects
122 are all visible to readers in one go, or the whole thing is undone.
123 This guarantee of atomicity means that if you're running two copies of
124 Mercurial, where one is reading data and one is writing it, the reader
125 will never see a partially written result that might confuse it.
127 The fact that Mercurial only appends to files makes it easier to
128 provide this transactional guarantee. The easier it is to do stuff
129 like this, the more confident you should be that it's done correctly.
131 \subsection{Fast retrieval}
133 Mercurial cleverly avoids a pitfall common to all earlier
134 revision control systems: the problem of \emph{inefficient retrieval}.
135 Most revision control systems store the contents of a revision as an
136 incremental series of modifications against a ``snapshot''. To
137 reconstruct a specific revision, you must first read the snapshot, and
138 then every one of the revisions between the snapshot and your target
139 revision. The more history that a file accumulates, the more
140 revisions you must read, hence the longer it takes to reconstruct a
141 particular revision.
143 \begin{figure}[ht]
144 \centering
145 \grafix{snapshot}
146 \caption{Snapshot of a revlog, with incremental deltas}
147 \label{fig:concepts:snapshot}
148 \end{figure}
150 The innovation that Mercurial applies to this problem is simple but
151 effective. Once the cumulative amount of delta information stored
152 since the last snapshot exceeds a fixed threshold, it stores a new
153 snapshot (compressed, of course), instead of another delta. This
154 makes it possible to reconstruct \emph{any} revision of a file
155 quickly. This approach works so well that it has since been copied by
156 several other revision control systems.
158 Figure~\ref{fig:concepts:snapshot} illustrates the idea. In an entry
159 in a revlog's index file, Mercurial stores the range of entries from
160 the data file that it must read to reconstruct a particular revision.
162 \subsubsection{Aside: the influence of video compression}
164 If you're familiar with video compression or have ever watched a TV
165 feed through a digital cable or satellite service, you may know that
166 most video compression schemes store each frame of video as a delta
167 against its predecessor frame. In addition, these schemes use
168 ``lossy'' compression techniques to increase the compression ratio, so
169 visual errors accumulate over the course of a number of inter-frame
170 deltas.
172 Because it's possible for a video stream to ``drop out'' occasionally
173 due to signal glitches, and to limit the accumulation of artefacts
174 introduced by the lossy compression process, video encoders
175 periodically insert a complete frame (called a ``key frame'') into the
176 video stream; the next delta is generated against that frame. This
177 means that if the video signal gets interrupted, it will resume once
178 the next key frame is received. Also, the accumulation of encoding
179 errors restarts anew with each key frame.
181 \subsection{Identification and strong integrity}
183 Along with delta or snapshot information, a revlog entry contains a
184 cryptographic hash of the data that it represents. This makes it
185 difficult to forge the contents of a revision, and easy to detect
186 accidental corruption.
188 Hashes provide more than a mere check against corruption; they are
189 used as the identifiers for revisions. The changeset identification
190 hashes that you see as an end user are from revisions of the
191 changelog. Although filelogs and the manifest also use hashes,
192 Mercurial only uses these behind the scenes.
194 Mercurial verifies that hashes are correct when it retrieves file
195 revisions and when it pulls changes from another repository. If it
196 encounters an integrity problem, it will complain and stop whatever
197 it's doing.
199 In addition to the effect it has on retrieval efficiency, Mercurial's
200 use of periodic snapshots makes it more robust against partial data
201 corruption. If a revlog becomes partly corrupted due to a hardware
202 error or system bug, it's often possible to reconstruct some or most
203 revisions from the uncorrupted sections of the revlog, both before and
204 after the corrupted section. This would not be possible with a
205 delta-only storage model.
207 \section{The working directory}
209 Mercurial's good ideas are not confined to the repository; it also
210 needs to manage the working directory. The \emph{dirstate} contains
211 Mercurial's knowledge of the working directory. This details which
212 revision(s) the working directory is updated to, and all files that
213 Mercurial is tracking in the working directory.
215 Because Mercurial doesn't force you to tell it when you're modifying a
216 file, it uses the dirstate to store some extra information so it can
217 determine efficiently whether you have modified a file. For each file
218 in the working directory, it stores the time that it last modified the
219 file itself, and the size of the file at that time.
221 When Mercurial is checking the states of files in the working
222 directory, it first checks a file's modification time. If that has
223 not changed, the file must not have been modified. If the file's size
224 has changed, the file must have been modified. If the modification
225 time has changed, but the size has not, only then does Mercurial need
226 to read the actual contents of the file to see if they've changed.
227 Storing these few extra pieces of information dramatically reduces the
228 amount of data that Mercurial needs to read, which yields large
229 performance improvements compared to other revision control systems.
231 \section{Revision history, branching,
232 and merging}
234 Every entry in a Mercurial revlog knows the identity of its immediate
235 ancestor revision, usually referred to as its \emph{parent}. In fact,
236 a revision contains room for not one parent, but two. Mercurial uses
237 a special hash, called the ``null ID'', to represent the idea ``there
238 is no parent here''. This hash is simply a string of zeroes.
240 In figure~\ref{fig:concepts:revlog}, you can see an example of the
241 conceptual structure of a revlog. Filelogs, manifests, and changelogs
242 all have this same structure; they differ only in the kind of data
243 stored in each delta or snapshot.
245 The first revision in a revlog (at the bottom of the image) has the
246 null ID in both of its parent slots. For a ``normal'' revision, its
247 first parent slot contains the ID of its parent revision, and its
248 second contains the null ID, indicating that the revision has only one
249 real parent. Any two revisions that have the same parent ID are
250 branches. A revision that represents a merge between branches has two
251 normal revision IDs in its parent slots.
253 \begin{figure}[ht]
254 \centering
255 \grafix{revlog}
256 \caption{}
257 \label{fig:concepts:revlog}
258 \end{figure}
260 \section{Other interesting design features}
262 In the sections above, I've tried to highlight some of the most
263 important aspects of Mercurial's design, to illustrate that it pays
264 careful attention to reliability and performance. However, the
265 attention to detail doesn't stop there. There are a number of other
266 aspects of Mercurial's construction that I personally find
267 interesting. I'll detail a few of them here, separate from the ``big
268 ticket'' items above, so that if you're interested, you can gain a
269 better idea of the amount of thinking that goes into a well-designed
270 system.
272 \subsection{Clever compression}
274 When appropriate, Mercurial will store both snapshots and deltas in
275 compressed form. It does this by always \emph{trying to} compress a
276 snapshot or delta, but only storing the compressed version if it's
277 smaller than the uncompressed version.
279 This means that Mercurial does ``the right thing'' when storing a file
280 whose native form is compressed, such as a \texttt{zip} archive or a
281 JPEG image. When these types of files are compressed a second time,
282 the resulting file is usually bigger than the once-compressed form,
283 and so Mercurial will store the plain \texttt{zip} or JPEG.
285 Deltas between revisions of a compressed file are usually larger than
286 snapshots of the file, and Mercurial again does ``the right thing'' in
287 these cases. It finds that such a delta exceeds the threshold at
288 which it should store a complete snapshot of the file, so it stores
289 the snapshot, again saving space compared to a naive delta-only
290 approach.
292 \subsubsection{Network recompression}
294 When storing revisions on disk, Mercurial uses the ``deflate''
295 compression algorithm (the same one used by the popular \texttt{zip}
296 archive format), which balances good speed with a respectable
297 compression ratio. However, when transmitting revision data over a
298 network connection, Mercurial uncompresses the compressed revision
299 data.
301 If the connection is over HTTP, Mercurial recompresses the entire
302 stream of data using a compression algorithm that gives a etter
303 compression ratio (the Burrows-Wheeler algorithm from the widely used
304 \texttt{bzip2} compression package). This combination of algorithm
305 and compression of the entire stream (instead of a revision at a time)
306 substantially reduces the number of bytes to be transferred, yielding
307 better network performance over almost all kinds of network.
309 (If the connection is over \command{ssh}, Mercurial \emph{doesn't}
310 recompress the stream, because \command{ssh} can already do this
311 itself.)
313 \subsection{Read/write ordering and atomicity}
315 Appending to files isn't the whole story when it comes to guaranteeing
316 that a reader won't see a partial write. If you recall
317 figure~\ref{fig:concepts:metadata}, revisions in the changelog point to
318 revisions in the manifest, and revisions in the manifest point to
319 revisions in filelogs. This hierarchy is deliberate.
321 A writer starts a transaction by writing filelog and manifest data,
322 and doesn't write any changelog data until those are finished. A
323 reader starts by reading changelog data, then manifest data, followed
324 by filelog data.
326 Since the writer has always finished writing filelog and manifest data
327 before it writes to the changelog, a reader will never read a pointer
328 to a partially written manifest revision from the changelog, and it will
329 never read a pointer to a partially written filelog revision from the
330 manifest.
332 \subsection{Concurrent access}
334 The read/write ordering and atomicity guarantees mean that Mercurial
335 never needs to \emph{lock} a repository when it's reading data, even
336 if the repository is being written to while the read is occurring.
337 This has a big effect on scalability; you can have an arbitrary number
338 of Mercurial processes safely reading data from a repository safely
339 all at once, no matter whether it's being written to or not.
341 The lockless nature of reading means that if you're sharing a
342 repository on a multi-user system, you don't need to grant other local
343 users permission to \emph{write} to your repository in order for them
344 to be able to clone it or pull changes from it; they only need
345 \emph{read} permission. (This is \emph{not} a common feature among
346 revision control systems, so don't take it for granted! Most require
347 readers to be able to lock a repository to access it safely, and this
348 requires write permission on at least one directory, which of course
349 makes for all kinds of nasty and annoying security and administrative
350 problems.)
352 Mercurial uses locks to ensure that only one process can write to a
353 repository at a time (the locking mechanism is safe even over
354 filesystems that are notoriously hostile to locking, such as NFS). If
355 a repository is locked, a writer will wait for a while to retry if the
356 repository becomes unlocked, but if the repository remains locked for
357 too long, the process attempting to write will time out after a while.
358 This means that your daily automated scripts won't get stuck forever
359 and pile up if a system crashes unnoticed, for example. (Yes, the
360 timeout is configurable, from zero to infinity.)
362 \subsubsection{Safe dirstate access}
364 As with revision data, Mercurial doesn't take a lock to read the
365 dirstate file; it does acquire a lock to write it. To avoid the
366 possibility of reading a partially written copy of the dirstate file,
367 Mercurial writes to a file with a unique name in the same directory as
368 the dirstate file, then renames the temporary file atomically to
369 \filename{dirstate}. The file named \filename{dirstate} is thus
370 guaranteed to be complete, not partially written.
372 \subsection{Avoiding seeks}
374 Critical to Mercurial's performance is the avoidance of seeks of the
375 disk head, since any seek is far more expensive than even a
376 comparatively large read operation.
378 This is why, for example, the dirstate is stored in a single file. If
379 there were a dirstate file per directory that Mercurial tracked, the
380 disk would seek once per directory. Instead, Mercurial reads the
381 entire single dirstate file in one step.
383 Mercurial also uses a ``copy on write'' scheme when cloning a
384 repository on local storage. Instead of copying every revlog file
385 from the old repository into the new repository, it makes a ``hard
386 link'', which is a shorthand way to say ``these two names point to the
387 same file''. When Mercurial is about to write to one of a revlog's
388 files, it checks to see if the number of names pointing at the file is
389 greater than one. If it is, more than one repository is using the
390 file, so Mercurial makes a new copy of the file that is private to
391 this repository.
393 A few revision control developers have pointed out that this idea of
394 making a complete private copy of a file is not very efficient in its
395 use of storage. While this is true, storage is cheap, and this method
396 gives the highest performance while deferring most book-keeping to the
397 operating system. An alternative scheme would most likely reduce
398 performance and increase the complexity of the software, each of which
399 is much more important to the ``feel'' of day-to-day use.
401 %%% Local Variables:
402 %%% mode: latex
403 %%% TeX-master: "00book"
404 %%% End: