1.1 --- a/fr/ch04-concepts.xml	Fri Sep 11 14:35:36 2009 +0200
     1.2 +++ b/fr/ch04-concepts.xml	Mon Sep 14 01:18:56 2009 +0200
     1.3 @@ -61,705 +61,710 @@
     1.4          <emphasis>manifest</emphasis> pour rassembler les informations sur
     1.5          les fichiers dont il gère le suivi. Chaque entrée dans ce manifest
     1.6          contient des informations sur les fichiers présents dans une révision
     1.7 -        donnée. Une entrée store la liste des fichiers faisant partie de la
     1.8 +        donnée. Une entrée enregistre la liste des fichiers faisant partie de la
     1.9          révision, la version de chaque fichier, et quelques autres
    1.10          métadonnées sur ces fichiers.</para>
    1.11  
    1.12      </sect2>
    1.13      <sect2>
    1.14 -      <title>Recording changeset information</title>
    1.15 -
    1.16 -      <para id="x_2ef">The <emphasis>changelog</emphasis> contains
    1.17 -        information about each changeset.  Each revision records who
    1.18 -        committed a change, the changeset comment, other pieces of
    1.19 -        changeset-related information, and the revision of the manifest to
    1.20 -        use.</para>
    1.21 -
    1.22 -    </sect2>
    1.23 -    <sect2>
    1.24 -      <title>Relationships between revisions</title>
    1.25 -
    1.26 -      <para id="x_2f0">Within a changelog, a manifest, or a filelog, each
    1.27 -	revision stores a pointer to its immediate parent (or to its
    1.28 -	two parents, if it's a merge revision).  As I mentioned above,
    1.29 -	there are also relationships between revisions
    1.30 -	<emphasis>across</emphasis> these structures, and they are
    1.31 -	hierarchical in nature.</para>
    1.32 -
    1.33 -      <para id="x_2f1">For every changeset in a repository, there is exactly one
    1.34 -	revision stored in the changelog.  Each revision of the
    1.35 -	changelog contains a pointer to a single revision of the
    1.36 -	manifest.  A revision of the manifest stores a pointer to a
    1.37 -	single revision of each filelog tracked when that changeset
    1.38 -	was created.  These relationships are illustrated in
    1.39 -	<xref linkend="fig:concepts:metadata"/>.</para>
    1.40 +      <title>Enregistrer les informations des changeset</title>
    1.41 +
    1.42 +      <para id="x_2ef">Le <emphasis>changelog</emphasis> contient les
    1.43 +        informations sur chaque changeset. Chaque révision enregistre qui a
    1.44 +        committé un changement, le commentaire du changeset, d'autres
    1.45 +        morceaux d'information relatives au changeset et la révision du
    1.46 +        manifest à utiliser.</para>
    1.47 +
    1.48 +    </sect2>
    1.49 +    <sect2>
    1.50 +      <title>Relations entre les révisions</title>
    1.51 +
    1.52 +      <para id="x_2f0">A l'intérieur d'un changelog, d'un manifest, ou d'un
    1.53 +        filelog, chaque révision enregistre un pointeur vers son parent
    1.54 +        immédiat (ou à ses deux parents s'il s'agit d'une révision
    1.55 +        correspondant à une fusion (merge)). Comme mentionné plus haut, il y
    1.56 +        a aussi des relations entre les révisions <emphasis>à
    1.57 +          travers</emphasis> ces structures, qui sont de nature
    1.58 +        hiérarchique.</para>
    1.59 +
    1.60 +      <para id="x_2f1">Pour chaque changeset dans un dépôt, il y a exactement
    1.61 +        une révision stockée dans le changelog. Chaque révision du changelog
    1.62 +        contient un pointeur vers une unique révision du manifest. Une
    1.63 +        révision du manifeste garde un pointeur vers une unique révision pour
    1.64 +        chaque filelog suivi lorsque le changeset est créé. Ces relations
    1.65 +        sont illustrées dans <xref linkend="fig:concepts:metadata"/>.</para>
    1.66  
    1.67        <figure id="fig:concepts:metadata">
    1.68 -	<title>Metadata relationships</title>
    1.69 -	<mediaobject>
    1.70 -	  <imageobject><imagedata fileref="figs/metadata.png"/></imageobject>
    1.71 -	  <textobject><phrase>XXX add text</phrase></textobject>
    1.72 -	</mediaobject>
    1.73 +        <title>Metadata relationships</title>
    1.74 +        <mediaobject> <imageobject><imagedata
    1.75 +              fileref="figs/metadata.png"/></imageobject>
    1.76 +          <textobject><phrase>XXX add text</phrase></textobject> 
    1.77 +        </mediaobject>
    1.78        </figure>
    1.79  
    1.80 -      <para id="x_2f3">As the illustration shows, there is
    1.81 -	<emphasis>not</emphasis> a <quote>one to one</quote>
    1.82 -	relationship between revisions in the changelog, manifest, or
    1.83 -	filelog. If a file that
    1.84 -	Mercurial tracks hasn't changed between two changesets, the
    1.85 -	entry for that file in the two revisions of the manifest will
    1.86 -	point to the same revision of its filelog<footnote>
    1.87 -	  <para id="x_725">It is possible (though unusual) for the manifest to
    1.88 -	    remain the same between two changesets, in which case the
    1.89 -	    changelog entries for those changesets will point to the
    1.90 -	    same revision of the manifest.</para>
    1.91 -	</footnote>.</para>
    1.92 +      <para id="x_2f3">Comme l'illustration le monde, il
    1.93 +        <emphasis>n'</emphasis>y a <emphasis>pas</emphasis> de relation
    1.94 +        <quote>un à un</quote> entre les révisions dans un changelog,
    1.95 +        manifest ou filelog. Si un fichier que Mercurial suit n'a pas changé
    1.96 +        entre deux changesets, l'entrée pour ce fichier dans les deux
    1.97 +        révisions du manifest pointera vers la même révision de son filelog
    1.98 +        <footnote> <para id="x_725">Il est possible (bien qu'inhabituel)
    1.99 +            qu'un manifest reste le même entre deux changesets, auquel cas
   1.100 +            l'entrée du changelog pour ces changesets pointera vers la même
   1.101 +            révision du manifest.</para>
   1.102 +        </footnote>.</para>
   1.103  
   1.104      </sect2>
   1.105    </sect1>
   1.106    <sect1>
   1.107 -    <title>Safe, efficient storage</title>
   1.108 -
   1.109 -    <para id="x_2f4">The underpinnings of changelogs, manifests, and filelogs are
   1.110 -      provided by a single structure called the
   1.111 +    <title>Stockage sûr et efficace</title>
   1.112 +
   1.113 +    <para id="x_2f4">Les fondements des changelogs, des manifests et des
   1.114 +      filelogs sont fournis par une unique structure appelée le
   1.115        <emphasis>revlog</emphasis>.</para>
   1.116  
   1.117      <sect2>
   1.118 -      <title>Efficient storage</title>
   1.119 -
   1.120 -      <para id="x_2f5">The revlog provides efficient storage of revisions using a
   1.121 -	<emphasis>delta</emphasis> mechanism.  Instead of storing a
   1.122 -	complete copy of a file for each revision, it stores the
   1.123 -	changes needed to transform an older revision into the new
   1.124 -	revision.  For many kinds of file data, these deltas are
   1.125 -	typically a fraction of a percent of the size of a full copy
   1.126 -	of a file.</para>
   1.127 -
   1.128 -      <para id="x_2f6">Some obsolete revision control systems can only work with
   1.129 -	deltas of text files.  They must either store binary files as
   1.130 -	complete snapshots or encoded into a text representation, both
   1.131 -	of which are wasteful approaches.  Mercurial can efficiently
   1.132 -	handle deltas of files with arbitrary binary contents; it
   1.133 -	doesn't need to treat text as special.</para>
   1.134 +      <title>stockage efficace</title>
   1.135 +
   1.136 +      <para id="x_2f5">Le revlog fournit un stockage efficace des révision en
   1.137 +        utilisant un mécanisme <emphasis>delta</emphasis>. A lieu de stocker
   1.138 +        une copie complète d'un fichier à chaque révision, il stocke les
   1.139 +        changements requis pour transformer une révision plus ancienne en la
   1.140 +        nouvelle révision. Pour plusieurs type de données, ces deltas sont
   1.141 +        typiquement une fraction de pourcentage de la taille de la copie
   1.142 +        complète d'un fichier.</para>
   1.143 +
   1.144 +      <para id="x_2f6">Certains systèmes de gestion de révisions obselètes
   1.145 +        peuvent seulement travailler avec les deltas de fichiers texte. Il
   1.146 +        doivent d'ailleurs stocker les fichiers binaires comme des images
   1.147 +        complètes ou encodées avec une représentation texte, chacune de ces
   1.148 +        approches étant gaspilleuse. Mercurial peut traiter les deltas de
   1.149 +        fichiers avec du contenu binaire arbitraire ; il n'a pas besoin de
   1.150 +        traiter spécialement du texte.</para>
   1.151  
   1.152      </sect2>
   1.153      <sect2 id="sec:concepts:txn">
   1.154 -      <title>Safe operation</title>
   1.155 -
   1.156 -      <para id="x_2f7">Mercurial only ever <emphasis>appends</emphasis> data to
   1.157 -	the end of a revlog file. It never modifies a section of a
   1.158 -	file after it has written it.  This is both more robust and
   1.159 -	efficient than schemes that need to modify or rewrite
   1.160 -	data.</para>
   1.161 -
   1.162 -      <para id="x_2f8">In addition, Mercurial treats every write as part of a
   1.163 -	<emphasis>transaction</emphasis> that can span a number of
   1.164 -	files.  A transaction is <emphasis>atomic</emphasis>: either
   1.165 -	the entire transaction succeeds and its effects are all
   1.166 -	visible to readers in one go, or the whole thing is undone.
   1.167 -	This guarantee of atomicity means that if you're running two
   1.168 -	copies of Mercurial, where one is reading data and one is
   1.169 -	writing it, the reader will never see a partially written
   1.170 -	result that might confuse it.</para>
   1.171 -
   1.172 -      <para id="x_2f9">The fact that Mercurial only appends to files makes it
   1.173 -	easier to provide this transactional guarantee.  The easier it
   1.174 -	is to do stuff like this, the more confident you should be
   1.175 -	that it's done correctly.</para>
   1.176 -
   1.177 -    </sect2>
   1.178 -    <sect2>
   1.179 -      <title>Fast retrieval</title>
   1.180 -
   1.181 -      <para id="x_2fa">Mercurial cleverly avoids a pitfall common to
   1.182 -	all earlier revision control systems: the problem of
   1.183 -	<emphasis>inefficient retrieval</emphasis>. Most revision
   1.184 -	control systems store the contents of a revision as an
   1.185 -	incremental series of modifications against a
   1.186 -	<quote>snapshot</quote>.  (Some base the snapshot on the
   1.187 -	oldest revision, others on the newest.)  To reconstruct a
   1.188 -	specific revision, you must first read the snapshot, and then
   1.189 -	every one of the revisions between the snapshot and your
   1.190 -	target revision.  The more history that a file accumulates,
   1.191 -	the more revisions you must read, hence the longer it takes to
   1.192 -	reconstruct a particular revision.</para>
   1.193 +      <title>Opérations sûres</title>
   1.194 +
   1.195 +      <para id="x_2f7">Mercurial <emphasis>empile</emphasis> toujours les
   1.196 +        données à la fin d'un fichier revlog. Il ne modifie jamais la section
   1.197 +        d'un fichier après qu'il l'ait écrite. C'est à la foit plus robuste
   1.198 +        et efficace que les schémas qui ont besoin de modifier ou réécrire
   1.199 +        les données.</para>
   1.200 +
   1.201 +      <para id="x_2f8">De plus, Mercurial traite chaque écriture comme une
   1.202 +        partie d'une <emphasis>transaction</emphasis> qui peut comprendre
   1.203 +        plusieurs fichiers. Une transaction est <emphasis>atomique</emphasis>
   1.204 +        : spot la transaction entière réussit et ses effets sont tous
   1.205 +        visibles aux lecteurs en une étape, soit la totalité est annulée.
   1.206 +        Cette garantie de l'atomicité signifie que si vous exécutez deux
   1.207 +        copies de Mercurial, où une lit les données et l'autre les écrit, le
   1.208 +        lecteur ne verra jamais un résultat partiellement écrit qui pourrait
   1.209 +        le perturber.</para>
   1.210 +
   1.211 +      <para id="x_2f9">Le fait que Mercurial ne fasse qu'ajouter aux fichiers
   1.212 +        fait qu'il est facile de fournir cette garantie de transaction. Plus
   1.213 +        les choses sont faites simplement comme ça, plus vous pouvez être
   1.214 +        rassurés qu'elles sont bien faites.</para>
   1.215 +    
   1.216 +    </sect2>
   1.217 +    <sect2>
   1.218 +      <title>Récupération rapide</title>
   1.219 +
   1.220 +      <para id="x_2fa">Mercurial évite habillement un piège commun à tous les
   1.221 +        vieux systèmes de gestion de révisions : le problème de la
   1.222 +        <emphasis>récupération inefficace</emphasis> La plupart des systèmes
   1.223 +        de gestion de révisions stockent le contenu d'une révision comme une
   1.224 +        série incrémentale de modifications faites à un
   1.225 +        <quote>snapshot</quote>. (Certains basent le snapshot sur la plus
   1.226 +        vieille révision, d'autres sur la plus récente.) Pour reconstruire
   1.227 +        une révision spécifique, vous devez d'abord lire le snapshot, et
   1.228 +        ensuite toutes les révisions entre le snapshot et votre révision
   1.229 +        cible. Plus vous avez d'historique accumulé dans un fichier, plus de
   1.230 +        révisions vous avez à lire, d'où la longueur que cela prend à
   1.231 +        reconstruire une révision particulière.</para>
   1.232  
   1.233        <figure id="fig:concepts:snapshot">
   1.234 -	<title>Snapshot of a revlog, with incremental deltas</title>
   1.235 -	<mediaobject>
   1.236 -	  <imageobject><imagedata fileref="figs/snapshot.png"/></imageobject>
   1.237 -	  <textobject><phrase>XXX add text</phrase></textobject>
   1.238 -	</mediaobject>
   1.239 +        <title>Snapshot d'un revlog, avec des deltas incrémentaux</title>
   1.240 +        <mediaobject> <imageobject><imagedata
   1.241 +              fileref="figs/snapshot.png"/></imageobject>
   1.242 +          <textobject><phrase>XXX add text</phrase></textobject>
   1.243 +        </mediaobject>
   1.244        </figure>
   1.245  
   1.246 -      <para id="x_2fc">The innovation that Mercurial applies to this problem is
   1.247 -	simple but effective.  Once the cumulative amount of delta
   1.248 -	information stored since the last snapshot exceeds a fixed
   1.249 -	threshold, it stores a new snapshot (compressed, of course),
   1.250 -	instead of another delta.  This makes it possible to
   1.251 -	reconstruct <emphasis>any</emphasis> revision of a file
   1.252 -	quickly.  This approach works so well that it has since been
   1.253 -	copied by several other revision control systems.</para>
   1.254 -
   1.255 -      <para id="x_2fd"><xref linkend="fig:concepts:snapshot"/> illustrates
   1.256 -	the idea.  In an entry in a revlog's index file, Mercurial
   1.257 -	stores the range of entries from the data file that it must
   1.258 -	read to reconstruct a particular revision.</para>
   1.259 +      <para id="x_2fc">L'inovation que Mercurial apporte à ce problème est
   1.260 +        simple mais effective. Une fois que la quantité cumulée de deltas
   1.261 +        d'informations stockées depuis le dernier snapshot excède un seuil
   1.262 +        fixé, il stock un nouveau snapshot (compréssé biensûr), plutôt qu'un
   1.263 +        nouveau delta. Ceci rend possible la reconstruction de
   1.264 +        <emphasis>toute</emphasis> révision d'un fichier rapidement. Cette
   1.265 +        approche fonctionne si bien que depuis, elle a été copiée par
   1.266 +        plusieurs autres systèmes de gestion de révisions.</para>
   1.267 +
   1.268 +      <para id="x_2fd"><xref linkend="fig:concepts:snapshot"/> illustre
   1.269 +        l'idée. Dans une entrée d'un fichier d'index de revlog, Mercurial
   1.270 +        stock l'intervale des entrées depuis le fichier de données qu'il doit
   1.271 +        lire pour reconstruire une révision particulière.</para>
   1.272  
   1.273        <sect3>
   1.274 -	<title>Aside: the influence of video compression</title>
   1.275 -
   1.276 -	<para id="x_2fe">If you're familiar with video compression or
   1.277 -	  have ever watched a TV feed through a digital cable or
   1.278 -	  satellite service, you may know that most video compression
   1.279 -	  schemes store each frame of video as a delta against its
   1.280 -	  predecessor frame.</para>
   1.281 -
   1.282 -	<para id="x_2ff">Mercurial borrows this idea to make it
   1.283 -	  possible to reconstruct a revision from a snapshot and a
   1.284 -	  small number of deltas.</para>
   1.285 +        <title>En amont : l'influence de la compression vidéo</title>
   1.286 +      
   1.287 +        <para id="x_2fe">Si vous êtes familiés de la compression vidéo ou
   1.288 +          avez déjà regardé un programme TV par cable ou par un service
   1.289 +          satellite, vous devez savoir que la plupart des schémas de
   1.290 +          compression vidéo stockent chaque frame de vidéo comme un delta vis
   1.291 +          à vis de la frame précédente.</para>
   1.292 +      
   1.293 +        <para id="x_2ff">Mercurial emprunte cette idée pour rendre possible
   1.294 +          la reconstruction d'une révision à partir d'un snapshot et d'un
   1.295 +          petit nombre de deltas.</para>
   1.296  
   1.297        </sect3>
   1.298      </sect2>
   1.299      <sect2>
   1.300 -      <title>Identification and strong integrity</title>
   1.301 -
   1.302 -      <para id="x_300">Along with delta or snapshot information, a revlog entry
   1.303 -	contains a cryptographic hash of the data that it represents.
   1.304 -	This makes it difficult to forge the contents of a revision,
   1.305 -	and easy to detect accidental corruption.</para>
   1.306 -
   1.307 -      <para id="x_301">Hashes provide more than a mere check against corruption;
   1.308 -	they are used as the identifiers for revisions.  The changeset
   1.309 -	identification hashes that you see as an end user are from
   1.310 -	revisions of the changelog.  Although filelogs and the
   1.311 -	manifest also use hashes, Mercurial only uses these behind the
   1.312 -	scenes.</para>
   1.313 -
   1.314 -      <para id="x_302">Mercurial verifies that hashes are correct when it
   1.315 -	retrieves file revisions and when it pulls changes from
   1.316 -	another repository.  If it encounters an integrity problem, it
   1.317 -	will complain and stop whatever it's doing.</para>
   1.318 -
   1.319 -      <para id="x_303">In addition to the effect it has on retrieval efficiency,
   1.320 -	Mercurial's use of periodic snapshots makes it more robust
   1.321 -	against partial data corruption.  If a revlog becomes partly
   1.322 -	corrupted due to a hardware error or system bug, it's often
   1.323 -	possible to reconstruct some or most revisions from the
   1.324 -	uncorrupted sections of the revlog, both before and after the
   1.325 -	corrupted section.  This would not be possible with a
   1.326 -	delta-only storage model.</para>
   1.327 +      <title>Identification et intégrité forte</title>
   1.328 +
   1.329 +      <para id="x_300">Avec les deltas ou l'information du snapshot, une
   1.330 +        entrée d'un revlog contient un hash cryptographique des données qu'il
   1.331 +        représente. Ceci fait qu'il est difficile de construire les données
   1.332 +        d'une révision, mais facile de détecter une corruption
   1.333 +        accidentelle.</para>
   1.334 +
   1.335 +      <para id="x_301">Les hash fournissent plus qu'un bon moyen de
   1.336 +        vérification contre la corruption ; il sont aussi utilisés comme
   1.337 +        identifiants pour les révisions. Le hash d'identification d'un
   1.338 +        changeset que vous voyez comme utilisateur final proviennent des
   1.339 +        révisions du changelog. Bien que les filelogs et le manifest
   1.340 +        utilisent aussi des hash, Mercurial ne les utilise qu'en arrière
   1.341 +        plan.</para>
   1.342 +
   1.343 +      <para id="x_302">Mercurial vérifie que les hash sont corrects lorsqu'il
   1.344 +        récupère les révisions de fichiers et lorsqu'il récupère (pull) les
   1.345 +        changements d'un autre dépôt. S'il rencontre un problème d'intégrité,
   1.346 +        il se pleindra et arrêtera tout ce qu'il est en train de faire.</para>
   1.347 +
   1.348 +      <para id="x_303">En plus de l'effet qu'il a sur l'efficacité des
   1.349 +        récupérations, l'utilisation de Mercurial de snapshots périodiques
   1.350 +        fait qu'il est plus robuste contre la corruption partielle de
   1.351 +        données. Si un revlog devient partiellement corrompu à cause d'une
   1.352 +        erreur matérielle ou d'un bug système, il est souvent possible de
   1.353 +        reconstruire certaines ou la plupart des révisions à partir des
   1.354 +        sections non corrompues du revlog, avant et après la section
   1.355 +        corrompue. Ceci ne serait pas possible à partir d'un modèle de
   1.356 +        stockage delta seul.</para>
   1.357      </sect2>
   1.358    </sect1>
   1.359  
   1.360    <sect1>
   1.361 -    <title>Revision history, branching, and merging</title>
   1.362 -
   1.363 -    <para id="x_304">Every entry in a Mercurial revlog knows the identity of its
   1.364 -      immediate ancestor revision, usually referred to as its
   1.365 -      <emphasis>parent</emphasis>.  In fact, a revision contains room
   1.366 -      for not one parent, but two.  Mercurial uses a special hash,
   1.367 -      called the <quote>null ID</quote>, to represent the idea
   1.368 -      <quote>there is no parent here</quote>.  This hash is simply a
   1.369 -      string of zeroes.</para>
   1.370 -
   1.371 -    <para id="x_305">In <xref linkend="fig:concepts:revlog"/>, you can see
   1.372 -      an example of the conceptual structure of a revlog.  Filelogs,
   1.373 -      manifests, and changelogs all have this same structure; they
   1.374 -      differ only in the kind of data stored in each delta or
   1.375 +    <title>Historique des révisions, branches et fusions (merge)</title>
   1.376 +
   1.377 +    <para id="x_304">Chaque entrée dans un revlog Mercurial connaît
   1.378 +      l'identité de l'ancètre immédiat de la révision, habituellement référé
   1.379 +      comme son <emphasis>parent</emphasis>. En fait, une révision contient
   1.380 +      de la place pour non pas un parent, mais deux. Mercurial utilise un
   1.381 +      hash spécial, appelé le <quote>null ID</quote> pour représenter l'idée
   1.382 +      qu'<quote>il n'y a pas de parent ici</quote>. Ce hash est simplement
   1.383 +      une chaîne de zéros.</para>
   1.384 +
   1.385 +    <para id="x_305">Dans <xref linkend="fig:concepts:revlog"/>, vous pouvez
   1.386 +      voir un exemple de la structure conceptuelle d'un revlog. Les filelogs,
   1.387 +      manifests et changelogs ont tous cette même structure ; ils difèrent
   1.388 +      simplement dans le type de donnée stockée dans chaque delta ou
   1.389        snapshot.</para>
   1.390  
   1.391 -    <para id="x_306">The first revision in a revlog (at the bottom of the image)
   1.392 -      has the null ID in both of its parent slots.  For a
   1.393 -      <quote>normal</quote> revision, its first parent slot contains
   1.394 -      the ID of its parent revision, and its second contains the null
   1.395 -      ID, indicating that the revision has only one real parent.  Any
   1.396 -      two revisions that have the same parent ID are branches.  A
   1.397 -      revision that represents a merge between branches has two normal
   1.398 -      revision IDs in its parent slots.</para>
   1.399 +    <para id="x_306">La première révision d'un revlog (au bas de l'image) a
   1.400 +      le null ID dans chacune de ses cases parent. Pour une révision
   1.401 +      <quote>normale</quote>, sa première case parent contient l'ID de sa
   1.402 +      révision parent et la seconde contient le null ID, indiquant que cette
   1.403 +      révision n'a qu'un seul vrai parent. Si deux révisions ont le même
   1.404 +      parent, il s'agit de branches. Une révision qui représente une fusion
   1.405 +      (merge) entre deux branches a deux identifiants de révision normaux
   1.406 +      dans ses cases parents.</para>
   1.407  
   1.408      <figure id="fig:concepts:revlog">
   1.409        <title>The conceptual structure of a revlog</title>
   1.410 -      <mediaobject>
   1.411 -	<imageobject><imagedata fileref="figs/revlog.png"/></imageobject>
   1.412 -	<textobject><phrase>XXX add text</phrase></textobject>
   1.413 +      <mediaobject> <imageobject><imagedata
   1.414 +            fileref="figs/revlog.png"/></imageobject> <textobject><phrase>XXX
   1.415 +            add text</phrase></textobject>
   1.416        </mediaobject>
   1.417      </figure>
   1.418  
   1.419    </sect1>
   1.420    <sect1>
   1.421 -    <title>The working directory</title>
   1.422 -
   1.423 -    <para id="x_307">In the working directory, Mercurial stores a snapshot of the
   1.424 -      files from the repository as of a particular changeset.</para>
   1.425 -
   1.426 -    <para id="x_308">The working directory <quote>knows</quote> which changeset
   1.427 -      it contains.  When you update the working directory to contain a
   1.428 -      particular changeset, Mercurial looks up the appropriate
   1.429 -      revision of the manifest to find out which files it was tracking
   1.430 -      at the time that changeset was committed, and which revision of
   1.431 -      each file was then current.  It then recreates a copy of each of
   1.432 -      those files, with the same contents it had when the changeset
   1.433 -      was committed.</para>
   1.434 -
   1.435 -    <para id="x_309">The <emphasis>dirstate</emphasis> is a special
   1.436 -      structure that contains Mercurial's knowledge of the working
   1.437 -      directory.  It is maintained as a file named
   1.438 -      <filename>.hg/dirstate</filename> inside a repository.  The
   1.439 -      dirstate details which changeset the working directory is
   1.440 -      updated to, and all of the files that Mercurial is tracking in
   1.441 -      the working directory. It also lets Mercurial quickly notice
   1.442 -      changed files, by recording their checkout times and
   1.443 -      sizes.</para>
   1.444 -
   1.445 -    <para id="x_30a">Just as a revision of a revlog has room for two parents, so
   1.446 -      that it can represent either a normal revision (with one parent)
   1.447 -      or a merge of two earlier revisions, the dirstate has slots for
   1.448 -      two parents.  When you use the <command role="hg-cmd">hg
   1.449 -	update</command> command, the changeset that you update to is
   1.450 -      stored in the <quote>first parent</quote> slot, and the null ID
   1.451 -      in the second. When you <command role="hg-cmd">hg
   1.452 -	merge</command> with another changeset, the first parent
   1.453 -      remains unchanged, and the second parent is filled in with the
   1.454 -      changeset you're merging with.  The <command role="hg-cmd">hg
   1.455 -	parents</command> command tells you what the parents of the
   1.456 -      dirstate are.</para>
   1.457 -
   1.458 -    <sect2>
   1.459 -      <title>What happens when you commit</title>
   1.460 -
   1.461 -      <para id="x_30b">The dirstate stores parent information for more than just
   1.462 -	book-keeping purposes.  Mercurial uses the parents of the
   1.463 -	dirstate as <emphasis>the parents of a new
   1.464 -	  changeset</emphasis> when you perform a commit.</para>
   1.465 -
   1.466 -      <figure id="fig:concepts:wdir">
   1.467 -	<title>The working directory can have two parents</title>
   1.468 -	<mediaobject>
   1.469 -	  <imageobject><imagedata fileref="figs/wdir.png"/></imageobject>
   1.470 -	  <textobject><phrase>XXX add text</phrase></textobject>
   1.471 -	</mediaobject>
   1.472 +    <title>Le répertoire de travail</title>
   1.473 +
   1.474 +    <para id="x_307">Dans un répertoire de travail, Mercurial stock une image
   1.475 +      des fichiers du dépôt à un changeset particulier.</para>
   1.476 +
   1.477 +    <para id="x_308">Le répertoire de travail <quote>sait</quote> quel
   1.478 +      changeset il contient. Lorsque vous mettez à jour (update) le
   1.479 +      répertoire de travail à un certain changeset, Mercurial regarde la
   1.480 +      révision appropriée du manifest pour trouver quels fichier il suivait
   1.481 +      au moment où le changeset a été committé, et quelle révision de chaque
   1.482 +      fichier était alors courante. Il recrée ensuite une copie de chacun de
   1.483 +      ces fichiers, avec le même contenu qu'ils avaient lorsque le changeset
   1.484 +      a été committé.</para>
   1.485 +
   1.486 +    <para id="x_309">La structure spéciale <emphasis>dirstate</emphasis>
   1.487 +      contient la connaissance de Mercurial sur le répertoire de travail.
   1.488 +      Elle est maintenue par un fichier appelé
   1.489 +      <filename>.hg/dirstate</filename> dans un dépôt. Les détails du
   1.490 +      dirstate sont le changeset vers lequel le répertoire de travail se met
   1.491 +      à jour (update), et tous les fichiers que Mercurial suit dans le
   1.492 +      répertoire de travail. Il permet aussi à Mercurial se connaître
   1.493 +      rapidement les fichiers modifiés, en enregistrant leurs heures de
   1.494 +      dernière modification et leur taille.</para>
   1.495 +
   1.496 +    <para id="x_30a">Puisqu'une révision de revlog a des emplacements pour
   1.497 +      deux parents et peut représenter aussi bien une révision normale (avec
   1.498 +      un parent) ou une fusion de deux révisions anciennes, le dirstate a des
   1.499 +      emplacements pour deux parents. Lorsque vous utilisez la commande
   1.500 +      <command role="hg-cmd">hg update</command>, le changeset que vous
   1.501 +      mettez à jour est stocké dans l'emplacement du <quote>premier
   1.502 +        parent</quote>, et le null ID l'est dans le second. Lorsque vous
   1.503 +      utilisez la commande <command role="hg-cmd">hg merge</command> avec un
   1.504 +      autre changeset, le premier parent reste inchangé, et le second est
   1.505 +      rempli avec le changeset à partir duquel vous êtes en train de
   1.506 +      fusionner. La commande <command role="hg-cmd">hg parents</command> vous
   1.507 +      donne les parents du dirstate.</para>
   1.508 +
   1.509 +    <sect2>
   1.510 +      <title>Que se passe-t-il lorsque vous committez</title>
   1.511 +
   1.512 +      <para id="x_30b">Le dirstate stock les informations sur les parents
   1.513 +        pour plusqu'un simple livre de stockage. Mercurial utilise les
   1.514 +        parents du distate comme <emphasis>les parents d'un nouveau
   1.515 +          changeset</emphasis> lorsque vous committez.</para>
   1.516 +
   1.517 +      <figure id="fig:concepts:wdir"> 
   1.518 +        <title>Le répertoire de travail peut avoir deux parents</title>
   1.519 +        <mediaobject>
   1.520 +          <imageobject><imagedata fileref="figs/wdir.png"/></imageobject>
   1.521 +          <textobject><phrase>XXX add text</phrase></textobject></mediaobject>
   1.522        </figure>
   1.523  
   1.524 -      <para id="x_30d"><xref linkend="fig:concepts:wdir"/> shows the
   1.525 -	normal state of the working directory, where it has a single
   1.526 -	changeset as parent.  That changeset is the
   1.527 -	<emphasis>tip</emphasis>, the newest changeset in the
   1.528 -	repository that has no children.</para>
   1.529 +      <para id="x_30d"><xref linkend="fig:concepts:wdir"/> montre l'état
   1.530 +        normal d'un répertoire de travail, où il n'y a qu'un seul changeset
   1.531 +        comme parent. Ce changeset est le <emphasis>tip</emphasis>, le
   1.532 +        changeset le plus récent dans le dépôt n'a pas d'enfant.</para>
   1.533  
   1.534        <figure id="fig:concepts:wdir-after-commit">
   1.535 -	<title>The working directory gains new parents after a
   1.536 -	  commit</title>
   1.537 -	<mediaobject>
   1.538 -	  <imageobject><imagedata fileref="figs/wdir-after-commit.png"/></imageobject>
   1.539 -	  <textobject><phrase>XXX add text</phrase></textobject>
   1.540 -	</mediaobject>
   1.541 +        <title>Le répertoire de travail gagne de nouveaux parents après un
   1.542 +        commit</title>
   1.543 +        <mediaobject>
   1.544 +          <imageobject><imagedata
   1.545 +              fileref="figs/wdir-after-commit.png"/></imageobject>
   1.546 +          <textobject><phrase>XXX add text</phrase></textobject>
   1.547 +        </mediaobject>
   1.548        </figure>
   1.549  
   1.550 -      <para id="x_30f">It's useful to think of the working directory as
   1.551 -	<quote>the changeset I'm about to commit</quote>.  Any files
   1.552 -	that you tell Mercurial that you've added, removed, renamed,
   1.553 -	or copied will be reflected in that changeset, as will
   1.554 -	modifications to any files that Mercurial is already tracking;
   1.555 -	the new changeset will have the parents of the working
   1.556 -	directory as its parents.</para>
   1.557 -
   1.558 -      <para id="x_310">After a commit, Mercurial will update the
   1.559 -	parents of the working directory, so that the first parent is
   1.560 -	the ID of the new changeset, and the second is the null ID.
   1.561 -	This is shown in <xref
   1.562 -	  linkend="fig:concepts:wdir-after-commit"/>. Mercurial
   1.563 -	doesn't touch any of the files in the working directory when
   1.564 -	you commit; it just modifies the dirstate to note its new
   1.565 -	parents.</para>
   1.566 -
   1.567 -    </sect2>
   1.568 -    <sect2>
   1.569 -      <title>Creating a new head</title>
   1.570 -
   1.571 -      <para id="x_311">It's perfectly normal to update the working directory to a
   1.572 -	changeset other than the current tip.  For example, you might
   1.573 -	want to know what your project looked like last Tuesday, or
   1.574 -	you could be looking through changesets to see which one
   1.575 -	introduced a bug.  In cases like this, the natural thing to do
   1.576 -	is update the working directory to the changeset you're
   1.577 -	interested in, and then examine the files in the working
   1.578 -	directory directly to see their contents as they were when you
   1.579 -	committed that changeset.  The effect of this is shown in
   1.580 -	<xref linkend="fig:concepts:wdir-pre-branch"/>.</para>
   1.581 +      <para id="x_30f">Il est utile de penser du répertoire de travail qu'il
   1.582 +        est <quote>le changeset que je vais committer</quote>. Chaque fichier
   1.583 +        que vous dites à mercurial d'ajouter, de supprimer, de renommer ou de
   1.584 +        copier va être reflété dasn ce changeset, tout comme les
   1.585 +        modifications de n'importe quel fichier que Mercurial est déjà en
   1.586 +        train de suite ; le nouveau changeset aura les mêmes parents que le
   1.587 +        répertoire de travail.</para>
   1.588 +
   1.589 +      <para id="x_310">Après un commit, Mercurial va mettre à jour les
   1.590 +        parents du répertoire de travail, ainsi, le premier parents est l'ID
   1.591 +        du nouveau changeset, et le second, le nullID. Ceci est illustré dans
   1.592 +        <xref linkend="fig:concepts:wdir-after-commit"/>. Mercurial ne touche
   1.593 +        à aucun des fichiers du répertoire de travail lorsque vous committez
   1.594 +        ; il modifie simplement le dirstate pour noter ses nouveaux
   1.595 +        parents.</para>
   1.596 +
   1.597 +    </sect2>
   1.598 +    <sect2>
   1.599 +      <title>Création d'une nouvelle <quote>head</quote></title>
   1.600 +
   1.601 +      <para id="x_311">Il est parfaitement normal de faire un update du
   1.602 +        répertoire de travail à un changeset autre que le tip courant. Par
   1.603 +        exemple, vous pourriez vouloir savoir ce à quoi votre projet
   1.604 +        ressemblait le dernier Mardi, ou regarder le changeset qui a
   1.605 +        introduit un bug. Dans des cas comme ça, la chose naturelle à faire
   1.606 +        est de faire un update du répertoire de travail au changeset qui vous
   1.607 +        intéresse, et ensuite d'en examiner les fichiers pour regarder leurs
   1.608 +        contenus comme ils l'étaient lorsque vous avez commité ce changeset.
   1.609 +        L'effet de ceci est montré dans <xref
   1.610 +          linkend="fig:concepts:wdir-pre-branch"/>.</para>
   1.611  
   1.612        <figure id="fig:concepts:wdir-pre-branch">
   1.613 -	<title>The working directory, updated to an older
   1.614 -	  changeset</title>
   1.615 -	<mediaobject>
   1.616 -	  <imageobject><imagedata fileref="figs/wdir-pre-branch.png"/></imageobject>
   1.617 -	  <textobject><phrase>XXX add text</phrase></textobject>
   1.618 -	</mediaobject>
   1.619 +        <title>Le répertoire de travail, "updaté" pour un changeset plus
   1.620 +        ancien</title>
   1.621 +        <mediaobject> <imageobject><imagedata
   1.622 +              fileref="figs/wdir-pre-branch.png"/></imageobject>
   1.623 +          <textobject><phrase>XXX add text</phrase></textobject>
   1.624 +        </mediaobject>
   1.625        </figure>
   1.626  
   1.627 -      <para id="x_313">Having updated the working directory to an
   1.628 -	older changeset, what happens if you make some changes, and
   1.629 -	then commit?  Mercurial behaves in the same way as I outlined
   1.630 -	above.  The parents of the working directory become the
   1.631 -	parents of the new changeset.  This new changeset has no
   1.632 -	children, so it becomes the new tip.  And the repository now
   1.633 -	contains two changesets that have no children; we call these
   1.634 -	<emphasis>heads</emphasis>.  You can see the structure that
   1.635 -	this creates in <xref
   1.636 -	  linkend="fig:concepts:wdir-branch"/>.</para>
   1.637 +      <para id="x_313">En ayant fait un update du répertoire de travail vers
   1.638 +        un changeset plus ancien, qu'est-ce qu'il se passe si vous faites des
   1.639 +        changements et ensuite committez ? Mercurial se comporte comme je
   1.640 +        l'ai fait remarqué plus haut. Les parents du répertoire de travail
   1.641 +        deviennent les parents du nouveau changeset. Ce nouveau changeset n'a
   1.642 +        pas d'enfant, donc il devient le nouveau tip. Le dépôt contient
   1.643 +        maintenant deux changesets qui n'ont pas d'enfant ; on appelle ceci
   1.644 +        des <emphasis>heads</emphasis>. Vous pouvez voir la structire que
   1.645 +        cela crée dans <xref linkend="fig:concepts:wdir-branch"/>.</para>
   1.646  
   1.647        <figure id="fig:concepts:wdir-branch">
   1.648 -	<title>After a commit made while synced to an older
   1.649 -	  changeset</title>
   1.650 -	<mediaobject>
   1.651 -	  <imageobject><imagedata fileref="figs/wdir-branch.png"/></imageobject>
   1.652 -	  <textobject><phrase>XXX add text</phrase></textobject>
   1.653 -	</mediaobject>
   1.654 +        <title>Après un commit fait pendant la synchronisation avec un ancien
   1.655 +        changeset</title>
   1.656 +        <mediaobject> <imageobject><imagedata
   1.657 +              fileref="figs/wdir-branch.png"/></imageobject>
   1.658 +          <textobject><phrase>XXX add text</phrase></textobject>
   1.659 +        </mediaobject>
   1.660        </figure>
   1.661  
   1.662        <note>
   1.663 -	<para id="x_315">If you're new to Mercurial, you should keep
   1.664 -	  in mind a common <quote>error</quote>, which is to use the
   1.665 -	  <command role="hg-cmd">hg pull</command> command without any
   1.666 -	  options.  By default, the <command role="hg-cmd">hg
   1.667 -	    pull</command> command <emphasis>does not</emphasis>
   1.668 -	  update the working directory, so you'll bring new changesets
   1.669 -	  into your repository, but the working directory will stay
   1.670 -	  synced at the same changeset as before the pull.  If you
   1.671 -	  make some changes and commit afterwards, you'll thus create
   1.672 -	  a new head, because your working directory isn't synced to
   1.673 -	  whatever the current tip is.  To combine the operation of a
   1.674 -	  pull, followed by an update, run <command>hg pull
   1.675 -	    -u</command>.</para>
   1.676 -
   1.677 -	<para id="x_316">I put the word <quote>error</quote> in quotes
   1.678 -	  because all that you need to do to rectify the situation
   1.679 -	  where you created a new head by accident is
   1.680 -	  <command role="hg-cmd">hg merge</command>, then <command
   1.681 -	    role="hg-cmd">hg commit</command>.  In other words, this
   1.682 -	  almost never has negative consequences; it's just something
   1.683 -	  of a surprise for newcomers.  I'll discuss other ways to
   1.684 -	  avoid this behavior, and why Mercurial behaves in this
   1.685 -	  initially surprising way, later on.</para>
   1.686 +        <para id="x_315">Si vous êtes nouveau à Mercurial, vous devez garder
   1.687 +          à l'esprit une <quote>erreur</quote> commune, qui est d'utiliser la
   1.688 +          commande <command role="hg-cmd">hg pull</command> sans aucune
   1.689 +          option. Par défaut, la commande <command role="hg-cmd">hg
   1.690 +            pull</command> <emphasis>ne fait pas</emphasis> d'update sur le
   1.691 +          répertoire de travail, ainsi, vous allez récupérer les nouveaux
   1.692 +          changesets dans votre dépôt, mais le répertoire de travail va
   1.693 +          rester synchroniser au même changeset qu'il l'était avant le pull.
   1.694 +          Si vous faites des changements et committez ensuite, vous allez
   1.695 +          créer une nouvelle head puisque votre répertoire de travail n'est
   1.696 +          pas synchronisé à ce que le tip actuel est. Pour combiner les
   1.697 +          opérations d'un pull suivi d'un update, exécutez run <command>hg
   1.698 +            pull -u</command>.</para>
   1.699 +      
   1.700 +        <para id="x_316">Je place le mot <quote>erreur</quote> entre
   1.701 +          guillemets parce que tous ce dont vous avez besoin de faire pour
   1.702 +          rectifier la situation où vous avez créé une nouvelle head par
   1.703 +          accident est un <command role="hg-cmd">hg merge</command> suivi
   1.704 +          d'un <command role="hg-cmd">hg commit</command>.  En d'autres mots,
   1.705 +          ceci n'a presque jamais de conséquences négatives ; il s'agit juste
   1.706 +          d'une surprise pour les nouveaux arrivants. Je discuterai d'autres
   1.707 +          moyens d'éviter ce comportement, et pourquoi Mercurial agit de
   1.708 +          cette façon surprenante plus tard.</para>
   1.709        </note>
   1.710  
   1.711      </sect2>
   1.712      <sect2>
   1.713 -      <title>Merging changes</title>
   1.714 -
   1.715 -      <para id="x_317">When you run the <command role="hg-cmd">hg
   1.716 -	  merge</command> command, Mercurial leaves the first parent
   1.717 -	of the working directory unchanged, and sets the second parent
   1.718 -	to the changeset you're merging with, as shown in <xref
   1.719 -	  linkend="fig:concepts:wdir-merge"/>.</para>
   1.720 +      <title>Fusionner (merge) les changements</title>
   1.721 +
   1.722 +      <para id="x_317">Lorsque vous exécutez la commande <command
   1.723 +          role="hg-cmd">hg merge</command>, Mercurial laisse le premier
   1.724 +        parent du répertoire de travail inchangé et fixe le second au
   1.725 +        changeset avec lequel vous fusionnez (merge), comme montré dans <xref
   1.726 +          linkend="fig:concepts:wdir-merge"/>.</para>
   1.727  
   1.728        <figure id="fig:concepts:wdir-merge">
   1.729 -	<title>Merging two heads</title>
   1.730 -	<mediaobject>
   1.731 -	  <imageobject>
   1.732 -	    <imagedata fileref="figs/wdir-merge.png"/>
   1.733 -	  </imageobject>
   1.734 -	  <textobject><phrase>XXX add text</phrase></textobject>
   1.735 -	</mediaobject>
   1.736 +        <title>Fusionner (merge) deux heads</title>
   1.737 +        <mediaobject>
   1.738 +          <imageobject> <imagedata fileref="figs/wdir-merge.png"/>
   1.739 +        </imageobject> <textobject><phrase>XXX add text</phrase></textobject>
   1.740 +      </mediaobject>
   1.741        </figure>
   1.742  
   1.743 -      <para id="x_319">Mercurial also has to modify the working directory, to
   1.744 -	merge the files managed in the two changesets.  Simplified a
   1.745 -	little, the merging process goes like this, for every file in
   1.746 -	the manifests of both changesets.</para>
   1.747 +      <para id="x_319">Mercurial doit aussi modifier le répertoire de
   1.748 +        travail pour fusionner les fichiers gérés dans les deux changesets.
   1.749 +        Un peu simplifié, le processus de fusion fonctionne comme ça : pour
   1.750 +        chaque fichier dans le manifest de chaque changeset.</para>
   1.751 +
   1.752        <itemizedlist>
   1.753 -	<listitem><para id="x_31a">If neither changeset has modified a file, do
   1.754 -	    nothing with that file.</para>
   1.755 -	</listitem>
   1.756 -	<listitem><para id="x_31b">If one changeset has modified a file, and the
   1.757 -	    other hasn't, create the modified copy of the file in the
   1.758 -	    working directory.</para>
   1.759 -	</listitem>
   1.760 -	<listitem><para id="x_31c">If one changeset has removed a file, and the
   1.761 -	    other hasn't (or has also deleted it), delete the file
   1.762 -	    from the working directory.</para>
   1.763 -	</listitem>
   1.764 -	<listitem><para id="x_31d">If one changeset has removed a file, but the
   1.765 -	    other has modified the file, ask the user what to do: keep
   1.766 -	    the modified file, or remove it?</para>
   1.767 -	</listitem>
   1.768 -	<listitem><para id="x_31e">If both changesets have modified a file,
   1.769 -	    invoke an external merge program to choose the new
   1.770 -	    contents for the merged file.  This may require input from
   1.771 -	    the user.</para>
   1.772 -	</listitem>
   1.773 -	<listitem><para id="x_31f">If one changeset has modified a file, and the
   1.774 -	    other has renamed or copied the file, make sure that the
   1.775 -	    changes follow the new name of the file.</para>
   1.776 -	</listitem></itemizedlist>
   1.777 -      <para id="x_320">There are more details&emdash;merging has plenty of corner
   1.778 -	cases&emdash;but these are the most common choices that are
   1.779 -	involved in a merge.  As you can see, most cases are
   1.780 -	completely automatic, and indeed most merges finish
   1.781 -	automatically, without requiring your input to resolve any
   1.782 -	conflicts.</para>
   1.783 -
   1.784 -      <para id="x_321">When you're thinking about what happens when you commit
   1.785 -	after a merge, once again the working directory is <quote>the
   1.786 -	  changeset I'm about to commit</quote>.  After the <command
   1.787 -	  role="hg-cmd">hg merge</command> command completes, the
   1.788 -	working directory has two parents; these will become the
   1.789 -	parents of the new changeset.</para>
   1.790 -
   1.791 -      <para id="x_322">Mercurial lets you perform multiple merges, but
   1.792 -	you must commit the results of each individual merge as you
   1.793 -	go.  This is necessary because Mercurial only tracks two
   1.794 -	parents for both revisions and the working directory.  While
   1.795 -	it would be technically feasible to merge multiple changesets
   1.796 -	at once, Mercurial avoids this for simplicity.  With multi-way
   1.797 -	merges, the risks of user confusion, nasty conflict
   1.798 -	resolution, and making a terrible mess of a merge would grow
   1.799 -	intolerable.</para>
   1.800 -
   1.801 -    </sect2>
   1.802 -
   1.803 -    <sect2>
   1.804 -      <title>Merging and renames</title>
   1.805 -
   1.806 -      <para id="x_69a">A surprising number of revision control systems pay little
   1.807 -	or no attention to a file's <emphasis>name</emphasis> over
   1.808 -	time.  For instance, it used to be common that if a file got
   1.809 -	renamed on one side of a merge, the changes from the other
   1.810 -	side would be silently dropped.</para>
   1.811 -
   1.812 -      <para id="x_69b">Mercurial records metadata when you tell it to perform a
   1.813 -	rename or copy. It uses this metadata during a merge to do the
   1.814 -	right thing in the case of a merge.  For instance, if I rename
   1.815 -	a file, and you edit it without renaming it, when we merge our
   1.816 -	work the file will be renamed and have your edits
   1.817 -	applied.</para>
   1.818 +        <listitem><para id="x_31a">Si aucun changeset n'a modifié un fichier,
   1.819 +            ne rien faire avec ce fichier.</para> </listitem>
   1.820 +        <listitem><para id="x_31b">Si un changeset a modifié un fichier et
   1.821 +            que l'autre ne l'a pas fait, créer une copie modifiée du fichier
   1.822 +            dans le répertoire de travail.</para> </listitem>
   1.823 +        <listitem><para id="x_31c">Si un changeset a modifié un fichier, et
   1.824 +            que l'autre ne l'a pas fait (ou l'a supprimé), supprimer le
   1.825 +            fichier du répertoire de travail.</para> </listitem>
   1.826 +        <listitem><para id="x_31d">Si un changeset a supprimé un fichier,
   1.827 +            mais que l'autre a modifié le fichier, demander à l'utilisateur
   1.828 +            quoi faire : garder le fichier modifié ou le supprimer ?</para>
   1.829 +        </listitem>
   1.830 +        <listitem><para id="x_31e">Si chacun des chengeset a modifié un
   1.831 +            fichier, invoquer le programme externe de fusion pour choisir les
   1.832 +            nouveaux contenus pour le fichier fusionné. Ceci peut demander
   1.833 +            des entrées de l'utilisateur.</para></listitem>
   1.834 +        <listitem><para id="x_31f">Si un changeset a modifié un fichier, et
   1.835 +            que l'autre a renommé ou copié le fichier, être sûr que les
   1.836 +            changements suivent le nouveau nom du fichier.</para></listitem>
   1.837 +      </itemizedlist>
   1.838 +      
   1.839 +      <para id="x_320">Il y a plus de détails&emdash;fusionner a beaucoup de
   1.840 +        cas anguleux&emdash;mais ceux-ci sont des chois plus communs qui sont
   1.841 +        invoqués pendant une fusion (merge). Comme vous pouvez le voir, la
   1.842 +        plupart des cas sont entièrement automatiques, et effectivement, la
   1.843 +        plupart des fusions (merge) se terminent automatiquement, sans avoir
   1.844 +        besoin d'entrées pour résoudre un conflit.</para>
   1.845 +
   1.846 +      <para id="x_321">Lorsque vous pensez à ce qu'il se passe lorsque vous
   1.847 +        committez après un merge, une fois encore, le répertoire de travail
   1.848 +        est <quote>le changeset que je suis sur le point de
   1.849 +          committer</quote>. Après que la commande <command role="hg-cmd">hg
   1.850 +          merge</command> ait terminé, le répertoire de travail a deux
   1.851 +        parents ; ceux ci vont devenir les parents du nouveau
   1.852 +        changeset.</para>
   1.853 +
   1.854 +      <para id="x_322">Mercurial vous permet d'exécuter de multiples fusions,
   1.855 +        mais vous devez committer le résultat de chaque fusion individuelle
   1.856 +        comme vous avancez. Ceci est nécessaire puisque Mercurial ne stock
   1.857 +        que deux parents pour chaque révision et le répertoire de travail.
   1.858 +        Alors qu'il serait techniquement faisble de fusionner de multiples
   1.859 +        changesets en même temps, Mercurial interdit cette simplicité. Avec
   1.860 +        des fusions multplus, les risques de confision utilisateur, de
   1.861 +        conflits néfastes de résolutions, et faire une pagaille d'une fusion
   1.862 +        grossiraient intollérablement.</para>
   1.863 +
   1.864 +    </sect2>
   1.865 +
   1.866 +    <sect2>
   1.867 +      <title>Fusions et renommages</title>
   1.868 +
   1.869 +      <para id="x_69a">Un nombre surprenant de systèmes de gestion de
   1.870 +        révision fait peu ou pas attention à un <emphasis>nom</emphasis> au
   1.871 +        cours du temps. Par exemple, il était habituel que si un fichier
   1.872 +        était renommé d'un coté de la fusion, les changements à partir de
   1.873 +        l'autre coté étaient supprimés silencieusement.</para>
   1.874 +
   1.875 +      <para id="x_69b">Mercurial enregistre les metadata lorsque vous lui
   1.876 +        dite d'exécuter un renommage ou une copie. Il utilise ces metadata
   1.877 +        durant une fusion pour faire les bonnes choses dans le cas d'un
   1.878 +        merge. Par exemple, si je renomme un fichier et que vous l'éditez
   1.879 +        sans le renommer, lorsque l'on fusionne, le fichier sera renommé et
   1.880 +        aura les éditions appliquées.</para>
   1.881 +
   1.882      </sect2>
   1.883    </sect1>
   1.884  
   1.885    <sect1>
   1.886 -    <title>Other interesting design features</title>
   1.887 -
   1.888 -    <para id="x_323">In the sections above, I've tried to highlight some of the
   1.889 -      most important aspects of Mercurial's design, to illustrate that
   1.890 -      it pays careful attention to reliability and performance.
   1.891 -      However, the attention to detail doesn't stop there.  There are
   1.892 -      a number of other aspects of Mercurial's construction that I
   1.893 -      personally find interesting.  I'll detail a few of them here,
   1.894 -      separate from the <quote>big ticket</quote> items above, so that
   1.895 -      if you're interested, you can gain a better idea of the amount
   1.896 -      of thinking that goes into a well-designed system.</para>
   1.897 -
   1.898 -    <sect2>
   1.899 -      <title>Clever compression</title>
   1.900 -
   1.901 -      <para id="x_324">When appropriate, Mercurial will store both snapshots and
   1.902 -	deltas in compressed form.  It does this by always
   1.903 -	<emphasis>trying to</emphasis> compress a snapshot or delta,
   1.904 -	but only storing the compressed version if it's smaller than
   1.905 -	the uncompressed version.</para>
   1.906 -
   1.907 -      <para id="x_325">This means that Mercurial does <quote>the right
   1.908 -	  thing</quote> when storing a file whose native form is
   1.909 -	compressed, such as a <literal>zip</literal> archive or a JPEG
   1.910 -	image.  When these types of files are compressed a second
   1.911 -	time, the resulting file is usually bigger than the
   1.912 -	once-compressed form, and so Mercurial will store the plain
   1.913 -	<literal>zip</literal> or JPEG.</para>
   1.914 -
   1.915 -      <para id="x_326">Deltas between revisions of a compressed file are usually
   1.916 -	larger than snapshots of the file, and Mercurial again does
   1.917 -	<quote>the right thing</quote> in these cases.  It finds that
   1.918 -	such a delta exceeds the threshold at which it should store a
   1.919 -	complete snapshot of the file, so it stores the snapshot,
   1.920 -	again saving space compared to a naive delta-only
   1.921 -	approach.</para>
   1.922 +    <title>D'autres fonctionnalités intéressantes</title>
   1.923 +
   1.924 +    <para id="x_323">Dans les sections au dessus, j'ai tenté de mettre
   1.925 +      l'accent sur certains aspects importants du design de Mercurial pour
   1.926 +      illustrer l'attention particulière qui a été portée à la fiabilité et à
   1.927 +      la performance.Cependant, l'attention aux détails ne s'arrête pas ici.
   1.928 +      Il y a de nombreux aspects sur la construction de Mercurial que je
   1.929 +      trouve personnellement intéressante. Je détaillerai quelques un d'eux
   1.930 +      ici, séparément des éléments du <quote>big ticket</quote> ci dessus,
   1.931 +      ainsi, si vous êtes intéressés, vous pourrez avoir une meilleure idée
   1.932 +      de la quantité de pensées qu'il y a derrière un système bien
   1.933 +      défini.</para>
   1.934 +
   1.935 +    <sect2>
   1.936 +      <title>Compression élégante</title>
   1.937 +
   1.938 +      <para id="x_324">Lorsque cela est approprié, Mercurial stocke les
   1.939 +        snapshots et deltas sous une forme compressée. Il le fait en
   1.940 +        <emphasis>essayant</emphasis> toujours de compression un snapshot ou
   1.941 +        un delta, mais en ne stockant la version compression que si celle ci
   1.942 +        est plus petite que la version non compressée.</para>
   1.943 +
   1.944 +      <para id="x_325">Ceci signifie que Mercurial fait <quote>la bonne
   1.945 +          chose</quote> lorsqu'il stocke un fichier dont la forme native est
   1.946 +        compressée, comme une archive <literal>zip</literal> ou une image
   1.947 +        JPEG. Lorsque ces types de fichiers sont compressés une seconde fois,
   1.948 +        le fichier obtenu est habituellement plus gros que la forme
   1.949 +        compressée une seule fois et Mercurial stockera alors le
   1.950 +        <literal>zip</literal> ou JPEG.</para>
   1.951 +
   1.952 +      <para id="x_326">Les Deltas entre les révisions d'un fichier compressé
   1.953 +        sont habituellement plus gros que les snapshots du fichier, et
   1.954 +        Mercurial fait à nouveau <quote>la bonne chose</quote> dans ces cas.
   1.955 +        Il trouve qu'un delta dépasse le seuil auquel il devrait stocker un
   1.956 +        snapshot complet du ficheir, alors il stocke le snapshot, en gagnant
   1.957 +        encore de la place en comparaison à une approche naïve delta
   1.958 +        seulement.</quote>
   1.959  
   1.960        <sect3>
   1.961 -	<title>Network recompression</title>
   1.962 -
   1.963 -	<para id="x_327">When storing revisions on disk, Mercurial uses the
   1.964 -	  <quote>deflate</quote> compression algorithm (the same one
   1.965 -	  used by the popular <literal>zip</literal> archive format),
   1.966 -	  which balances good speed with a respectable compression
   1.967 -	  ratio.  However, when transmitting revision data over a
   1.968 -	  network connection, Mercurial uncompresses the compressed
   1.969 -	  revision data.</para>
   1.970 -
   1.971 -	<para id="x_328">If the connection is over HTTP, Mercurial recompresses
   1.972 -	  the entire stream of data using a compression algorithm that
   1.973 -	  gives a better compression ratio (the Burrows-Wheeler
   1.974 -	  algorithm from the widely used <literal>bzip2</literal>
   1.975 -	  compression package).  This combination of algorithm and
   1.976 -	  compression of the entire stream (instead of a revision at a
   1.977 -	  time) substantially reduces the number of bytes to be
   1.978 -	  transferred, yielding better network performance over most
   1.979 -	  kinds of network.</para>
   1.980 -
   1.981 -	<para id="x_329">If the connection is over
   1.982 -	  <command>ssh</command>, Mercurial
   1.983 -	  <emphasis>doesn't</emphasis> recompress the stream, because
   1.984 -	  <command>ssh</command> can already do this itself.  You can
   1.985 -	  tell Mercurial to always use <command>ssh</command>'s
   1.986 -	  compression feature by editing the
   1.987 -	  <filename>.hgrc</filename> file in your home directory as
   1.988 -	  follows.</para>
   1.989 -
   1.990 -	<programlisting>[ui]
   1.991 +        <title>Recompression réseau</title>
   1.992 +      
   1.993 +        <para id="x_327">Lors du stockage des révisions sur le disque,
   1.994 +          Mercurial utilise l'algorithme de compression
   1.995 +          <quote>deflate</quote> (le même que celui utilisé pour le format
   1.996 +          d'archive populaire <literal>zip</literal>), qui est un bon
   1.997 +          comprimis entre la vitesse et le taux de compression. Cependant,
   1.998 +          lors de la transmission d'une révision de données par une connexion
   1.999 +          réseau, Mercurial décompresse les données de révision
  1.1000 +          compressées.</para>
  1.1001 +      
  1.1002 +        <para id="x_328">Si la connexion est au dessus de HTTP, mercurial
  1.1003 +          recompresse le flux entier de données en utilisant un algorithme de
  1.1004 +          compression qui donne un meilleur taux de compression (l'algorithme
  1.1005 +          Burrows-Wheeler utilisé principalement par le package de
  1.1006 +          compression <literal>bzip2</literal>). Cette combinaison de
  1.1007 +          l'algorithme et de compression du flux entier (plutôt que pour une
  1.1008 +          révision à la fois) réduit substanciellement le nombre de bits qui
  1.1009 +          sont transférés, résultant dans une performance réseau accrue sur
  1.1010 +          la plupart des supports.</para>
  1.1011 +      
  1.1012 +        <para id="x_329">Si la connexion est au dessus de
  1.1013 +          <command>ssh</command>, Mercurial <emphasis>ne</emphasis>
  1.1014 +          recompresse <emphasis>pas</emphasis> le flux puisque
  1.1015 +          <command>ssh</command> peut déjà le faire par lui même. Vous pouvez
  1.1016 +          demander à Mercurial de toujours utiliser la compression
  1.1017 +          <command>ssh</command> en éditant le fichier
  1.1018 +          <filename>.hgrc</filename> de votre répertoire personnale comme ci
  1.1019 +          dessous.</para>
  1.1020 +      
  1.1021 +        <programlisting>[ui]
  1.1022  ssh = ssh -C</programlisting>
  1.1023  
  1.1024        </sect3>
  1.1025      </sect2>
  1.1026      <sect2>
  1.1027 -      <title>Read/write ordering and atomicity</title>
  1.1028 -
  1.1029 -      <para id="x_32a">Appending to files isn't the whole story when
  1.1030 -	it comes to guaranteeing that a reader won't see a partial
  1.1031 -	write.  If you recall <xref linkend="fig:concepts:metadata"/>,
  1.1032 -	revisions in the changelog point to revisions in the manifest,
  1.1033 -	and revisions in the manifest point to revisions in filelogs.
  1.1034 -	This hierarchy is deliberate.</para>
  1.1035 -
  1.1036 -      <para id="x_32b">A writer starts a transaction by writing filelog and
  1.1037 -	manifest data, and doesn't write any changelog data until
  1.1038 -	those are finished.  A reader starts by reading changelog
  1.1039 -	data, then manifest data, followed by filelog data.</para>
  1.1040 -
  1.1041 -      <para id="x_32c">Since the writer has always finished writing filelog and
  1.1042 -	manifest data before it writes to the changelog, a reader will
  1.1043 -	never read a pointer to a partially written manifest revision
  1.1044 -	from the changelog, and it will never read a pointer to a
  1.1045 -	partially written filelog revision from the manifest.</para>
  1.1046 -
  1.1047 -    </sect2>
  1.1048 -    <sect2>
  1.1049 -      <title>Concurrent access</title>
  1.1050 -
  1.1051 -      <para id="x_32d">The read/write ordering and atomicity guarantees mean that
  1.1052 -	Mercurial never needs to <emphasis>lock</emphasis> a
  1.1053 -	repository when it's reading data, even if the repository is
  1.1054 -	being written to while the read is occurring. This has a big
  1.1055 -	effect on scalability; you can have an arbitrary number of
  1.1056 -	Mercurial processes safely reading data from a repository
  1.1057 -	all at once, no matter whether it's being written to or
  1.1058 -	not.</para>
  1.1059 -
  1.1060 -      <para id="x_32e">The lockless nature of reading means that if you're
  1.1061 -	sharing a repository on a multi-user system, you don't need to
  1.1062 -	grant other local users permission to
  1.1063 -	<emphasis>write</emphasis> to your repository in order for
  1.1064 -	them to be able to clone it or pull changes from it; they only
  1.1065 -	need <emphasis>read</emphasis> permission.  (This is
  1.1066 -	<emphasis>not</emphasis> a common feature among revision
  1.1067 -	control systems, so don't take it for granted!  Most require
  1.1068 -	readers to be able to lock a repository to access it safely,
  1.1069 -	and this requires write permission on at least one directory,
  1.1070 -	which of course makes for all kinds of nasty and annoying
  1.1071 -	security and administrative problems.)</para>
  1.1072 -
  1.1073 -      <para id="x_32f">Mercurial uses locks to ensure that only one process can
  1.1074 -	write to a repository at a time (the locking mechanism is safe
  1.1075 -	even over filesystems that are notoriously hostile to locking,
  1.1076 -	such as NFS).  If a repository is locked, a writer will wait
  1.1077 -	for a while to retry if the repository becomes unlocked, but
  1.1078 -	if the repository remains locked for too long, the process
  1.1079 -	attempting to write will time out after a while. This means
  1.1080 -	that your daily automated scripts won't get stuck forever and
  1.1081 -	pile up if a system crashes unnoticed, for example.  (Yes, the
  1.1082 -	timeout is configurable, from zero to infinity.)</para>
  1.1083 +      <title>Ordres de Lecture/Écriture et atomicité</title>
  1.1084 +
  1.1085 +      <para id="x_32a">Ajouter à la fin des fichiers n'est pas toute
  1.1086 +        l'histoire lorsque l'on cherche à garantir que le lecteur ne verra
  1.1087 +        pas qu'une écriture partielle. Si vous relisez <xref
  1.1088 +          linkend="fig:concepts:metadata"/>, les révisions dans le changelog
  1.1089 +        pointent vers les révisions dans le manifest, et les révisions du
  1.1090 +        manifest pointent vers les révisions du filelog. Cette hiérarchie est
  1.1091 +        délibérée.</para>
  1.1092 +
  1.1093 +      <para id="x_32b">L'écriture commence une transaction en écrivant dans
  1.1094 +        le filelog et dans les données du manifest, et n'écrit aucune donnée
  1.1095 +        changelog tant que ce n'est pas terminé. La lecture commence en
  1.1096 +        lisant les données du changelog, puis les données du manifest, et
  1.1097 +        enfin les données du filelog.</para>
  1.1098 +
  1.1099 +      <para id="x_32c">Puisque que l'écriture ne finit pas d'écrire les
  1.1100 +        données du filelog et du manifest avant d'écrire dans le changelog,
  1.1101 +        la lecture ne verra jamais un pointeur vers une révision du manifest
  1.1102 +        partiellement écrite à partir du changelog, et ne lira jamais un
  1.1103 +        pointeur vers une révision du filelog partiellement écrite dans le
  1.1104 +        manifest.</para>
  1.1105 +
  1.1106 +    </sect2>
  1.1107 +    <sect2>
  1.1108 +      <title>Accès concurrent</title>
  1.1109 +
  1.1110 +      <para id="x_32d">La garantie de l'ordre de lecture/écriture et
  1.1111 +        de l'atomicite signifie que Mercurial n'a jamais besoin de poser de
  1.1112 +        <emphasis>lock</emphasis> sur un dépôt lorsqu'il lit des données,
  1.1113 +        même si le dépôt est en train d'être écrit au même moment que la
  1.1114 +        lecture a lieue. Ceci a un grand impact sur la fiabilité ; vous
  1.1115 +        pouvez avoir un nombre arbitraire de processus Mercurial qui lisent
  1.1116 +        dans risque en même temps les données d'un dépôt, peu importe s'il
  1.1117 +        est en train d'être lu ou non.</para>
  1.1118 +
  1.1119 +      <para id="x_32e">La nature sans <quote>lock</quote> de la lecture
  1.1120 +        signifie que si vous partagez un dépôt sur un système
  1.1121 +        multi-utilisateurs, vous n'avez pas besoin de donner aux autres
  1.1122 +        utilisateurs locaux la permission d'<emphasis>écrire</emphasis> sur
  1.1123 +        votre dépôt pour qu'ils soient capable de faire un clone ou un pull
  1.1124 +        des changements à partir de celui ci ; ils ont seulement besoin de la
  1.1125 +        permission en <emphasis>lecture</emphasis>. (Il
  1.1126 +        <emphasis>ne</emphasis> s'agit <emphasis>pas</emphasis> d'une
  1.1127 +        fonctionnalité commune à travers les systèmes de gestion de révision,
  1.1128 +        donc ne prenez pas ça pour garanti ! La plupart ont besoin que les
  1.1129 +        lecteurs soient capables de mettre un lock sur le dépôt pour y
  1.1130 +        accéder en toute sécurité, et ceci demande des permissions en
  1.1131 +        écriture, sur au moins un dépertoire, ce qui provoque biensûr toutes
  1.1132 +        sortes de problèmes néfastes et ennuyants relatifs à la sécurité et à
  1.1133 +        l'administration.)</para>
  1.1134 +
  1.1135 +      <para id="x_32f">Mercurial utilise des locs pour assurer qu'un seul
  1.1136 +        processus peut écrire dans le dépôt à un moment donné (le mécanisme
  1.1137 +        de lock est sûr, même sur des systèmes de fichiers qui sont connus
  1.1138 +        pour être hostiles aux locks, comme NFS). Si un dépôt dispose d'un
  1.1139 +        lock, un processus qui cherche à écrire va attendre un peu avant de
  1.1140 +        retenter pour voir si le dépôt perd son lock, mais le dépôt garde
  1.1141 +        trop longtemps son lock, le processus qui tente d'écrire va expirer
  1.1142 +        (time out) après un moment. Celà veut dire par exemple que vous
  1.1143 +        scripts lancés quotidiennement n'attendront pas toujours et boucler
  1.1144 +        si un système crashait sans avertissement, par exemple. (Oui, le
  1.1145 +        timeout est configurable, de zéro à l'infini.)</para>
  1.1146  
  1.1147        <sect3>
  1.1148 -	<title>Safe dirstate access</title>
  1.1149 -
  1.1150 -	<para id="x_330">As with revision data, Mercurial doesn't take a lock to
  1.1151 -	  read the dirstate file; it does acquire a lock to write it.
  1.1152 -	  To avoid the possibility of reading a partially written copy
  1.1153 -	  of the dirstate file, Mercurial writes to a file with a
  1.1154 -	  unique name in the same directory as the dirstate file, then
  1.1155 -	  renames the temporary file atomically to
  1.1156 -	  <filename>dirstate</filename>.  The file named
  1.1157 -	  <filename>dirstate</filename> is thus guaranteed to be
  1.1158 -	  complete, not partially written.</para>
  1.1159 +	<title>Accès dirstate sûr</title>
  1.1160 +
  1.1161 +	<para id="x_330">Comme avec les données de révision, Mercurial ne prend pas
  1.1162 +    de lock pour lire le fichier dirstate ; il n'acquier pas un lock pour
  1.1163 +    y écrire. Pour empécher la possibilité de lire une copie partiellement
  1.1164 +    écrite du fichier dirstate, Mercurial écrit à un fichier avec un nom
  1.1165 +    unique dans le même répertoire que le fichier dirstate, ensuite renomme
  1.1166 +    le fichier temporaire automatiquement en <filename>dirstate</filename>.
  1.1167 +    Le fichier nommé <filename>dirstate</filename> est ainsi garanti d'être
  1.1168 +    écrit totalement, et non partiellement.</para>
  1.1169  
  1.1170        </sect3>
  1.1171      </sect2>
  1.1172      <sect2>
  1.1173 -      <title>Avoiding seeks</title>
  1.1174 -
  1.1175 -      <para id="x_331">Critical to Mercurial's performance is the avoidance of
  1.1176 -	seeks of the disk head, since any seek is far more expensive
  1.1177 -	than even a comparatively large read operation.</para>
  1.1178 -
  1.1179 -      <para id="x_332">This is why, for example, the dirstate is stored in a
  1.1180 -	single file.  If there were a dirstate file per directory that
  1.1181 -	Mercurial tracked, the disk would seek once per directory.
  1.1182 -	Instead, Mercurial reads the entire single dirstate file in
  1.1183 -	one step.</para>
  1.1184 -
  1.1185 -      <para id="x_333">Mercurial also uses a <quote>copy on write</quote> scheme
  1.1186 -	when cloning a repository on local storage.  Instead of
  1.1187 -	copying every revlog file from the old repository into the new
  1.1188 -	repository, it makes a <quote>hard link</quote>, which is a
  1.1189 -	shorthand way to say <quote>these two names point to the same
  1.1190 -	  file</quote>.  When Mercurial is about to write to one of a
  1.1191 -	revlog's files, it checks to see if the number of names
  1.1192 -	pointing at the file is greater than one.  If it is, more than
  1.1193 -	one repository is using the file, so Mercurial makes a new
  1.1194 -	copy of the file that is private to this repository.</para>
  1.1195 -
  1.1196 -      <para id="x_334">A few revision control developers have pointed out that
  1.1197 -	this idea of making a complete private copy of a file is not
  1.1198 -	very efficient in its use of storage.  While this is true,
  1.1199 -	storage is cheap, and this method gives the highest
  1.1200 -	performance while deferring most book-keeping to the operating
  1.1201 -	system.  An alternative scheme would most likely reduce
  1.1202 -	performance and increase the complexity of the software, but
  1.1203 -	speed and simplicity are key to the <quote>feel</quote> of
  1.1204 -	day-to-day use.</para>
  1.1205 -
  1.1206 -    </sect2>
  1.1207 -    <sect2>
  1.1208 -      <title>Other contents of the dirstate</title>
  1.1209 -
  1.1210 -      <para id="x_335">Because Mercurial doesn't force you to tell it when you're
  1.1211 -	modifying a file, it uses the dirstate to store some extra
  1.1212 -	information so it can determine efficiently whether you have
  1.1213 -	modified a file.  For each file in the working directory, it
  1.1214 -	stores the time that it last modified the file itself, and the
  1.1215 -	size of the file at that time.</para>
  1.1216 -
  1.1217 -      <para id="x_336">When you explicitly <command role="hg-cmd">hg
  1.1218 -	  add</command>, <command role="hg-cmd">hg remove</command>,
  1.1219 -	<command role="hg-cmd">hg rename</command> or <command
  1.1220 -	  role="hg-cmd">hg copy</command> files, Mercurial updates the
  1.1221 -	dirstate so that it knows what to do with those files when you
  1.1222 -	commit.</para>
  1.1223 -
  1.1224 -      <para id="x_337">The dirstate helps Mercurial to efficiently
  1.1225 -	  check the status of files in a repository.</para>
  1.1226 +      <title>Empécher les recherches</title>
  1.1227 +
  1.1228 +      <para id="x_331">L'absence de recherche sur les têtes de disques est
  1.1229 +        critique pour la performance de Mercurial, puisque toute recherche
  1.1230 +        est beaucoup plus coûteuse comparativement à une grosse opération de
  1.1231 +        lecture.</para>
  1.1232 +
  1.1233 +      <para id="x_332">C'est pour ça, par exemple, que le dirstate est stocké
  1.1234 +        dans un unique fichier. S'il y avait eu un dirstate par répertoire
  1.1235 +        que Mercurial suivait, le disque aurait recherché une fois par
  1.1236 +        répertoire. Au lieu de ça, Mercurial lit entièrement un unique
  1.1237 +        fichier, en une étape.</para>
  1.1238 +
  1.1239 +      <para id="x_333">Mercurial utilise aussi un schéma <quote>copie à
  1.1240 +          l'écriture</quote> lorsqu'il clone un dépôt sur un stockage local.
  1.1241 +        Au lieu de copier chaque fichier revlog depuis l'ancien dépôt vers le
  1.1242 +        nouveau dépôt, il crée un <quote>lien physique</quote>, qui est le
  1.1243 +        plus court chemin pour dire <quote>Ces deux noms pointent vers le
  1.1244 +          même fichier</quote>. Lorsque Mercurial est sur le point d'écrire
  1.1245 +        sur l'un des revlogs de ces fichiers, il vérifie si le nombre de noms
  1.1246 +        pointant sur ce fichier est plus grand que un. Si c'est le cas, plus
  1.1247 +        d'un dépôt utilise le fichier, donc Mercurial crée une nouvelle copie
  1.1248 +        du fichier qui est privée à ce dépôt.</para>
  1.1249 +
  1.1250 +      <para id="x_334">Quelques développeurs de systèmes de gestion de
  1.1251 +        révision ont montré que cette idée de faire une copie privée complète
  1.1252 +        d'un fichier n'est pas vraiment efficace dans son utilisation du
  1.1253 +        stockage. Bien que ce soit vrai, le stockage est peu onéreux, et
  1.1254 +        cette méthode donne la plus grande performance lorsque l'on reporte
  1.1255 +        la plupart des journalisations au système d'exploitation. Un schéma
  1.1256 +        alternatif réduirait certainement la performance tout en augmentant
  1.1257 +        la complexité du logiciel, mais la vitesse et la simplicité sont els
  1.1258 +        clefs du <quote>sentiment</quote> de l'utilisation
  1.1259 +        quotidienne.</para>
  1.1260 +
  1.1261 +    </sect2>
  1.1262 +    <sect2>
  1.1263 +      <title>Autres contenus du dirstate</title>
  1.1264 +
  1.1265 +      <para id="x_335">Puisque Mercurial ne vous force pas à dire lorsque
  1.1266 +        vous modifiez un fichier, il utilise le dirstate pour stocker
  1.1267 +        certaines informations supplémentaires pour déterminer efficacement
  1.1268 +        si vous avez ou non modifié un fichier. Pour chaque fichier du
  1.1269 +        répertoire de travail, il stocke l'heure à laquelle il a été modifié,
  1.1270 +        ainsi que la taille du fichier à cette heure.</para>
  1.1271 +
  1.1272 +      <para id="x_336">Lorsque vous faites explicitement un <command
  1.1273 +          role="hg-cmd">hg add</command>, <command role="hg-cmd">hg
  1.1274 +          remove</command>, <command role="hg-cmd">hg rename</command> ou
  1.1275 +        <command role="hg-cmd">hg copy</command> sur des fichiers, Mercurial
  1.1276 +        met à jour le dirstate afin de savoir quoi faire lorsque vous
  1.1277 +        effectuez un commit.</para>
  1.1278 +
  1.1279 +      <para id="x_337">Le dirstate aide Mercurial à vérifier efficacement le
  1.1280 +        status des fichiers dans un dépôt.</para>
  1.1281  
  1.1282        <itemizedlist>
  1.1283 -	<listitem>
  1.1284 -	  <para id="x_726">When Mercurial checks the state of a file in the
  1.1285 -	    working directory, it first checks a file's modification
  1.1286 -	    time against the time in the dirstate that records when
  1.1287 -	    Mercurial last wrote the file. If the last modified time
  1.1288 -	    is the same as the time when Mercurial wrote the file, the
  1.1289 -	    file must not have been modified, so Mercurial does not
  1.1290 -	    need to check any further.</para>
  1.1291 -	</listitem>
  1.1292 -	<listitem>
  1.1293 -	  <para id="x_727">If the file's size has changed, the file must have
  1.1294 -	    been modified.  If the modification time has changed, but
  1.1295 -	    the size has not, only then does Mercurial need to
  1.1296 -	    actually read the contents of the file to see if it has
  1.1297 -	    changed.</para>
  1.1298 -	</listitem>
  1.1299 +        <listitem> <para id="x_726"> Lorsque Mercurial vérifie l'état d'un
  1.1300 +            fichier du répertoire de travail, il compare d'abord la date de
  1.1301 +            dernière modification du fichier avec celle enregistrée dans le
  1.1302 +            dirstate qui correspond à Mercurial a écrit en dernier sur ce
  1.1303 +            fichier. Si le temps de dernière modification correspond au temps
  1.1304 +            où Mercurial a écrit le fichier, celui ci n'a pas été modifié,
  1.1305 +            donc mercurial n'a pas besoin de revérifier.</para> </listitem>
  1.1306 +        <listitem> <para id="x_727"> Si la taille du fichier a changé, celui
  1.1307 +            ci a été modifié. Si la date de modification a changé mais que la
  1.1308 +            taille est restée inchangée, seulement à ce moment là Mercurial
  1.1309 +            doit vérifier le contenu du fichier pour savoir s'il a été
  1.1310 +            modifié.</para> </listitem>
  1.1311        </itemizedlist>
  1.1312  
  1.1313 -      <para id="x_728">Storing the modification time and size dramatically
  1.1314 -	reduces the number of read operations that Mercurial needs to
  1.1315 -	perform when we run commands like <command>hg status</command>.
  1.1316 -	This results in large performance improvements.</para>
  1.1317 +      <para id="x_728">Enregistrer la date de modification et la taille
  1.1318 +        réduit grandement le nombre d'opérations de lecture que Mercurial
  1.1319 +        doit effectuer lorsque l'on utilise une commande comme <command>hg
  1.1320 +          status</command>. Le résultat est un grand gain de
  1.1321 +        performance.</para>
  1.1322      </sect2>
  1.1323    </sect1>
  1.1324  </chapter>