hgbook
view fr/ch04-concepts.xml @ 991:e6894aa7baf2
French translation; ch04-concepts.xml; 10percent
| author | Jean-Marie Clément <JeanMarieClement@web.de> |
|---|---|
| date | Mon Sep 07 23:16:08 2009 +0200 (2009-09-07) |
| parents | 6b680d569bb4 |
| children | 71dbda516572 |
line source
1 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
3 <chapter>
4 <title>Derrière le décor</title>
5 <para>\label{chap:concepts}</para>
7 <para>À 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.
12 </para>
14 <para>En effet, cette compréhension m'apporte la confiance que Mercurial a été
15 développé avec soin pour être à la fois <emphasis>sûr</emphasis> et
16 <emphasis>efficace</emphasis>. De surcroît, si il m'est facile de
17 garder en tête ce que le logiciel fait lorsque j'accompli des
18 tâches de révision, j'aurai moins de risques d'être surpris par
19 son comportement.</para>
21 <para>Dans ce chapitre, nous décrirons tout d'abord les concepts
22 essentiels de l'architecture de Mercurial, pour ensuite discuter
23 quelques uns des détails intéressants de son implémentation.
24 </para>
26 <sect1>
27 <title>Conservation de l'historique sous Mercurial</title>
29 <sect2>
30 <title>Suivi de l'historique pour un seul fichier</title>
32 <para>
33 Lorsque Mercurial effectue un suivi des modifications faites à un
34 fichier, il conserve l'historique pour ce fichier dans un
35 <emphasis>filelog</emphasis> sous forme de métadonnées.
36 Chaque entrée dans le filelog contient assez d'informations pour
37 reconstituer une révision du fichier correspondant.
38 Les filelogs sont des fichiers stockés dans le répertoire
39 <filename role="special" class="directory">.hg/store/data</filename>.
40 Un filelog contient des informations de deux types: les données de
41 révision, et un index pour permettre à Mercurial une recherche
42 efficace d'une révision donnée.
43 </para>
45 <para>
46 Lorsqu'un fichier devient trop gros ou a un long historique, son
47 filelog se voit stocker dans un fichier de données (avec un suffixe
48 <quote><literal>.d</literal></quote>) et un fichier index (avec un
49 suffixe<quote><literal>.i</literal></quote>) distincts.
50 La relation entre un fichier dans le répertoire de travail et le
51 filelog couvrant le suivi de son historique dans le dépôt est
52 illustré à la figure <xref linkend="fig:concepts:filelog"/>.
53 </para>
55 <informalfigure>
57 <para> <mediaobject><imageobject><imagedata fileref="filelog"/></imageobject><textobject><phrase>XXX add text</phrase></textobject></mediaobject>
58 \caption{Relation entre les fichiers dans le répertoire de travail
59 et leurs filelogs dans le dépôt}
60 \label{fig:concepts:filelog}</para>
61 </informalfigure>
63 </sect2>
64 <sect2>
65 <title>Gestion des fichiers suivis</title>
67 <para>
68 Mercurial a recours à une structure nommée <emphasis>manifest</emphasis>
69 pour rassembler les informations sur les fichiers dont il gère le suivi.
70 Chaque entrée dans ce manifest contient des informations sur les fichiers
71 présents dans une révision donnée. Une entrée store la liste des fichiers faisant
72 partie de la révision, la version de chaque fichier, et quelques autres
73 métadonnées sur ces fichiers.
74 </para>
76 </sect2>
77 <sect2>
78 <title>Recording changeset information</title>
80 <para>The <emphasis>changelog</emphasis> contains information about each changeset. Each
81 revision records who committed a change, the changeset comment, other
82 pieces of changeset-related information, and the revision of the
83 manifest to use.
84 </para>
86 </sect2>
87 <sect2>
88 <title>Relationships between revisions</title>
90 <para>Within a changelog, a manifest, or a filelog, each revision stores a
91 pointer to its immediate parent (or to its two parents, if it's a
92 merge revision). As I mentioned above, there are also relationships
93 between revisions <emphasis>across</emphasis> these structures, and they are
94 hierarchical in nature.
95 </para>
97 <para>For every changeset in a repository, there is exactly one revision
98 stored in the changelog. Each revision of the changelog contains a
99 pointer to a single revision of the manifest. A revision of the
100 manifest stores a pointer to a single revision of each filelog tracked
101 when that changeset was created. These relationships are illustrated
102 in figure <xref linkend="fig:concepts:metadata"/>.
103 </para>
105 <informalfigure>
107 <para> <mediaobject><imageobject><imagedata fileref="metadata"/></imageobject><textobject><phrase>XXX add text</phrase></textobject></mediaobject>
108 <caption><para>Metadata relationships</para></caption>
109 \label{fig:concepts:metadata}
110 </para>
111 </informalfigure>
113 <para>As the illustration shows, there is <emphasis>not</emphasis> a <quote>one to one</quote>
114 relationship between revisions in the changelog, manifest, or filelog.
115 If the manifest hasn't changed between two changesets, the changelog
116 entries for those changesets will point to the same revision of the
117 manifest. If a file that Mercurial tracks hasn't changed between two
118 changesets, the entry for that file in the two revisions of the
119 manifest will point to the same revision of its filelog.
120 </para>
122 </sect2>
123 </sect1>
124 <sect1>
125 <title>Safe, efficient storage</title>
127 <para>The underpinnings of changelogs, manifests, and filelogs are provided
128 by a single structure called the <emphasis>revlog</emphasis>.
129 </para>
131 <sect2>
132 <title>Efficient storage</title>
134 <para>The revlog provides efficient storage of revisions using a
135 <emphasis>delta</emphasis> mechanism. Instead of storing a complete copy of a file
136 for each revision, it stores the changes needed to transform an older
137 revision into the new revision. For many kinds of file data, these
138 deltas are typically a fraction of a percent of the size of a full
139 copy of a file.
140 </para>
142 <para>Some obsolete revision control systems can only work with deltas of
143 text files. They must either store binary files as complete snapshots
144 or encoded into a text representation, both of which are wasteful
145 approaches. Mercurial can efficiently handle deltas of files with
146 arbitrary binary contents; it doesn't need to treat text as special.
147 </para>
149 </sect2>
150 <sect2>
151 <title>Safe operation</title>
152 <para>\label{sec:concepts:txn}
153 </para>
155 <para>Mercurial only ever <emphasis>appends</emphasis> data to the end of a revlog file.
156 It never modifies a section of a file after it has written it. This
157 is both more robust and efficient than schemes that need to modify or
158 rewrite data.
159 </para>
161 <para>In addition, Mercurial treats every write as part of a
162 <emphasis>transaction</emphasis> that can span a number of files. A transaction is
163 <emphasis>atomic</emphasis>: either the entire transaction succeeds and its effects
164 are all visible to readers in one go, or the whole thing is undone.
165 This guarantee of atomicity means that if you're running two copies of
166 Mercurial, where one is reading data and one is writing it, the reader
167 will never see a partially written result that might confuse it.
168 </para>
170 <para>The fact that Mercurial only appends to files makes it easier to
171 provide this transactional guarantee. The easier it is to do stuff
172 like this, the more confident you should be that it's done correctly.
173 </para>
175 </sect2>
176 <sect2>
177 <title>Fast retrieval</title>
179 <para>Mercurial cleverly avoids a pitfall common to all earlier
180 revision control systems: the problem of <emphasis>inefficient retrieval</emphasis>.
181 Most revision control systems store the contents of a revision as an
182 incremental series of modifications against a <quote>snapshot</quote>. To
183 reconstruct a specific revision, you must first read the snapshot, and
184 then every one of the revisions between the snapshot and your target
185 revision. The more history that a file accumulates, the more
186 revisions you must read, hence the longer it takes to reconstruct a
187 particular revision.
188 </para>
190 <informalfigure>
192 <para> <mediaobject><imageobject><imagedata fileref="snapshot"/></imageobject><textobject><phrase>XXX add text</phrase></textobject></mediaobject>
193 <caption><para>Snapshot of a revlog, with incremental deltas</para></caption>
194 \label{fig:concepts:snapshot}
195 </para>
196 </informalfigure>
198 <para>The innovation that Mercurial applies to this problem is simple but
199 effective. Once the cumulative amount of delta information stored
200 since the last snapshot exceeds a fixed threshold, it stores a new
201 snapshot (compressed, of course), instead of another delta. This
202 makes it possible to reconstruct <emphasis>any</emphasis> revision of a file
203 quickly. This approach works so well that it has since been copied by
204 several other revision control systems.
205 </para>
207 <para>Figure <xref linkend="fig:concepts:snapshot"/> illustrates the idea. In an entry
208 in a revlog's index file, Mercurial stores the range of entries from
209 the data file that it must read to reconstruct a particular revision.
210 </para>
212 <sect3>
213 <title>Aside: the influence of video compression</title>
215 <para>If you're familiar with video compression or have ever watched a TV
216 feed through a digital cable or satellite service, you may know that
217 most video compression schemes store each frame of video as a delta
218 against its predecessor frame. In addition, these schemes use
219 <quote>lossy</quote> compression techniques to increase the compression ratio, so
220 visual errors accumulate over the course of a number of inter-frame
221 deltas.
222 </para>
224 <para>Because it's possible for a video stream to <quote>drop out</quote> occasionally
225 due to signal glitches, and to limit the accumulation of artefacts
226 introduced by the lossy compression process, video encoders
227 periodically insert a complete frame (called a <quote>key frame</quote>) into the
228 video stream; the next delta is generated against that frame. This
229 means that if the video signal gets interrupted, it will resume once
230 the next key frame is received. Also, the accumulation of encoding
231 errors restarts anew with each key frame.
232 </para>
234 </sect3>
235 </sect2>
236 <sect2>
237 <title>Identification and strong integrity</title>
239 <para>Along with delta or snapshot information, a revlog entry contains a
240 cryptographic hash of the data that it represents. This makes it
241 difficult to forge the contents of a revision, and easy to detect
242 accidental corruption.
243 </para>
245 <para>Hashes provide more than a mere check against corruption; they are
246 used as the identifiers for revisions. The changeset identification
247 hashes that you see as an end user are from revisions of the
248 changelog. Although filelogs and the manifest also use hashes,
249 Mercurial only uses these behind the scenes.
250 </para>
252 <para>Mercurial verifies that hashes are correct when it retrieves file
253 revisions and when it pulls changes from another repository. If it
254 encounters an integrity problem, it will complain and stop whatever
255 it's doing.
256 </para>
258 <para>In addition to the effect it has on retrieval efficiency, Mercurial's
259 use of periodic snapshots makes it more robust against partial data
260 corruption. If a revlog becomes partly corrupted due to a hardware
261 error or system bug, it's often possible to reconstruct some or most
262 revisions from the uncorrupted sections of the revlog, both before and
263 after the corrupted section. This would not be possible with a
264 delta-only storage model.
265 </para>
267 <para>\section{Revision history, branching,
268 and merging}
269 </para>
271 <para>Every entry in a Mercurial revlog knows the identity of its immediate
272 ancestor revision, usually referred to as its <emphasis>parent</emphasis>. In fact,
273 a revision contains room for not one parent, but two. Mercurial uses
274 a special hash, called the <quote>null ID</quote>, to represent the idea <quote>there
275 is no parent here</quote>. This hash is simply a string of zeroes.
276 </para>
278 <para>In figure <xref linkend="fig:concepts:revlog"/>, you can see an example of the
279 conceptual structure of a revlog. Filelogs, manifests, and changelogs
280 all have this same structure; they differ only in the kind of data
281 stored in each delta or snapshot.
282 </para>
284 <para>The first revision in a revlog (at the bottom of the image) has the
285 null ID in both of its parent slots. For a <quote>normal</quote> revision, its
286 first parent slot contains the ID of its parent revision, and its
287 second contains the null ID, indicating that the revision has only one
288 real parent. Any two revisions that have the same parent ID are
289 branches. A revision that represents a merge between branches has two
290 normal revision IDs in its parent slots.
291 </para>
293 <informalfigure>
295 <para> <mediaobject><imageobject><imagedata fileref="revlog"/></imageobject><textobject><phrase>XXX add text</phrase></textobject></mediaobject>
296 \caption{}
297 \label{fig:concepts:revlog}
298 </para>
299 </informalfigure>
301 </sect2>
302 </sect1>
303 <sect1>
304 <title>The working directory</title>
306 <para>In the working directory, Mercurial stores a snapshot of the files
307 from the repository as of a particular changeset.
308 </para>
310 <para>The working directory <quote>knows</quote> which changeset it contains. When you
311 update the working directory to contain a particular changeset,
312 Mercurial looks up the appropriate revision of the manifest to find
313 out which files it was tracking at the time that changeset was
314 committed, and which revision of each file was then current. It then
315 recreates a copy of each of those files, with the same contents it had
316 when the changeset was committed.
317 </para>
319 <para>The <emphasis>dirstate</emphasis> contains Mercurial's knowledge of the working
320 directory. This details which changeset the working directory is
321 updated to, and all of the files that Mercurial is tracking in the
322 working directory.
323 </para>
325 <para>Just as a revision of a revlog has room for two parents, so that it
326 can represent either a normal revision (with one parent) or a merge of
327 two earlier revisions, the dirstate has slots for two parents. When
328 you use the <command role="hg-cmd">hg update</command> command, the changeset that you update to
329 is stored in the <quote>first parent</quote> slot, and the null ID in the second.
330 When you <command role="hg-cmd">hg merge</command> with another changeset, the first parent
331 remains unchanged, and the second parent is filled in with the
332 changeset you're merging with. The <command role="hg-cmd">hg parents</command> command tells you
333 what the parents of the dirstate are.
334 </para>
336 <sect2>
337 <title>What happens when you commit</title>
339 <para>The dirstate stores parent information for more than just book-keeping
340 purposes. Mercurial uses the parents of the dirstate as \emph{the
341 parents of a new changeset} when you perform a commit.
342 </para>
344 <informalfigure>
346 <para> <mediaobject><imageobject><imagedata fileref="wdir"/></imageobject><textobject><phrase>XXX add text</phrase></textobject></mediaobject>
347 <caption><para>The working directory can have two parents</para></caption>
348 \label{fig:concepts:wdir}
349 </para>
350 </informalfigure>
352 <para>Figure <xref linkend="fig:concepts:wdir"/> shows the normal state of the working
353 directory, where it has a single changeset as parent. That changeset
354 is the <emphasis>tip</emphasis>, the newest changeset in the repository that has no
355 children.
356 </para>
358 <informalfigure>
360 <para> <mediaobject><imageobject><imagedata fileref="wdir-after-commit"/></imageobject><textobject><phrase>XXX add text</phrase></textobject></mediaobject>
361 <caption><para>The working directory gains new parents after a commit</para></caption>
362 \label{fig:concepts:wdir-after-commit}
363 </para>
364 </informalfigure>
366 <para>It's useful to think of the working directory as <quote>the changeset I'm
367 about to commit</quote>. Any files that you tell Mercurial that you've
368 added, removed, renamed, or copied will be reflected in that
369 changeset, as will modifications to any files that Mercurial is
370 already tracking; the new changeset will have the parents of the
371 working directory as its parents.
372 </para>
374 <para>After a commit, Mercurial will update the parents of the working
375 directory, so that the first parent is the ID of the new changeset,
376 and the second is the null ID. This is shown in
377 figure <xref linkend="fig:concepts:wdir-after-commit"/>. Mercurial doesn't touch
378 any of the files in the working directory when you commit; it just
379 modifies the dirstate to note its new parents.
380 </para>
382 </sect2>
383 <sect2>
384 <title>Creating a new head</title>
386 <para>It's perfectly normal to update the working directory to a changeset
387 other than the current tip. For example, you might want to know what
388 your project looked like last Tuesday, or you could be looking through
389 changesets to see which one introduced a bug. In cases like this, the
390 natural thing to do is update the working directory to the changeset
391 you're interested in, and then examine the files in the working
392 directory directly to see their contents as they were when you
393 committed that changeset. The effect of this is shown in
394 figure <xref linkend="fig:concepts:wdir-pre-branch"/>.
395 </para>
397 <informalfigure>
399 <para> <mediaobject><imageobject><imagedata fileref="wdir-pre-branch"/></imageobject><textobject><phrase>XXX add text</phrase></textobject></mediaobject>
400 <caption><para>The working directory, updated to an older changeset</para></caption>
401 \label{fig:concepts:wdir-pre-branch}
402 </para>
403 </informalfigure>
405 <para>Having updated the working directory to an older changeset, what
406 happens if you make some changes, and then commit? Mercurial behaves
407 in the same way as I outlined above. The parents of the working
408 directory become the parents of the new changeset. This new changeset
409 has no children, so it becomes the new tip. And the repository now
410 contains two changesets that have no children; we call these
411 <emphasis>heads</emphasis>. You can see the structure that this creates in
412 figure <xref linkend="fig:concepts:wdir-branch"/>.
413 </para>
415 <informalfigure>
417 <para> <mediaobject><imageobject><imagedata fileref="wdir-branch"/></imageobject><textobject><phrase>XXX add text</phrase></textobject></mediaobject>
418 <caption><para>After a commit made while synced to an older changeset</para></caption>
419 \label{fig:concepts:wdir-branch}
420 </para>
421 </informalfigure>
423 <note>
424 <para> If you're new to Mercurial, you should keep in mind a common
425 <quote>error</quote>, which is to use the <command role="hg-cmd">hg pull</command> command without any
426 options. By default, the <command role="hg-cmd">hg pull</command> command <emphasis>does not</emphasis>
427 update the working directory, so you'll bring new changesets into
428 your repository, but the working directory will stay synced at the
429 same changeset as before the pull. If you make some changes and
430 commit afterwards, you'll thus create a new head, because your
431 working directory isn't synced to whatever the current tip is.
432 </para>
434 <para> I put the word <quote>error</quote> in quotes because all that you need to do
435 to rectify this situation is <command role="hg-cmd">hg merge</command>, then <command role="hg-cmd">hg commit</command>. In
436 other words, this almost never has negative consequences; it just
437 surprises people. I'll discuss other ways to avoid this behaviour,
438 and why Mercurial behaves in this initially surprising way, later
439 on.
440 </para>
441 </note>
443 </sect2>
444 <sect2>
445 <title>Merging heads</title>
447 <para>When you run the <command role="hg-cmd">hg merge</command> command, Mercurial leaves the first
448 parent of the working directory unchanged, and sets the second parent
449 to the changeset you're merging with, as shown in
450 figure <xref linkend="fig:concepts:wdir-merge"/>.
451 </para>
453 <informalfigure>
455 <para> <mediaobject><imageobject><imagedata fileref="wdir-merge"/></imageobject><textobject><phrase>XXX add text</phrase></textobject></mediaobject>
456 <caption><para>Merging two heads</para></caption>
457 \label{fig:concepts:wdir-merge}
458 </para>
459 </informalfigure>
461 <para>Mercurial also has to modify the working directory, to merge the files
462 managed in the two changesets. Simplified a little, the merging
463 process goes like this, for every file in the manifests of both
464 changesets.
465 </para>
466 <itemizedlist>
467 <listitem><para>If neither changeset has modified a file, do nothing with that
468 file.
469 </para>
470 </listitem>
471 <listitem><para>If one changeset has modified a file, and the other hasn't,
472 create the modified copy of the file in the working directory.
473 </para>
474 </listitem>
475 <listitem><para>If one changeset has removed a file, and the other hasn't (or
476 has also deleted it), delete the file from the working directory.
477 </para>
478 </listitem>
479 <listitem><para>If one changeset has removed a file, but the other has modified
480 the file, ask the user what to do: keep the modified file, or remove
481 it?
482 </para>
483 </listitem>
484 <listitem><para>If both changesets have modified a file, invoke an external
485 merge program to choose the new contents for the merged file. This
486 may require input from the user.
487 </para>
488 </listitem>
489 <listitem><para>If one changeset has modified a file, and the other has renamed
490 or copied the file, make sure that the changes follow the new name
491 of the file.
492 </para>
493 </listitem></itemizedlist>
494 <para>There are more details&emdash;merging has plenty of corner cases&emdash;but
495 these are the most common choices that are involved in a merge. As
496 you can see, most cases are completely automatic, and indeed most
497 merges finish automatically, without requiring your input to resolve
498 any conflicts.
499 </para>
501 <para>When you're thinking about what happens when you commit after a merge,
502 once again the working directory is <quote>the changeset I'm about to
503 commit</quote>. After the <command role="hg-cmd">hg merge</command> command completes, the working
504 directory has two parents; these will become the parents of the new
505 changeset.
506 </para>
508 <para>Mercurial lets you perform multiple merges, but you must commit the
509 results of each individual merge as you go. This is necessary because
510 Mercurial only tracks two parents for both revisions and the working
511 directory. While it would be technically possible to merge multiple
512 changesets at once, the prospect of user confusion and making a
513 terrible mess of a merge immediately becomes overwhelming.
514 </para>
516 </sect2>
517 </sect1>
518 <sect1>
519 <title>Other interesting design features</title>
521 <para>In the sections above, I've tried to highlight some of the most
522 important aspects of Mercurial's design, to illustrate that it pays
523 careful attention to reliability and performance. However, the
524 attention to detail doesn't stop there. There are a number of other
525 aspects of Mercurial's construction that I personally find
526 interesting. I'll detail a few of them here, separate from the <quote>big
527 ticket</quote> items above, so that if you're interested, you can gain a
528 better idea of the amount of thinking that goes into a well-designed
529 system.
530 </para>
532 <sect2>
533 <title>Clever compression</title>
535 <para>When appropriate, Mercurial will store both snapshots and deltas in
536 compressed form. It does this by always <emphasis>trying to</emphasis> compress a
537 snapshot or delta, but only storing the compressed version if it's
538 smaller than the uncompressed version.
539 </para>
541 <para>This means that Mercurial does <quote>the right thing</quote> when storing a file
542 whose native form is compressed, such as a <literal>zip</literal> archive or a
543 JPEG image. When these types of files are compressed a second time,
544 the resulting file is usually bigger than the once-compressed form,
545 and so Mercurial will store the plain <literal>zip</literal> or JPEG.
546 </para>
548 <para>Deltas between revisions of a compressed file are usually larger than
549 snapshots of the file, and Mercurial again does <quote>the right thing</quote> in
550 these cases. It finds that such a delta exceeds the threshold at
551 which it should store a complete snapshot of the file, so it stores
552 the snapshot, again saving space compared to a naive delta-only
553 approach.
554 </para>
556 <sect3>
557 <title>Network recompression</title>
559 <para>When storing revisions on disk, Mercurial uses the <quote>deflate</quote>
560 compression algorithm (the same one used by the popular <literal>zip</literal>
561 archive format), which balances good speed with a respectable
562 compression ratio. However, when transmitting revision data over a
563 network connection, Mercurial uncompresses the compressed revision
564 data.
565 </para>
567 <para>If the connection is over HTTP, Mercurial recompresses the entire
568 stream of data using a compression algorithm that gives a better
569 compression ratio (the Burrows-Wheeler algorithm from the widely used
570 <literal>bzip2</literal> compression package). This combination of algorithm
571 and compression of the entire stream (instead of a revision at a time)
572 substantially reduces the number of bytes to be transferred, yielding
573 better network performance over almost all kinds of network.
574 </para>
576 <para>(If the connection is over <command>ssh</command>, Mercurial <emphasis>doesn't</emphasis>
577 recompress the stream, because <command>ssh</command> can already do this
578 itself.)
579 </para>
581 </sect3>
582 </sect2>
583 <sect2>
584 <title>Read/write ordering and atomicity</title>
586 <para>Appending to files isn't the whole story when it comes to guaranteeing
587 that a reader won't see a partial write. If you recall
588 figure <xref linkend="fig:concepts:metadata"/>, revisions in the changelog point to
589 revisions in the manifest, and revisions in the manifest point to
590 revisions in filelogs. This hierarchy is deliberate.
591 </para>
593 <para>A writer starts a transaction by writing filelog and manifest data,
594 and doesn't write any changelog data until those are finished. A
595 reader starts by reading changelog data, then manifest data, followed
596 by filelog data.
597 </para>
599 <para>Since the writer has always finished writing filelog and manifest data
600 before it writes to the changelog, a reader will never read a pointer
601 to a partially written manifest revision from the changelog, and it will
602 never read a pointer to a partially written filelog revision from the
603 manifest.
604 </para>
606 </sect2>
607 <sect2>
608 <title>Concurrent access</title>
610 <para>The read/write ordering and atomicity guarantees mean that Mercurial
611 never needs to <emphasis>lock</emphasis> a repository when it's reading data, even
612 if the repository is being written to while the read is occurring.
613 This has a big effect on scalability; you can have an arbitrary number
614 of Mercurial processes safely reading data from a repository safely
615 all at once, no matter whether it's being written to or not.
616 </para>
618 <para>The lockless nature of reading means that if you're sharing a
619 repository on a multi-user system, you don't need to grant other local
620 users permission to <emphasis>write</emphasis> to your repository in order for them
621 to be able to clone it or pull changes from it; they only need
622 <emphasis>read</emphasis> permission. (This is <emphasis>not</emphasis> a common feature among
623 revision control systems, so don't take it for granted! Most require
624 readers to be able to lock a repository to access it safely, and this
625 requires write permission on at least one directory, which of course
626 makes for all kinds of nasty and annoying security and administrative
627 problems.)
628 </para>
630 <para>Mercurial uses locks to ensure that only one process can write to a
631 repository at a time (the locking mechanism is safe even over
632 filesystems that are notoriously hostile to locking, such as NFS). If
633 a repository is locked, a writer will wait for a while to retry if the
634 repository becomes unlocked, but if the repository remains locked for
635 too long, the process attempting to write will time out after a while.
636 This means that your daily automated scripts won't get stuck forever
637 and pile up if a system crashes unnoticed, for example. (Yes, the
638 timeout is configurable, from zero to infinity.)
639 </para>
641 <sect3>
642 <title>Safe dirstate access</title>
644 <para>As with revision data, Mercurial doesn't take a lock to read the
645 dirstate file; it does acquire a lock to write it. To avoid the
646 possibility of reading a partially written copy of the dirstate file,
647 Mercurial writes to a file with a unique name in the same directory as
648 the dirstate file, then renames the temporary file atomically to
649 <filename>dirstate</filename>. The file named <filename>dirstate</filename> is thus
650 guaranteed to be complete, not partially written.
651 </para>
653 </sect3>
654 </sect2>
655 <sect2>
656 <title>Avoiding seeks</title>
658 <para>Critical to Mercurial's performance is the avoidance of seeks of the
659 disk head, since any seek is far more expensive than even a
660 comparatively large read operation.
661 </para>
663 <para>This is why, for example, the dirstate is stored in a single file. If
664 there were a dirstate file per directory that Mercurial tracked, the
665 disk would seek once per directory. Instead, Mercurial reads the
666 entire single dirstate file in one step.
667 </para>
669 <para>Mercurial also uses a <quote>copy on write</quote> scheme when cloning a
670 repository on local storage. Instead of copying every revlog file
671 from the old repository into the new repository, it makes a <quote>hard
672 link</quote>, which is a shorthand way to say <quote>these two names point to the
673 same file</quote>. When Mercurial is about to write to one of a revlog's
674 files, it checks to see if the number of names pointing at the file is
675 greater than one. If it is, more than one repository is using the
676 file, so Mercurial makes a new copy of the file that is private to
677 this repository.
678 </para>
680 <para>A few revision control developers have pointed out that this idea of
681 making a complete private copy of a file is not very efficient in its
682 use of storage. While this is true, storage is cheap, and this method
683 gives the highest performance while deferring most book-keeping to the
684 operating system. An alternative scheme would most likely reduce
685 performance and increase the complexity of the software, each of which
686 is much more important to the <quote>feel</quote> of day-to-day use.
687 </para>
689 </sect2>
690 <sect2>
691 <title>Other contents of the dirstate</title>
693 <para>Because Mercurial doesn't force you to tell it when you're modifying a
694 file, it uses the dirstate to store some extra information so it can
695 determine efficiently whether you have modified a file. For each file
696 in the working directory, it stores the time that it last modified the
697 file itself, and the size of the file at that time.
698 </para>
700 <para>When you explicitly <command role="hg-cmd">hg add</command>, <command role="hg-cmd">hg remove</command>, <command role="hg-cmd">hg rename</command> or
701 <command role="hg-cmd">hg copy</command> files, Mercurial updates the dirstate so that it knows
702 what to do with those files when you commit.
703 </para>
705 <para>When Mercurial is checking the states of files in the working
706 directory, it first checks a file's modification time. If that has
707 not changed, the file must not have been modified. If the file's size
708 has changed, the file must have been modified. If the modification
709 time has changed, but the size has not, only then does Mercurial need
710 to read the actual contents of the file to see if they've changed.
711 Storing these few extra pieces of information dramatically reduces the
712 amount of data that Mercurial needs to read, which yields large
713 performance improvements compared to other revision control systems.
714 </para>
716 </sect2>
717 </sect1>
718 </chapter>
720 <!--
721 local variables:
722 sgml-parent-document: ("00book.xml" "book" "chapter")
723 end:
724 -->