hgbook
view en/ch03-concepts.xml @ 608:c17f8bffc9e5
Account for new Django admin model.
| author | Bryan O'Sullivan <bos@serpentine.com> |
|---|---|
| date | Tue Mar 31 09:04:23 2009 -0700 (2009-03-31) |
| parents | 4ce9d0754af3 |
| children | 2ff0a43f1152 1c13ed2130a7 |
line source
1 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
3 <chapter id="chap:concepts">
4 <?dbhtml filename="behind-the-scenes.html"?>
5 <title>Behind the scenes</title>
7 <para id="x_2e8">Unlike many revision control systems, the concepts upon which
8 Mercurial is built are simple enough that it's easy to understand
9 how the software really works. Knowing this certainly isn't
10 necessary, but I find it useful to have a <quote>mental
11 model</quote> of what's going on.</para>
13 <para id="x_2e9">This understanding gives me confidence that Mercurial has been
14 carefully designed to be both <emphasis>safe</emphasis> and
15 <emphasis>efficient</emphasis>. And just as importantly, if it's
16 easy for me to retain a good idea of what the software is doing
17 when I perform a revision control task, I'm less likely to be
18 surprised by its behaviour.</para>
20 <para id="x_2ea">In this chapter, we'll initially cover the core concepts
21 behind Mercurial's design, then continue to discuss some of the
22 interesting details of its implementation.</para>
24 <sect1>
25 <title>Mercurial's historical record</title>
27 <sect2>
28 <title>Tracking the history of a single file</title>
30 <para id="x_2eb">When Mercurial tracks modifications to a file, it stores
31 the history of that file in a metadata object called a
32 <emphasis>filelog</emphasis>. Each entry in the filelog
33 contains enough information to reconstruct one revision of the
34 file that is being tracked. Filelogs are stored as files in
35 the <filename role="special"
36 class="directory">.hg/store/data</filename> directory. A
37 filelog contains two kinds of information: revision data, and
38 an index to help Mercurial to find a revision
39 efficiently.</para>
41 <para id="x_2ec">A file that is large, or has a lot of history, has its
42 filelog stored in separate data
43 (<quote><literal>.d</literal></quote> suffix) and index
44 (<quote><literal>.i</literal></quote> suffix) files. For
45 small files without much history, the revision data and index
46 are combined in a single <quote><literal>.i</literal></quote>
47 file. The correspondence between a file in the working
48 directory and the filelog that tracks its history in the
49 repository is illustrated in <xref
50 linkend="fig:concepts:filelog"/>.</para>
52 <figure id="fig:concepts:filelog">
53 <title>Relationships between files in working directory and
54 filelogs in repository</title>
55 <mediaobject>
56 <imageobject><imagedata fileref="figs/filelog.png"/></imageobject>
57 <textobject><phrase>XXX add text</phrase></textobject>
58 </mediaobject>
59 </figure>
61 </sect2>
62 <sect2>
63 <title>Managing tracked files</title>
65 <para id="x_2ee">Mercurial uses a structure called a
66 <emphasis>manifest</emphasis> to collect together information
67 about the files that it tracks. Each entry in the manifest
68 contains information about the files present in a single
69 changeset. An entry records which files are present in the
70 changeset, the revision of each file, and a few other pieces
71 of file metadata.</para>
73 </sect2>
74 <sect2>
75 <title>Recording changeset information</title>
77 <para id="x_2ef">The <emphasis>changelog</emphasis> contains information
78 about each changeset. Each revision records who committed a
79 change, the changeset comment, other pieces of
80 changeset-related information, and the revision of the
81 manifest to use.</para>
83 </sect2>
84 <sect2>
85 <title>Relationships between revisions</title>
87 <para id="x_2f0">Within a changelog, a manifest, or a filelog, each
88 revision stores a pointer to its immediate parent (or to its
89 two parents, if it's a merge revision). As I mentioned above,
90 there are also relationships between revisions
91 <emphasis>across</emphasis> these structures, and they are
92 hierarchical in nature.</para>
94 <para id="x_2f1">For every changeset in a repository, there is exactly one
95 revision stored in the changelog. Each revision of the
96 changelog contains a pointer to a single revision of the
97 manifest. A revision of the manifest stores a pointer to a
98 single revision of each filelog tracked when that changeset
99 was created. These relationships are illustrated in
100 <xref linkend="fig:concepts:metadata"/>.</para>
102 <figure id="fig:concepts:metadata">
103 <title>Metadata relationships</title>
104 <mediaobject>
105 <imageobject><imagedata fileref="figs/metadata.png"/></imageobject>
106 <textobject><phrase>XXX add text</phrase></textobject>
107 </mediaobject>
108 </figure>
110 <para id="x_2f3">As the illustration shows, there is
111 <emphasis>not</emphasis> a <quote>one to one</quote>
112 relationship between revisions in the changelog, manifest, or
113 filelog. If the manifest hasn't changed between two
114 changesets, the changelog entries for those changesets will
115 point to the same revision of the manifest. If a file that
116 Mercurial tracks hasn't changed between two changesets, the
117 entry for that file in the two revisions of the manifest will
118 point to the same revision of its filelog.</para>
120 </sect2>
121 </sect1>
122 <sect1>
123 <title>Safe, efficient storage</title>
125 <para id="x_2f4">The underpinnings of changelogs, manifests, and filelogs are
126 provided by a single structure called the
127 <emphasis>revlog</emphasis>.</para>
129 <sect2>
130 <title>Efficient storage</title>
132 <para id="x_2f5">The revlog provides efficient storage of revisions using a
133 <emphasis>delta</emphasis> mechanism. Instead of storing a
134 complete copy of a file for each revision, it stores the
135 changes needed to transform an older revision into the new
136 revision. For many kinds of file data, these deltas are
137 typically a fraction of a percent of the size of a full copy
138 of a file.</para>
140 <para id="x_2f6">Some obsolete revision control systems can only work with
141 deltas of text files. They must either store binary files as
142 complete snapshots or encoded into a text representation, both
143 of which are wasteful approaches. Mercurial can efficiently
144 handle deltas of files with arbitrary binary contents; it
145 doesn't need to treat text as special.</para>
147 </sect2>
148 <sect2 id="sec:concepts:txn">
149 <title>Safe operation</title>
151 <para id="x_2f7">Mercurial only ever <emphasis>appends</emphasis> data to
152 the end of a revlog file. It never modifies a section of a
153 file after it has written it. This is both more robust and
154 efficient than schemes that need to modify or rewrite
155 data.</para>
157 <para id="x_2f8">In addition, Mercurial treats every write as part of a
158 <emphasis>transaction</emphasis> that can span a number of
159 files. A transaction is <emphasis>atomic</emphasis>: either
160 the entire transaction succeeds and its effects are all
161 visible to readers in one go, or the whole thing is undone.
162 This guarantee of atomicity means that if you're running two
163 copies of Mercurial, where one is reading data and one is
164 writing it, the reader will never see a partially written
165 result that might confuse it.</para>
167 <para id="x_2f9">The fact that Mercurial only appends to files makes it
168 easier to provide this transactional guarantee. The easier it
169 is to do stuff like this, the more confident you should be
170 that it's done correctly.</para>
172 </sect2>
173 <sect2>
174 <title>Fast retrieval</title>
176 <para id="x_2fa">Mercurial cleverly avoids a pitfall common to all earlier
177 revision control systems: the problem of <emphasis>inefficient
178 retrieval</emphasis>. Most revision control systems store
179 the contents of a revision as an incremental series of
180 modifications against a <quote>snapshot</quote>. To
181 reconstruct a specific revision, you must first read the
182 snapshot, and then every one of the revisions between the
183 snapshot and your target revision. The more history that a
184 file accumulates, the more revisions you must read, hence the
185 longer it takes to reconstruct a particular revision.</para>
187 <figure id="fig:concepts:snapshot">
188 <title>Snapshot of a revlog, with incremental deltas</title>
189 <mediaobject>
190 <imageobject><imagedata fileref="figs/snapshot.png"/></imageobject>
191 <textobject><phrase>XXX add text</phrase></textobject>
192 </mediaobject>
193 </figure>
195 <para id="x_2fc">The innovation that Mercurial applies to this problem is
196 simple but effective. Once the cumulative amount of delta
197 information stored since the last snapshot exceeds a fixed
198 threshold, it stores a new snapshot (compressed, of course),
199 instead of another delta. This makes it possible to
200 reconstruct <emphasis>any</emphasis> revision of a file
201 quickly. This approach works so well that it has since been
202 copied by several other revision control systems.</para>
204 <para id="x_2fd"><xref linkend="fig:concepts:snapshot"/> illustrates
205 the idea. In an entry in a revlog's index file, Mercurial
206 stores the range of entries from the data file that it must
207 read to reconstruct a particular revision.</para>
209 <sect3>
210 <title>Aside: the influence of video compression</title>
212 <para id="x_2fe">If you're familiar with video compression or have ever
213 watched a TV feed through a digital cable or satellite
214 service, you may know that most video compression schemes
215 store each frame of video as a delta against its predecessor
216 frame. In addition, these schemes use <quote>lossy</quote>
217 compression techniques to increase the compression ratio, so
218 visual errors accumulate over the course of a number of
219 inter-frame deltas.</para>
221 <para id="x_2ff">Because it's possible for a video stream to <quote>drop
222 out</quote> occasionally due to signal glitches, and to
223 limit the accumulation of artefacts introduced by the lossy
224 compression process, video encoders periodically insert a
225 complete frame (called a <quote>key frame</quote>) into the
226 video stream; the next delta is generated against that
227 frame. This means that if the video signal gets
228 interrupted, it will resume once the next key frame is
229 received. Also, the accumulation of encoding errors
230 restarts anew with each key frame.</para>
232 </sect3>
233 </sect2>
234 <sect2>
235 <title>Identification and strong integrity</title>
237 <para id="x_300">Along with delta or snapshot information, a revlog entry
238 contains a cryptographic hash of the data that it represents.
239 This makes it difficult to forge the contents of a revision,
240 and easy to detect accidental corruption.</para>
242 <para id="x_301">Hashes provide more than a mere check against corruption;
243 they are used as the identifiers for revisions. The changeset
244 identification hashes that you see as an end user are from
245 revisions of the changelog. Although filelogs and the
246 manifest also use hashes, Mercurial only uses these behind the
247 scenes.</para>
249 <para id="x_302">Mercurial verifies that hashes are correct when it
250 retrieves file revisions and when it pulls changes from
251 another repository. If it encounters an integrity problem, it
252 will complain and stop whatever it's doing.</para>
254 <para id="x_303">In addition to the effect it has on retrieval efficiency,
255 Mercurial's use of periodic snapshots makes it more robust
256 against partial data corruption. If a revlog becomes partly
257 corrupted due to a hardware error or system bug, it's often
258 possible to reconstruct some or most revisions from the
259 uncorrupted sections of the revlog, both before and after the
260 corrupted section. This would not be possible with a
261 delta-only storage model.</para>
263 </sect2>
264 </sect1>
265 <sect1>
266 <title>Revision history, branching, and merging</title>
268 <para id="x_304">Every entry in a Mercurial revlog knows the identity of its
269 immediate ancestor revision, usually referred to as its
270 <emphasis>parent</emphasis>. In fact, a revision contains room
271 for not one parent, but two. Mercurial uses a special hash,
272 called the <quote>null ID</quote>, to represent the idea
273 <quote>there is no parent here</quote>. This hash is simply a
274 string of zeroes.</para>
276 <para id="x_305">In <xref linkend="fig:concepts:revlog"/>, you can see
277 an example of the conceptual structure of a revlog. Filelogs,
278 manifests, and changelogs all have this same structure; they
279 differ only in the kind of data stored in each delta or
280 snapshot.</para>
282 <para id="x_306">The first revision in a revlog (at the bottom of the image)
283 has the null ID in both of its parent slots. For a
284 <quote>normal</quote> revision, its first parent slot contains
285 the ID of its parent revision, and its second contains the null
286 ID, indicating that the revision has only one real parent. Any
287 two revisions that have the same parent ID are branches. A
288 revision that represents a merge between branches has two normal
289 revision IDs in its parent slots.</para>
291 <figure id="fig:concepts:revlog">
292 <title>The conceptual structure of a revlog</title>
293 <mediaobject>
294 <imageobject><imagedata fileref="figs/revlog.png"/></imageobject>
295 <textobject><phrase>XXX add text</phrase></textobject>
296 </mediaobject>
297 </figure>
299 </sect1>
300 <sect1>
301 <title>The working directory</title>
303 <para id="x_307">In the working directory, Mercurial stores a snapshot of the
304 files from the repository as of a particular changeset.</para>
306 <para id="x_308">The working directory <quote>knows</quote> which changeset
307 it contains. When you update the working directory to contain a
308 particular changeset, Mercurial looks up the appropriate
309 revision of the manifest to find out which files it was tracking
310 at the time that changeset was committed, and which revision of
311 each file was then current. It then recreates a copy of each of
312 those files, with the same contents it had when the changeset
313 was committed.</para>
315 <para id="x_309">The <emphasis>dirstate</emphasis> contains Mercurial's
316 knowledge of the working directory. This details which
317 changeset the working directory is updated to, and all of the
318 files that Mercurial is tracking in the working
319 directory.</para>
321 <para id="x_30a">Just as a revision of a revlog has room for two parents, so
322 that it can represent either a normal revision (with one parent)
323 or a merge of two earlier revisions, the dirstate has slots for
324 two parents. When you use the <command role="hg-cmd">hg
325 update</command> command, the changeset that you update to is
326 stored in the <quote>first parent</quote> slot, and the null ID
327 in the second. When you <command role="hg-cmd">hg
328 merge</command> with another changeset, the first parent
329 remains unchanged, and the second parent is filled in with the
330 changeset you're merging with. The <command role="hg-cmd">hg
331 parents</command> command tells you what the parents of the
332 dirstate are.</para>
334 <sect2>
335 <title>What happens when you commit</title>
337 <para id="x_30b">The dirstate stores parent information for more than just
338 book-keeping purposes. Mercurial uses the parents of the
339 dirstate as <emphasis>the parents of a new
340 changeset</emphasis> when you perform a commit.</para>
342 <figure id="fig:concepts:wdir">
343 <title>The working directory can have two parents</title>
344 <mediaobject>
345 <imageobject><imagedata fileref="figs/wdir.png"/></imageobject>
346 <textobject><phrase>XXX add text</phrase></textobject>
347 </mediaobject>
348 </figure>
350 <para id="x_30d"><xref linkend="fig:concepts:wdir"/> shows the
351 normal state of the working directory, where it has a single
352 changeset as parent. That changeset is the
353 <emphasis>tip</emphasis>, the newest changeset in the
354 repository that has no children.</para>
356 <figure id="fig:concepts:wdir-after-commit">
357 <title>The working directory gains new parents after a
358 commit</title>
359 <mediaobject>
360 <imageobject><imagedata fileref="figs/wdir-after-commit.png"/></imageobject>
361 <textobject><phrase>XXX add text</phrase></textobject>
362 </mediaobject>
363 </figure>
365 <para id="x_30f">It's useful to think of the working directory as
366 <quote>the changeset I'm about to commit</quote>. Any files
367 that you tell Mercurial that you've added, removed, renamed,
368 or copied will be reflected in that changeset, as will
369 modifications to any files that Mercurial is already tracking;
370 the new changeset will have the parents of the working
371 directory as its parents.</para>
373 <para id="x_310">After a commit, Mercurial will update the
374 parents of the working directory, so that the first parent is
375 the ID of the new changeset, and the second is the null ID.
376 This is shown in <xref
377 linkend="fig:concepts:wdir-after-commit"/>. Mercurial
378 doesn't touch any of the files in the working directory when
379 you commit; it just modifies the dirstate to note its new
380 parents.</para>
382 </sect2>
383 <sect2>
384 <title>Creating a new head</title>
386 <para id="x_311">It's perfectly normal to update the working directory to a
387 changeset other than the current tip. For example, you might
388 want to know what your project looked like last Tuesday, or
389 you could be looking through changesets to see which one
390 introduced a bug. In cases like this, the natural thing to do
391 is update the working directory to the changeset you're
392 interested in, and then examine the files in the working
393 directory directly to see their contents as they were when you
394 committed that changeset. The effect of this is shown in
395 <xref linkend="fig:concepts:wdir-pre-branch"/>.</para>
397 <figure id="fig:concepts:wdir-pre-branch">
398 <title>The working directory, updated to an older
399 changeset</title>
400 <mediaobject>
401 <imageobject><imagedata fileref="figs/wdir-pre-branch.png"/></imageobject>
402 <textobject><phrase>XXX add text</phrase></textobject>
403 </mediaobject>
404 </figure>
406 <para id="x_313">Having updated the working directory to an
407 older changeset, what happens if you make some changes, and
408 then commit? Mercurial behaves in the same way as I outlined
409 above. The parents of the working directory become the
410 parents of the new changeset. This new changeset has no
411 children, so it becomes the new tip. And the repository now
412 contains two changesets that have no children; we call these
413 <emphasis>heads</emphasis>. You can see the structure that
414 this creates in <xref
415 linkend="fig:concepts:wdir-branch"/>.</para>
417 <figure id="fig:concepts:wdir-branch">
418 <title>After a commit made while synced to an older
419 changeset</title>
420 <mediaobject>
421 <imageobject><imagedata fileref="figs/wdir-branch.png"/></imageobject>
422 <textobject><phrase>XXX add text</phrase></textobject>
423 </mediaobject>
424 </figure>
426 <note>
427 <para id="x_315"> If you're new to Mercurial, you should keep in mind a
428 common <quote>error</quote>, which is to use the <command
429 role="hg-cmd">hg pull</command> command without any
430 options. By default, the <command role="hg-cmd">hg
431 pull</command> command <emphasis>does not</emphasis>
432 update the working directory, so you'll bring new changesets
433 into your repository, but the working directory will stay
434 synced at the same changeset as before the pull. If you
435 make some changes and commit afterwards, you'll thus create
436 a new head, because your working directory isn't synced to
437 whatever the current tip is.</para>
439 <para id="x_316"> I put the word <quote>error</quote> in quotes because
440 all that you need to do to rectify this situation is
441 <command role="hg-cmd">hg merge</command>, then <command
442 role="hg-cmd">hg commit</command>. In other words, this
443 almost never has negative consequences; it just surprises
444 people. I'll discuss other ways to avoid this behaviour,
445 and why Mercurial behaves in this initially surprising way,
446 later on.</para>
447 </note>
449 </sect2>
450 <sect2>
451 <title>Merging heads</title>
453 <para id="x_317">When you run the <command role="hg-cmd">hg
454 merge</command> command, Mercurial leaves the first parent
455 of the working directory unchanged, and sets the second parent
456 to the changeset you're merging with, as shown in <xref
457 linkend="fig:concepts:wdir-merge"/>.</para>
459 <figure id="fig:concepts:wdir-merge">
460 <title>Merging two heads</title>
461 <mediaobject>
462 <imageobject>
463 <imagedata fileref="figs/wdir-merge.png"/>
464 </imageobject>
465 <textobject><phrase>XXX add text</phrase></textobject>
466 </mediaobject>
467 </figure>
469 <para id="x_319">Mercurial also has to modify the working directory, to
470 merge the files managed in the two changesets. Simplified a
471 little, the merging process goes like this, for every file in
472 the manifests of both changesets.</para>
473 <itemizedlist>
474 <listitem><para id="x_31a">If neither changeset has modified a file, do
475 nothing with that file.</para>
476 </listitem>
477 <listitem><para id="x_31b">If one changeset has modified a file, and the
478 other hasn't, create the modified copy of the file in the
479 working directory.</para>
480 </listitem>
481 <listitem><para id="x_31c">If one changeset has removed a file, and the
482 other hasn't (or has also deleted it), delete the file
483 from the working directory.</para>
484 </listitem>
485 <listitem><para id="x_31d">If one changeset has removed a file, but the
486 other has modified the file, ask the user what to do: keep
487 the modified file, or remove it?</para>
488 </listitem>
489 <listitem><para id="x_31e">If both changesets have modified a file,
490 invoke an external merge program to choose the new
491 contents for the merged file. This may require input from
492 the user.</para>
493 </listitem>
494 <listitem><para id="x_31f">If one changeset has modified a file, and the
495 other has renamed or copied the file, make sure that the
496 changes follow the new name of the file.</para>
497 </listitem></itemizedlist>
498 <para id="x_320">There are more details&emdash;merging has plenty of corner
499 cases&emdash;but these are the most common choices that are
500 involved in a merge. As you can see, most cases are
501 completely automatic, and indeed most merges finish
502 automatically, without requiring your input to resolve any
503 conflicts.</para>
505 <para id="x_321">When you're thinking about what happens when you commit
506 after a merge, once again the working directory is <quote>the
507 changeset I'm about to commit</quote>. After the <command
508 role="hg-cmd">hg merge</command> command completes, the
509 working directory has two parents; these will become the
510 parents of the new changeset.</para>
512 <para id="x_322">Mercurial lets you perform multiple merges, but you must
513 commit the results of each individual merge as you go. This
514 is necessary because Mercurial only tracks two parents for
515 both revisions and the working directory. While it would be
516 technically possible to merge multiple changesets at once, the
517 prospect of user confusion and making a terrible mess of a
518 merge immediately becomes overwhelming.</para>
520 </sect2>
521 </sect1>
522 <sect1>
523 <title>Other interesting design features</title>
525 <para id="x_323">In the sections above, I've tried to highlight some of the
526 most important aspects of Mercurial's design, to illustrate that
527 it pays careful attention to reliability and performance.
528 However, the attention to detail doesn't stop there. There are
529 a number of other aspects of Mercurial's construction that I
530 personally find interesting. I'll detail a few of them here,
531 separate from the <quote>big ticket</quote> items above, so that
532 if you're interested, you can gain a better idea of the amount
533 of thinking that goes into a well-designed system.</para>
535 <sect2>
536 <title>Clever compression</title>
538 <para id="x_324">When appropriate, Mercurial will store both snapshots and
539 deltas in compressed form. It does this by always
540 <emphasis>trying to</emphasis> compress a snapshot or delta,
541 but only storing the compressed version if it's smaller than
542 the uncompressed version.</para>
544 <para id="x_325">This means that Mercurial does <quote>the right
545 thing</quote> when storing a file whose native form is
546 compressed, such as a <literal>zip</literal> archive or a JPEG
547 image. When these types of files are compressed a second
548 time, the resulting file is usually bigger than the
549 once-compressed form, and so Mercurial will store the plain
550 <literal>zip</literal> or JPEG.</para>
552 <para id="x_326">Deltas between revisions of a compressed file are usually
553 larger than snapshots of the file, and Mercurial again does
554 <quote>the right thing</quote> in these cases. It finds that
555 such a delta exceeds the threshold at which it should store a
556 complete snapshot of the file, so it stores the snapshot,
557 again saving space compared to a naive delta-only
558 approach.</para>
560 <sect3>
561 <title>Network recompression</title>
563 <para id="x_327">When storing revisions on disk, Mercurial uses the
564 <quote>deflate</quote> compression algorithm (the same one
565 used by the popular <literal>zip</literal> archive format),
566 which balances good speed with a respectable compression
567 ratio. However, when transmitting revision data over a
568 network connection, Mercurial uncompresses the compressed
569 revision data.</para>
571 <para id="x_328">If the connection is over HTTP, Mercurial recompresses
572 the entire stream of data using a compression algorithm that
573 gives a better compression ratio (the Burrows-Wheeler
574 algorithm from the widely used <literal>bzip2</literal>
575 compression package). This combination of algorithm and
576 compression of the entire stream (instead of a revision at a
577 time) substantially reduces the number of bytes to be
578 transferred, yielding better network performance over almost
579 all kinds of network.</para>
581 <para id="x_329">(If the connection is over <command>ssh</command>,
582 Mercurial <emphasis>doesn't</emphasis> recompress the
583 stream, because <command>ssh</command> can already do this
584 itself.)</para>
586 </sect3>
587 </sect2>
588 <sect2>
589 <title>Read/write ordering and atomicity</title>
591 <para id="x_32a">Appending to files isn't the whole story when
592 it comes to guaranteeing that a reader won't see a partial
593 write. If you recall <xref linkend="fig:concepts:metadata"/>,
594 revisions in
595 the changelog point to revisions in the manifest, and
596 revisions in the manifest point to revisions in filelogs.
597 This hierarchy is deliberate.</para>
599 <para id="x_32b">A writer starts a transaction by writing filelog and
600 manifest data, and doesn't write any changelog data until
601 those are finished. A reader starts by reading changelog
602 data, then manifest data, followed by filelog data.</para>
604 <para id="x_32c">Since the writer has always finished writing filelog and
605 manifest data before it writes to the changelog, a reader will
606 never read a pointer to a partially written manifest revision
607 from the changelog, and it will never read a pointer to a
608 partially written filelog revision from the manifest.</para>
610 </sect2>
611 <sect2>
612 <title>Concurrent access</title>
614 <para id="x_32d">The read/write ordering and atomicity guarantees mean that
615 Mercurial never needs to <emphasis>lock</emphasis> a
616 repository when it's reading data, even if the repository is
617 being written to while the read is occurring. This has a big
618 effect on scalability; you can have an arbitrary number of
619 Mercurial processes safely reading data from a repository
620 safely all at once, no matter whether it's being written to or
621 not.</para>
623 <para id="x_32e">The lockless nature of reading means that if you're
624 sharing a repository on a multi-user system, you don't need to
625 grant other local users permission to
626 <emphasis>write</emphasis> to your repository in order for
627 them to be able to clone it or pull changes from it; they only
628 need <emphasis>read</emphasis> permission. (This is
629 <emphasis>not</emphasis> a common feature among revision
630 control systems, so don't take it for granted! Most require
631 readers to be able to lock a repository to access it safely,
632 and this requires write permission on at least one directory,
633 which of course makes for all kinds of nasty and annoying
634 security and administrative problems.)</para>
636 <para id="x_32f">Mercurial uses locks to ensure that only one process can
637 write to a repository at a time (the locking mechanism is safe
638 even over filesystems that are notoriously hostile to locking,
639 such as NFS). If a repository is locked, a writer will wait
640 for a while to retry if the repository becomes unlocked, but
641 if the repository remains locked for too long, the process
642 attempting to write will time out after a while. This means
643 that your daily automated scripts won't get stuck forever and
644 pile up if a system crashes unnoticed, for example. (Yes, the
645 timeout is configurable, from zero to infinity.)</para>
647 <sect3>
648 <title>Safe dirstate access</title>
650 <para id="x_330">As with revision data, Mercurial doesn't take a lock to
651 read the dirstate file; it does acquire a lock to write it.
652 To avoid the possibility of reading a partially written copy
653 of the dirstate file, Mercurial writes to a file with a
654 unique name in the same directory as the dirstate file, then
655 renames the temporary file atomically to
656 <filename>dirstate</filename>. The file named
657 <filename>dirstate</filename> is thus guaranteed to be
658 complete, not partially written.</para>
660 </sect3>
661 </sect2>
662 <sect2>
663 <title>Avoiding seeks</title>
665 <para id="x_331">Critical to Mercurial's performance is the avoidance of
666 seeks of the disk head, since any seek is far more expensive
667 than even a comparatively large read operation.</para>
669 <para id="x_332">This is why, for example, the dirstate is stored in a
670 single file. If there were a dirstate file per directory that
671 Mercurial tracked, the disk would seek once per directory.
672 Instead, Mercurial reads the entire single dirstate file in
673 one step.</para>
675 <para id="x_333">Mercurial also uses a <quote>copy on write</quote> scheme
676 when cloning a repository on local storage. Instead of
677 copying every revlog file from the old repository into the new
678 repository, it makes a <quote>hard link</quote>, which is a
679 shorthand way to say <quote>these two names point to the same
680 file</quote>. When Mercurial is about to write to one of a
681 revlog's files, it checks to see if the number of names
682 pointing at the file is greater than one. If it is, more than
683 one repository is using the file, so Mercurial makes a new
684 copy of the file that is private to this repository.</para>
686 <para id="x_334">A few revision control developers have pointed out that
687 this idea of making a complete private copy of a file is not
688 very efficient in its use of storage. While this is true,
689 storage is cheap, and this method gives the highest
690 performance while deferring most book-keeping to the operating
691 system. An alternative scheme would most likely reduce
692 performance and increase the complexity of the software, each
693 of which is much more important to the <quote>feel</quote> of
694 day-to-day use.</para>
696 </sect2>
697 <sect2>
698 <title>Other contents of the dirstate</title>
700 <para id="x_335">Because Mercurial doesn't force you to tell it when you're
701 modifying a file, it uses the dirstate to store some extra
702 information so it can determine efficiently whether you have
703 modified a file. For each file in the working directory, it
704 stores the time that it last modified the file itself, and the
705 size of the file at that time.</para>
707 <para id="x_336">When you explicitly <command role="hg-cmd">hg
708 add</command>, <command role="hg-cmd">hg remove</command>,
709 <command role="hg-cmd">hg rename</command> or <command
710 role="hg-cmd">hg copy</command> files, Mercurial updates the
711 dirstate so that it knows what to do with those files when you
712 commit.</para>
714 <para id="x_337">When Mercurial is checking the states of files in the
715 working directory, it first checks a file's modification time.
716 If that has not changed, the file must not have been modified.
717 If the file's size has changed, the file must have been
718 modified. If the modification time has changed, but the size
719 has not, only then does Mercurial need to read the actual
720 contents of the file to see if they've changed. Storing these
721 few extra pieces of information dramatically reduces the
722 amount of data that Mercurial needs to read, which yields
723 large performance improvements compared to other revision
724 control systems.</para>
726 </sect2>
727 </sect1>
728 </chapter>
730 <!--
731 local variables:
732 sgml-parent-document: ("00book.xml" "book" "chapter")
733 end:
734 -->