hgbook
view fr/ch04-concepts.xml @ 993:71dbda516572
French translation : merge with Jean Marie Clement's work on ch04-concepts
| author | Frédéric Bouquet <youshe.jaalon@gmail.com> |
|---|---|
| date | Fri Sep 11 14:35:36 2009 +0200 (2009-09-11) |
| parents | 8b0f1e2984d0 e6894aa7baf2 |
| children | 669ae1a09e46 |
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>Derrière le décor</title>
7 <para id="x_2e8">À la différence de beaucoup d'outils de gestion de versions,
8 les concepts sur lesquels se base Mercurial sont assez simples pour
9 qu'il soit facile de comprendre comment le logiciel fonctionne.
10 Bien que leur connaissance ne soit pas nécéssaire, je trouve utile
11 d'avoir un <quote>modèle mental</quote> de ce qui se passe.</para>
13 <para id="x_2e9">En effet, cette compréhension m'apporte la confiance que
14 Mercurial a été développé avec soin pour être à la fois
15 <emphasis>sûr</emphasis> et <emphasis>efficace</emphasis>. De surcroît,
16 si il m'est facile de garder en tête ce que le logiciel fait lorsque
17 j'accompli des tâches de révision, j'aurai moins de risques d'être
18 surpris par son comportement.</para>
20 <para id="x_2ea">Dans ce chapitre, nous décrirons tout d'abord les concepts
21 essentiels de l'architecture de Mercurial, pour ensuite discuter quelques
22 uns des détails intéressants de son implémentation.</para>
24 <sect1>
25 <title>Conservation de l'historique sous Mercurial</title>
26 <sect2>
27 <title>Suivi de l'historique pour un seul fichier</title>
29 <para id="x_2eb">Lorsque Mercurial effectue un suivi des modifications
30 faites à un fichier, il conserve l'historique pour ce fichier dans un
31 <emphasis>filelog</emphasis> sous forme de métadonnées. Chaque entrée
32 dans le filelog contient assez d'informations pour reconstituer une
33 révision du fichier correspondant. Les filelogs sont des fichiers
34 stockés dans le répertoire <filename role="special"
35 class="directory">.hg/store/data</filename>. Un filelog contient
36 des informations de deux types: les données de révision, et un index
37 pour permettre à Mercurial une recherche efficace d'une révision
38 donnée.</para>
40 <para id="x_2ec">Lorsqu'un fichier devient trop gros ou a un long
41 historique, son filelog se voit stocker dans un fichier de données
42 (avec un suffixe <quote><literal>.d</literal></quote>) et un fichier
43 index (avec un suffixe<quote><literal>.i</literal></quote>)
44 distincts. La relation entre un fichier dans le répertoire de travail
45 et le filelog couvrant le suivi de son historique dans le dépôt est
46 illustré à la figure <xref linkend="fig:concepts:filelog"/>.</para>
48 <figure id="fig:concepts:filelog">
49 <title>Relations entre les fichiers dans le répertoire de travail et
50 leurs filelogs dans le dépôt</title>
51 <mediaobject> <imageobject><imagedata
52 fileref="figs/filelog.png"/></imageobject>
53 <textobject><phrase>XXX add text</phrase></textobject>
54 </mediaobject> </figure>
56 </sect2>
57 <sect2>
58 <title>Gestion des fichiers suivis</title>
60 <para id="x_2ee">Mercurial a recours à une structure nommée
61 <emphasis>manifest</emphasis> pour rassembler les informations sur
62 les fichiers dont il gère le suivi. Chaque entrée dans ce manifest
63 contient des informations sur les fichiers présents dans une révision
64 donnée. Une entrée store la liste des fichiers faisant partie de la
65 révision, la version de chaque fichier, et quelques autres
66 métadonnées sur ces fichiers.</para>
68 </sect2>
69 <sect2>
70 <title>Recording changeset information</title>
72 <para id="x_2ef">The <emphasis>changelog</emphasis> contains
73 information about each changeset. Each revision records who
74 committed a change, the changeset comment, other pieces of
75 changeset-related information, and the revision of the manifest to
76 use.</para>
78 </sect2>
79 <sect2>
80 <title>Relationships between revisions</title>
82 <para id="x_2f0">Within a changelog, a manifest, or a filelog, each
83 revision stores a pointer to its immediate parent (or to its
84 two parents, if it's a merge revision). As I mentioned above,
85 there are also relationships between revisions
86 <emphasis>across</emphasis> these structures, and they are
87 hierarchical in nature.</para>
89 <para id="x_2f1">For every changeset in a repository, there is exactly one
90 revision stored in the changelog. Each revision of the
91 changelog contains a pointer to a single revision of the
92 manifest. A revision of the manifest stores a pointer to a
93 single revision of each filelog tracked when that changeset
94 was created. These relationships are illustrated in
95 <xref linkend="fig:concepts:metadata"/>.</para>
97 <figure id="fig:concepts:metadata">
98 <title>Metadata relationships</title>
99 <mediaobject>
100 <imageobject><imagedata fileref="figs/metadata.png"/></imageobject>
101 <textobject><phrase>XXX add text</phrase></textobject>
102 </mediaobject>
103 </figure>
105 <para id="x_2f3">As the illustration shows, there is
106 <emphasis>not</emphasis> a <quote>one to one</quote>
107 relationship between revisions in the changelog, manifest, or
108 filelog. If a file that
109 Mercurial tracks hasn't changed between two changesets, the
110 entry for that file in the two revisions of the manifest will
111 point to the same revision of its filelog<footnote>
112 <para id="x_725">It is possible (though unusual) for the manifest to
113 remain the same between two changesets, in which case the
114 changelog entries for those changesets will point to the
115 same revision of the manifest.</para>
116 </footnote>.</para>
118 </sect2>
119 </sect1>
120 <sect1>
121 <title>Safe, efficient storage</title>
123 <para id="x_2f4">The underpinnings of changelogs, manifests, and filelogs are
124 provided by a single structure called the
125 <emphasis>revlog</emphasis>.</para>
127 <sect2>
128 <title>Efficient storage</title>
130 <para id="x_2f5">The revlog provides efficient storage of revisions using a
131 <emphasis>delta</emphasis> mechanism. Instead of storing a
132 complete copy of a file for each revision, it stores the
133 changes needed to transform an older revision into the new
134 revision. For many kinds of file data, these deltas are
135 typically a fraction of a percent of the size of a full copy
136 of a file.</para>
138 <para id="x_2f6">Some obsolete revision control systems can only work with
139 deltas of text files. They must either store binary files as
140 complete snapshots or encoded into a text representation, both
141 of which are wasteful approaches. Mercurial can efficiently
142 handle deltas of files with arbitrary binary contents; it
143 doesn't need to treat text as special.</para>
145 </sect2>
146 <sect2 id="sec:concepts:txn">
147 <title>Safe operation</title>
149 <para id="x_2f7">Mercurial only ever <emphasis>appends</emphasis> data to
150 the end of a revlog file. It never modifies a section of a
151 file after it has written it. This is both more robust and
152 efficient than schemes that need to modify or rewrite
153 data.</para>
155 <para id="x_2f8">In addition, Mercurial treats every write as part of a
156 <emphasis>transaction</emphasis> that can span a number of
157 files. A transaction is <emphasis>atomic</emphasis>: either
158 the entire transaction succeeds and its effects are all
159 visible to readers in one go, or the whole thing is undone.
160 This guarantee of atomicity means that if you're running two
161 copies of Mercurial, where one is reading data and one is
162 writing it, the reader will never see a partially written
163 result that might confuse it.</para>
165 <para id="x_2f9">The fact that Mercurial only appends to files makes it
166 easier to provide this transactional guarantee. The easier it
167 is to do stuff like this, the more confident you should be
168 that it's done correctly.</para>
170 </sect2>
171 <sect2>
172 <title>Fast retrieval</title>
174 <para id="x_2fa">Mercurial cleverly avoids a pitfall common to
175 all earlier revision control systems: the problem of
176 <emphasis>inefficient retrieval</emphasis>. Most revision
177 control systems store the contents of a revision as an
178 incremental series of modifications against a
179 <quote>snapshot</quote>. (Some base the snapshot on the
180 oldest revision, others on the newest.) To reconstruct a
181 specific revision, you must first read the snapshot, and then
182 every one of the revisions between the snapshot and your
183 target revision. The more history that a file accumulates,
184 the more revisions you must read, hence the longer it takes to
185 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
213 have ever watched a TV feed through a digital cable or
214 satellite service, you may know that most video compression
215 schemes store each frame of video as a delta against its
216 predecessor frame.</para>
218 <para id="x_2ff">Mercurial borrows this idea to make it
219 possible to reconstruct a revision from a snapshot and a
220 small number of deltas.</para>
222 </sect3>
223 </sect2>
224 <sect2>
225 <title>Identification and strong integrity</title>
227 <para id="x_300">Along with delta or snapshot information, a revlog entry
228 contains a cryptographic hash of the data that it represents.
229 This makes it difficult to forge the contents of a revision,
230 and easy to detect accidental corruption.</para>
232 <para id="x_301">Hashes provide more than a mere check against corruption;
233 they are used as the identifiers for revisions. The changeset
234 identification hashes that you see as an end user are from
235 revisions of the changelog. Although filelogs and the
236 manifest also use hashes, Mercurial only uses these behind the
237 scenes.</para>
239 <para id="x_302">Mercurial verifies that hashes are correct when it
240 retrieves file revisions and when it pulls changes from
241 another repository. If it encounters an integrity problem, it
242 will complain and stop whatever it's doing.</para>
244 <para id="x_303">In addition to the effect it has on retrieval efficiency,
245 Mercurial's use of periodic snapshots makes it more robust
246 against partial data corruption. If a revlog becomes partly
247 corrupted due to a hardware error or system bug, it's often
248 possible to reconstruct some or most revisions from the
249 uncorrupted sections of the revlog, both before and after the
250 corrupted section. This would not be possible with a
251 delta-only storage model.</para>
252 </sect2>
253 </sect1>
255 <sect1>
256 <title>Revision history, branching, and merging</title>
258 <para id="x_304">Every entry in a Mercurial revlog knows the identity of its
259 immediate ancestor revision, usually referred to as its
260 <emphasis>parent</emphasis>. In fact, a revision contains room
261 for not one parent, but two. Mercurial uses a special hash,
262 called the <quote>null ID</quote>, to represent the idea
263 <quote>there is no parent here</quote>. This hash is simply a
264 string of zeroes.</para>
266 <para id="x_305">In <xref linkend="fig:concepts:revlog"/>, you can see
267 an example of the conceptual structure of a revlog. Filelogs,
268 manifests, and changelogs all have this same structure; they
269 differ only in the kind of data stored in each delta or
270 snapshot.</para>
272 <para id="x_306">The first revision in a revlog (at the bottom of the image)
273 has the null ID in both of its parent slots. For a
274 <quote>normal</quote> revision, its first parent slot contains
275 the ID of its parent revision, and its second contains the null
276 ID, indicating that the revision has only one real parent. Any
277 two revisions that have the same parent ID are branches. A
278 revision that represents a merge between branches has two normal
279 revision IDs in its parent slots.</para>
281 <figure id="fig:concepts:revlog">
282 <title>The conceptual structure of a revlog</title>
283 <mediaobject>
284 <imageobject><imagedata fileref="figs/revlog.png"/></imageobject>
285 <textobject><phrase>XXX add text</phrase></textobject>
286 </mediaobject>
287 </figure>
289 </sect1>
290 <sect1>
291 <title>The working directory</title>
293 <para id="x_307">In the working directory, Mercurial stores a snapshot of the
294 files from the repository as of a particular changeset.</para>
296 <para id="x_308">The working directory <quote>knows</quote> which changeset
297 it contains. When you update the working directory to contain a
298 particular changeset, Mercurial looks up the appropriate
299 revision of the manifest to find out which files it was tracking
300 at the time that changeset was committed, and which revision of
301 each file was then current. It then recreates a copy of each of
302 those files, with the same contents it had when the changeset
303 was committed.</para>
305 <para id="x_309">The <emphasis>dirstate</emphasis> is a special
306 structure that contains Mercurial's knowledge of the working
307 directory. It is maintained as a file named
308 <filename>.hg/dirstate</filename> inside a repository. The
309 dirstate details which changeset the working directory is
310 updated to, and all of the files that Mercurial is tracking in
311 the working directory. It also lets Mercurial quickly notice
312 changed files, by recording their checkout times and
313 sizes.</para>
315 <para id="x_30a">Just as a revision of a revlog has room for two parents, so
316 that it can represent either a normal revision (with one parent)
317 or a merge of two earlier revisions, the dirstate has slots for
318 two parents. When you use the <command role="hg-cmd">hg
319 update</command> command, the changeset that you update to is
320 stored in the <quote>first parent</quote> slot, and the null ID
321 in the second. When you <command role="hg-cmd">hg
322 merge</command> with another changeset, the first parent
323 remains unchanged, and the second parent is filled in with the
324 changeset you're merging with. The <command role="hg-cmd">hg
325 parents</command> command tells you what the parents of the
326 dirstate are.</para>
328 <sect2>
329 <title>What happens when you commit</title>
331 <para id="x_30b">The dirstate stores parent information for more than just
332 book-keeping purposes. Mercurial uses the parents of the
333 dirstate as <emphasis>the parents of a new
334 changeset</emphasis> when you perform a commit.</para>
336 <figure id="fig:concepts:wdir">
337 <title>The working directory can have two parents</title>
338 <mediaobject>
339 <imageobject><imagedata fileref="figs/wdir.png"/></imageobject>
340 <textobject><phrase>XXX add text</phrase></textobject>
341 </mediaobject>
342 </figure>
344 <para id="x_30d"><xref linkend="fig:concepts:wdir"/> shows the
345 normal state of the working directory, where it has a single
346 changeset as parent. That changeset is the
347 <emphasis>tip</emphasis>, the newest changeset in the
348 repository that has no children.</para>
350 <figure id="fig:concepts:wdir-after-commit">
351 <title>The working directory gains new parents after a
352 commit</title>
353 <mediaobject>
354 <imageobject><imagedata fileref="figs/wdir-after-commit.png"/></imageobject>
355 <textobject><phrase>XXX add text</phrase></textobject>
356 </mediaobject>
357 </figure>
359 <para id="x_30f">It's useful to think of the working directory as
360 <quote>the changeset I'm about to commit</quote>. Any files
361 that you tell Mercurial that you've added, removed, renamed,
362 or copied will be reflected in that changeset, as will
363 modifications to any files that Mercurial is already tracking;
364 the new changeset will have the parents of the working
365 directory as its parents.</para>
367 <para id="x_310">After a commit, Mercurial will update the
368 parents of the working directory, so that the first parent is
369 the ID of the new changeset, and the second is the null ID.
370 This is shown in <xref
371 linkend="fig:concepts:wdir-after-commit"/>. Mercurial
372 doesn't touch any of the files in the working directory when
373 you commit; it just modifies the dirstate to note its new
374 parents.</para>
376 </sect2>
377 <sect2>
378 <title>Creating a new head</title>
380 <para id="x_311">It's perfectly normal to update the working directory to a
381 changeset other than the current tip. For example, you might
382 want to know what your project looked like last Tuesday, or
383 you could be looking through changesets to see which one
384 introduced a bug. In cases like this, the natural thing to do
385 is update the working directory to the changeset you're
386 interested in, and then examine the files in the working
387 directory directly to see their contents as they were when you
388 committed that changeset. The effect of this is shown in
389 <xref linkend="fig:concepts:wdir-pre-branch"/>.</para>
391 <figure id="fig:concepts:wdir-pre-branch">
392 <title>The working directory, updated to an older
393 changeset</title>
394 <mediaobject>
395 <imageobject><imagedata fileref="figs/wdir-pre-branch.png"/></imageobject>
396 <textobject><phrase>XXX add text</phrase></textobject>
397 </mediaobject>
398 </figure>
400 <para id="x_313">Having updated the working directory to an
401 older changeset, what happens if you make some changes, and
402 then commit? Mercurial behaves in the same way as I outlined
403 above. The parents of the working directory become the
404 parents of the new changeset. This new changeset has no
405 children, so it becomes the new tip. And the repository now
406 contains two changesets that have no children; we call these
407 <emphasis>heads</emphasis>. You can see the structure that
408 this creates in <xref
409 linkend="fig:concepts:wdir-branch"/>.</para>
411 <figure id="fig:concepts:wdir-branch">
412 <title>After a commit made while synced to an older
413 changeset</title>
414 <mediaobject>
415 <imageobject><imagedata fileref="figs/wdir-branch.png"/></imageobject>
416 <textobject><phrase>XXX add text</phrase></textobject>
417 </mediaobject>
418 </figure>
420 <note>
421 <para id="x_315">If you're new to Mercurial, you should keep
422 in mind a common <quote>error</quote>, which is to use the
423 <command role="hg-cmd">hg pull</command> command without any
424 options. By default, the <command role="hg-cmd">hg
425 pull</command> command <emphasis>does not</emphasis>
426 update the working directory, so you'll bring new changesets
427 into your repository, but the working directory will stay
428 synced at the same changeset as before the pull. If you
429 make some changes and commit afterwards, you'll thus create
430 a new head, because your working directory isn't synced to
431 whatever the current tip is. To combine the operation of a
432 pull, followed by an update, run <command>hg pull
433 -u</command>.</para>
435 <para id="x_316">I put the word <quote>error</quote> in quotes
436 because all that you need to do to rectify the situation
437 where you created a new head by accident is
438 <command role="hg-cmd">hg merge</command>, then <command
439 role="hg-cmd">hg commit</command>. In other words, this
440 almost never has negative consequences; it's just something
441 of a surprise for newcomers. I'll discuss other ways to
442 avoid this behavior, and why Mercurial behaves in this
443 initially surprising way, later on.</para>
444 </note>
446 </sect2>
447 <sect2>
448 <title>Merging changes</title>
450 <para id="x_317">When you run the <command role="hg-cmd">hg
451 merge</command> command, Mercurial leaves the first parent
452 of the working directory unchanged, and sets the second parent
453 to the changeset you're merging with, as shown in <xref
454 linkend="fig:concepts:wdir-merge"/>.</para>
456 <figure id="fig:concepts:wdir-merge">
457 <title>Merging two heads</title>
458 <mediaobject>
459 <imageobject>
460 <imagedata fileref="figs/wdir-merge.png"/>
461 </imageobject>
462 <textobject><phrase>XXX add text</phrase></textobject>
463 </mediaobject>
464 </figure>
466 <para id="x_319">Mercurial also has to modify the working directory, to
467 merge the files managed in the two changesets. Simplified a
468 little, the merging process goes like this, for every file in
469 the manifests of both changesets.</para>
470 <itemizedlist>
471 <listitem><para id="x_31a">If neither changeset has modified a file, do
472 nothing with that file.</para>
473 </listitem>
474 <listitem><para id="x_31b">If one changeset has modified a file, and the
475 other hasn't, create the modified copy of the file in the
476 working directory.</para>
477 </listitem>
478 <listitem><para id="x_31c">If one changeset has removed a file, and the
479 other hasn't (or has also deleted it), delete the file
480 from the working directory.</para>
481 </listitem>
482 <listitem><para id="x_31d">If one changeset has removed a file, but the
483 other has modified the file, ask the user what to do: keep
484 the modified file, or remove it?</para>
485 </listitem>
486 <listitem><para id="x_31e">If both changesets have modified a file,
487 invoke an external merge program to choose the new
488 contents for the merged file. This may require input from
489 the user.</para>
490 </listitem>
491 <listitem><para id="x_31f">If one changeset has modified a file, and the
492 other has renamed or copied the file, make sure that the
493 changes follow the new name of the file.</para>
494 </listitem></itemizedlist>
495 <para id="x_320">There are more details&emdash;merging has plenty of corner
496 cases&emdash;but these are the most common choices that are
497 involved in a merge. As you can see, most cases are
498 completely automatic, and indeed most merges finish
499 automatically, without requiring your input to resolve any
500 conflicts.</para>
502 <para id="x_321">When you're thinking about what happens when you commit
503 after a merge, once again the working directory is <quote>the
504 changeset I'm about to commit</quote>. After the <command
505 role="hg-cmd">hg merge</command> command completes, the
506 working directory has two parents; these will become the
507 parents of the new changeset.</para>
509 <para id="x_322">Mercurial lets you perform multiple merges, but
510 you must commit the results of each individual merge as you
511 go. This is necessary because Mercurial only tracks two
512 parents for both revisions and the working directory. While
513 it would be technically feasible to merge multiple changesets
514 at once, Mercurial avoids this for simplicity. With multi-way
515 merges, the risks of user confusion, nasty conflict
516 resolution, and making a terrible mess of a merge would grow
517 intolerable.</para>
519 </sect2>
521 <sect2>
522 <title>Merging and renames</title>
524 <para id="x_69a">A surprising number of revision control systems pay little
525 or no attention to a file's <emphasis>name</emphasis> over
526 time. For instance, it used to be common that if a file got
527 renamed on one side of a merge, the changes from the other
528 side would be silently dropped.</para>
530 <para id="x_69b">Mercurial records metadata when you tell it to perform a
531 rename or copy. It uses this metadata during a merge to do the
532 right thing in the case of a merge. For instance, if I rename
533 a file, and you edit it without renaming it, when we merge our
534 work the file will be renamed and have your edits
535 applied.</para>
536 </sect2>
537 </sect1>
539 <sect1>
540 <title>Other interesting design features</title>
542 <para id="x_323">In the sections above, I've tried to highlight some of the
543 most important aspects of Mercurial's design, to illustrate that
544 it pays careful attention to reliability and performance.
545 However, the attention to detail doesn't stop there. There are
546 a number of other aspects of Mercurial's construction that I
547 personally find interesting. I'll detail a few of them here,
548 separate from the <quote>big ticket</quote> items above, so that
549 if you're interested, you can gain a better idea of the amount
550 of thinking that goes into a well-designed system.</para>
552 <sect2>
553 <title>Clever compression</title>
555 <para id="x_324">When appropriate, Mercurial will store both snapshots and
556 deltas in compressed form. It does this by always
557 <emphasis>trying to</emphasis> compress a snapshot or delta,
558 but only storing the compressed version if it's smaller than
559 the uncompressed version.</para>
561 <para id="x_325">This means that Mercurial does <quote>the right
562 thing</quote> when storing a file whose native form is
563 compressed, such as a <literal>zip</literal> archive or a JPEG
564 image. When these types of files are compressed a second
565 time, the resulting file is usually bigger than the
566 once-compressed form, and so Mercurial will store the plain
567 <literal>zip</literal> or JPEG.</para>
569 <para id="x_326">Deltas between revisions of a compressed file are usually
570 larger than snapshots of the file, and Mercurial again does
571 <quote>the right thing</quote> in these cases. It finds that
572 such a delta exceeds the threshold at which it should store a
573 complete snapshot of the file, so it stores the snapshot,
574 again saving space compared to a naive delta-only
575 approach.</para>
577 <sect3>
578 <title>Network recompression</title>
580 <para id="x_327">When storing revisions on disk, Mercurial uses the
581 <quote>deflate</quote> compression algorithm (the same one
582 used by the popular <literal>zip</literal> archive format),
583 which balances good speed with a respectable compression
584 ratio. However, when transmitting revision data over a
585 network connection, Mercurial uncompresses the compressed
586 revision data.</para>
588 <para id="x_328">If the connection is over HTTP, Mercurial recompresses
589 the entire stream of data using a compression algorithm that
590 gives a better compression ratio (the Burrows-Wheeler
591 algorithm from the widely used <literal>bzip2</literal>
592 compression package). This combination of algorithm and
593 compression of the entire stream (instead of a revision at a
594 time) substantially reduces the number of bytes to be
595 transferred, yielding better network performance over most
596 kinds of network.</para>
598 <para id="x_329">If the connection is over
599 <command>ssh</command>, Mercurial
600 <emphasis>doesn't</emphasis> recompress the stream, because
601 <command>ssh</command> can already do this itself. You can
602 tell Mercurial to always use <command>ssh</command>'s
603 compression feature by editing the
604 <filename>.hgrc</filename> file in your home directory as
605 follows.</para>
607 <programlisting>[ui]
608 ssh = ssh -C</programlisting>
610 </sect3>
611 </sect2>
612 <sect2>
613 <title>Read/write ordering and atomicity</title>
615 <para id="x_32a">Appending to files isn't the whole story when
616 it comes to guaranteeing that a reader won't see a partial
617 write. If you recall <xref linkend="fig:concepts:metadata"/>,
618 revisions in the changelog point to revisions in the manifest,
619 and revisions in the manifest point to revisions in filelogs.
620 This hierarchy is deliberate.</para>
622 <para id="x_32b">A writer starts a transaction by writing filelog and
623 manifest data, and doesn't write any changelog data until
624 those are finished. A reader starts by reading changelog
625 data, then manifest data, followed by filelog data.</para>
627 <para id="x_32c">Since the writer has always finished writing filelog and
628 manifest data before it writes to the changelog, a reader will
629 never read a pointer to a partially written manifest revision
630 from the changelog, and it will never read a pointer to a
631 partially written filelog revision from the manifest.</para>
633 </sect2>
634 <sect2>
635 <title>Concurrent access</title>
637 <para id="x_32d">The read/write ordering and atomicity guarantees mean that
638 Mercurial never needs to <emphasis>lock</emphasis> a
639 repository when it's reading data, even if the repository is
640 being written to while the read is occurring. This has a big
641 effect on scalability; you can have an arbitrary number of
642 Mercurial processes safely reading data from a repository
643 all at once, no matter whether it's being written to or
644 not.</para>
646 <para id="x_32e">The lockless nature of reading means that if you're
647 sharing a repository on a multi-user system, you don't need to
648 grant other local users permission to
649 <emphasis>write</emphasis> to your repository in order for
650 them to be able to clone it or pull changes from it; they only
651 need <emphasis>read</emphasis> permission. (This is
652 <emphasis>not</emphasis> a common feature among revision
653 control systems, so don't take it for granted! Most require
654 readers to be able to lock a repository to access it safely,
655 and this requires write permission on at least one directory,
656 which of course makes for all kinds of nasty and annoying
657 security and administrative problems.)</para>
659 <para id="x_32f">Mercurial uses locks to ensure that only one process can
660 write to a repository at a time (the locking mechanism is safe
661 even over filesystems that are notoriously hostile to locking,
662 such as NFS). If a repository is locked, a writer will wait
663 for a while to retry if the repository becomes unlocked, but
664 if the repository remains locked for too long, the process
665 attempting to write will time out after a while. This means
666 that your daily automated scripts won't get stuck forever and
667 pile up if a system crashes unnoticed, for example. (Yes, the
668 timeout is configurable, from zero to infinity.)</para>
670 <sect3>
671 <title>Safe dirstate access</title>
673 <para id="x_330">As with revision data, Mercurial doesn't take a lock to
674 read the dirstate file; it does acquire a lock to write it.
675 To avoid the possibility of reading a partially written copy
676 of the dirstate file, Mercurial writes to a file with a
677 unique name in the same directory as the dirstate file, then
678 renames the temporary file atomically to
679 <filename>dirstate</filename>. The file named
680 <filename>dirstate</filename> is thus guaranteed to be
681 complete, not partially written.</para>
683 </sect3>
684 </sect2>
685 <sect2>
686 <title>Avoiding seeks</title>
688 <para id="x_331">Critical to Mercurial's performance is the avoidance of
689 seeks of the disk head, since any seek is far more expensive
690 than even a comparatively large read operation.</para>
692 <para id="x_332">This is why, for example, the dirstate is stored in a
693 single file. If there were a dirstate file per directory that
694 Mercurial tracked, the disk would seek once per directory.
695 Instead, Mercurial reads the entire single dirstate file in
696 one step.</para>
698 <para id="x_333">Mercurial also uses a <quote>copy on write</quote> scheme
699 when cloning a repository on local storage. Instead of
700 copying every revlog file from the old repository into the new
701 repository, it makes a <quote>hard link</quote>, which is a
702 shorthand way to say <quote>these two names point to the same
703 file</quote>. When Mercurial is about to write to one of a
704 revlog's files, it checks to see if the number of names
705 pointing at the file is greater than one. If it is, more than
706 one repository is using the file, so Mercurial makes a new
707 copy of the file that is private to this repository.</para>
709 <para id="x_334">A few revision control developers have pointed out that
710 this idea of making a complete private copy of a file is not
711 very efficient in its use of storage. While this is true,
712 storage is cheap, and this method gives the highest
713 performance while deferring most book-keeping to the operating
714 system. An alternative scheme would most likely reduce
715 performance and increase the complexity of the software, but
716 speed and simplicity are key to the <quote>feel</quote> of
717 day-to-day use.</para>
719 </sect2>
720 <sect2>
721 <title>Other contents of the dirstate</title>
723 <para id="x_335">Because Mercurial doesn't force you to tell it when you're
724 modifying a file, it uses the dirstate to store some extra
725 information so it can determine efficiently whether you have
726 modified a file. For each file in the working directory, it
727 stores the time that it last modified the file itself, and the
728 size of the file at that time.</para>
730 <para id="x_336">When you explicitly <command role="hg-cmd">hg
731 add</command>, <command role="hg-cmd">hg remove</command>,
732 <command role="hg-cmd">hg rename</command> or <command
733 role="hg-cmd">hg copy</command> files, Mercurial updates the
734 dirstate so that it knows what to do with those files when you
735 commit.</para>
737 <para id="x_337">The dirstate helps Mercurial to efficiently
738 check the status of files in a repository.</para>
740 <itemizedlist>
741 <listitem>
742 <para id="x_726">When Mercurial checks the state of a file in the
743 working directory, it first checks a file's modification
744 time against the time in the dirstate that records when
745 Mercurial last wrote the file. If the last modified time
746 is the same as the time when Mercurial wrote the file, the
747 file must not have been modified, so Mercurial does not
748 need to check any further.</para>
749 </listitem>
750 <listitem>
751 <para id="x_727">If the file's size has changed, the file must have
752 been modified. If the modification time has changed, but
753 the size has not, only then does Mercurial need to
754 actually read the contents of the file to see if it has
755 changed.</para>
756 </listitem>
757 </itemizedlist>
759 <para id="x_728">Storing the modification time and size dramatically
760 reduces the number of read operations that Mercurial needs to
761 perform when we run commands like <command>hg status</command>.
762 This results in large performance improvements.</para>
763 </sect2>
764 </sect1>
765 </chapter>
767 <!--
768 local variables:
769 sgml-parent-document: ("00book.xml" "book" "chapter")
770 end:
771 -->