1.1 --- a/fr/ch04-concepts.xml	Tue Sep 15 13:43:02 2009 +0200
     1.2 +++ b/fr/ch04-concepts.xml	Thu Sep 17 10:30:33 2009 +0200
     1.3 @@ -4,16 +4,16 @@
     1.4    <?dbhtml filename="behind-the-scenes.html"?>
     1.5    <title>Derrière le décor</title>
     1.6    
     1.7 -  <para id="x_2e8">À la différence de beaucoup d'outils de gestion de versions,
     1.8 +  <para id="x_2e8">À la différence de beaucoup d'outils de gestion de révisions,
     1.9      les concepts sur lesquels se base Mercurial sont assez simples pour
    1.10      qu'il soit facile de comprendre comment le logiciel fonctionne.
    1.11 -    Bien que leur connaissance ne soit pas nécéssaire, je trouve utile
    1.12 +    Bien que leur connaissance ne soit pas indispensable, je trouve utile
    1.13      d'avoir un <quote>modèle mental</quote> de ce qui se passe.</para>
    1.14  
    1.15    <para id="x_2e9">En effet, cette compréhension m'apporte la confiance que
    1.16      Mercurial a été développé avec soin pour être à la fois
    1.17      <emphasis>sûr</emphasis> et <emphasis>efficace</emphasis>. De surcroît,
    1.18 -    si il m'est facile de garder en tête ce que le logiciel fait lorsque
    1.19 +    s'il m'est facile de garder en tête ce que le logiciel fait lorsque
    1.20      j'accompli des tâches de révision, j'aurai moins de risques d'être
    1.21      surpris par son comportement.</para>
    1.22  
    1.23 @@ -29,25 +29,25 @@
    1.24        <para id="x_2eb">Lorsque Mercurial effectue un suivi des modifications
    1.25          faites à un fichier, il conserve l'historique pour ce fichier dans un
    1.26          <emphasis>filelog</emphasis> sous forme de métadonnées. Chaque entrée
    1.27 -        dans le filelog contient assez d'informations pour reconstituer une
    1.28 -        révision du fichier correspondant. Les filelogs sont des fichiers
    1.29 +        dans le <quote>filelog</quote> contient assez d'informations pour reconstituer une
    1.30 +        révision du fichier correspondant. Les <quote>filelogs</quote> sont des fichiers
    1.31          stockés dans le répertoire  <filename role="special"
    1.32 -          class="directory">.hg/store/data</filename>. Un filelog contient
    1.33 +            class="directory">.hg/store/data</filename>. Un <quote>filelog</quote> contient
    1.34          des informations de deux types: les données de révision, et un index
    1.35          pour permettre à Mercurial une recherche efficace d'une révision
    1.36          donnée.</para>
    1.37  
    1.38        <para id="x_2ec">Lorsqu'un fichier devient trop gros ou a un long
    1.39 -        historique, son filelog se voit stocker dans un fichier de données
    1.40 +          historique, son <quote>filelog</quote> se voit stocké dans un fichier de données
    1.41          (avec un suffixe <quote><literal>.d</literal></quote>) et un fichier
    1.42          index (avec un suffixe<quote><literal>.i</literal></quote>)
    1.43          distincts. La relation entre un fichier dans le répertoire de travail
    1.44 -        et le  filelog couvrant le suivi de son historique dans le dépôt est
    1.45 +        et le <quote>filelog</quote> couvrant le suivi de son historique dans le dépôt est
    1.46          illustré à la figure <xref linkend="fig:concepts:filelog"/>.</para>
    1.47  
    1.48        <figure id="fig:concepts:filelog">
    1.49          <title>Relations entre les fichiers dans le répertoire de travail et
    1.50 -        leurs filelogs dans le dépôt</title> 
    1.51 +            leurs <quote>filelogs</quote> dans le dépôt</title> 
    1.52          <mediaobject> <imageobject><imagedata
    1.53                fileref="figs/filelog.png"/></imageobject>
    1.54            <textobject><phrase>XXX add text</phrase></textobject>
    1.55 @@ -59,7 +59,7 @@
    1.56        
    1.57        <para id="x_2ee">Mercurial a recours à une structure nommée
    1.58          <emphasis>manifest</emphasis> pour rassembler les informations sur
    1.59 -        les fichiers dont il gère le suivi. Chaque entrée dans ce manifest
    1.60 +        les fichiers dont il gère le suivi. Chaque entrée dans ce <quote>manifest</quote>
    1.61          contient des informations sur les fichiers présents dans une révision
    1.62          donnée. Une entrée enregistre la liste des fichiers faisant partie de la
    1.63          révision, la version de chaque fichier, et quelques autres
    1.64 @@ -67,31 +67,31 @@
    1.65  
    1.66      </sect2>
    1.67      <sect2>
    1.68 -      <title>Enregistrer les informations des changeset</title>
    1.69 +        <title>Enregistrer les informations des <quote>changesets</quote></title>
    1.70  
    1.71        <para id="x_2ef">Le <emphasis>changelog</emphasis> contient les
    1.72 -        informations sur chaque changeset. Chaque révision enregistre qui a
    1.73 -        committé un changement, le commentaire du changeset, d'autres
    1.74 -        morceaux d'information relatives au changeset et la révision du
    1.75 -        manifest à utiliser.</para>
    1.76 +          informations sur chaque <quote>changeset</quote>. Chaque révision enregistre qui a
    1.77 +          <quote>committé</quote> un changement, le commentaire du <quote>changeset</quote>, d'autres
    1.78 +          morceaux d'information relatives au <quote>changeset</quote> et la révision du
    1.79 +          <quote>manifest</quote> à utiliser.</para>
    1.80  
    1.81      </sect2>
    1.82      <sect2>
    1.83        <title>Relations entre les révisions</title>
    1.84  
    1.85 -      <para id="x_2f0">A l'intérieur d'un changelog, d'un manifest, ou d'un
    1.86 -        filelog, chaque révision enregistre un pointeur vers son parent
    1.87 +      <para id="x_2f0">A l'intérieur d'un <quote>changelog</quote>, d'un <quote>manifest</quote>, ou d'un
    1.88 +          <quote>filelog</quote>, chaque révision enregistre un pointeur vers son parent
    1.89          immédiat (ou à ses deux parents s'il s'agit d'une révision
    1.90          correspondant à une fusion (merge)). Comme mentionné plus haut, il y
    1.91          a aussi des relations entre les révisions <emphasis>à
    1.92            travers</emphasis> ces structures, qui sont de nature
    1.93          hiérarchique.</para>
    1.94  
    1.95 -      <para id="x_2f1">Pour chaque changeset dans un dépôt, il y a exactement
    1.96 -        une révision stockée dans le changelog. Chaque révision du changelog
    1.97 -        contient un pointeur vers une unique révision du manifest. Une
    1.98 -        révision du manifeste garde un pointeur vers une unique révision pour
    1.99 -        chaque filelog suivi lorsque le changeset est créé. Ces relations
   1.100 +    <para id="x_2f1">Pour chaque <quote>changeset</quote> dans un dépôt, il y a exactement
   1.101 +        une révision stockée dans le <quote>changelog</quote>. Chaque révision du <quote>changelog</quote>
   1.102 +        contient un pointeur vers une unique révision du <quote>manifest</quote>. Une
   1.103 +        révision du <quote>manifest</quote> garde un pointeur vers une unique révision pour
   1.104 +        chaque <quote>filelog</quote> suivi lorsque le <quote>changeset</quote> est créé. Ces relations
   1.105          sont illustrées dans <xref linkend="fig:concepts:metadata"/>.</para>
   1.106  
   1.107        <figure id="fig:concepts:metadata">
   1.108 @@ -102,16 +102,16 @@
   1.109          </mediaobject>
   1.110        </figure>
   1.111  
   1.112 -      <para id="x_2f3">Comme l'illustration le monde, il
   1.113 +      <para id="x_2f3">Comme l'illustration le montre, il
   1.114          <emphasis>n'</emphasis>y a <emphasis>pas</emphasis> de relation
   1.115 -        <quote>un à un</quote> entre les révisions dans un changelog,
   1.116 -        manifest ou filelog. Si un fichier que Mercurial suit n'a pas changé
   1.117 -        entre deux changesets, l'entrée pour ce fichier dans les deux
   1.118 -        révisions du manifest pointera vers la même révision de son filelog
   1.119 +        <quote>un à un</quote> entre les révisions dans un <quote>changelog</quote>,
   1.120 +        <quote>manifest</quote> ou <quote>filelog</quote>. Si un fichier que Mercurial suit n'a pas changé
   1.121 +        entre deux <quote>changesets</quote>, l'entrée pour ce fichier dans les deux
   1.122 +        révisions du <quote>manifest</quote> pointera vers la même révision de son <quote>filelog</quote>
   1.123          <footnote> <para id="x_725">Il est possible (bien qu'inhabituel)
   1.124 -            qu'un manifest reste le même entre deux changesets, auquel cas
   1.125 -            l'entrée du changelog pour ces changesets pointera vers la même
   1.126 -            révision du manifest.</para>
   1.127 +                qu'un <quote>manifest</quote> reste le même entre deux <quote>changesets</quote>, auquel cas
   1.128 +                l'entrée du <quote>changelog</quote> pour ces <quote>changesets</quote> pointera vers la même
   1.129 +                révision du <quote>manifest</quote>.</para>
   1.130          </footnote>.</para>
   1.131  
   1.132      </sect2>
   1.133 @@ -119,22 +119,22 @@
   1.134    <sect1>
   1.135      <title>Stockage sûr et efficace</title>
   1.136  
   1.137 -    <para id="x_2f4">Les fondements des changelogs, des manifests et des
   1.138 -      filelogs sont fournis par une unique structure appelée le
   1.139 +    <para id="x_2f4">Les fondements des <quote>changelogs</quote>, des <quote>manifests</quote> et des
   1.140 +        <quote>filelogs</quote> sont fournis par une unique structure appelée le
   1.141        <emphasis>revlog</emphasis>.</para>
   1.142  
   1.143      <sect2>
   1.144        <title>stockage efficace</title>
   1.145  
   1.146 -      <para id="x_2f5">Le revlog fournit un stockage efficace des révision en
   1.147 +      <para id="x_2f5">Le <quote>revlog</quote> fournit un stockage efficace des révisions en
   1.148          utilisant un mécanisme <emphasis>delta</emphasis>. A lieu de stocker
   1.149          une copie complète d'un fichier à chaque révision, il stocke les
   1.150 -        changements requis pour transformer une révision plus ancienne en la
   1.151 +        changements requis pour transformer une révision plus ancienne en une
   1.152          nouvelle révision. Pour plusieurs type de données, ces deltas sont
   1.153          typiquement une fraction de pourcentage de la taille de la copie
   1.154          complète d'un fichier.</para>
   1.155  
   1.156 -      <para id="x_2f6">Certains systèmes de gestion de révisions obselètes
   1.157 +      <para id="x_2f6">Certains systèmes de gestion de révisions obsolètes
   1.158          peuvent seulement travailler avec les deltas de fichiers texte. Il
   1.159          doivent d'ailleurs stocker les fichiers binaires comme des images
   1.160          complètes ou encodées avec une représentation texte, chacune de ces
   1.161 @@ -147,15 +147,15 @@
   1.162        <title>Opérations sûres</title>
   1.163  
   1.164        <para id="x_2f7">Mercurial <emphasis>empile</emphasis> toujours les
   1.165 -        données à la fin d'un fichier revlog. Il ne modifie jamais la section
   1.166 -        d'un fichier après qu'il l'ait écrite. C'est à la foit plus robuste
   1.167 +          données à la fin d'un fichier <quote>revlog</quote>. Il ne modifie jamais la section
   1.168 +        d'un fichier après qu'il l'ait écrite. C'est à la fois plus robuste
   1.169          et efficace que les schémas qui ont besoin de modifier ou réécrire
   1.170          les données.</para>
   1.171  
   1.172 -      <para id="x_2f8">De plus, Mercurial traite chaque écriture comme une
   1.173 +      <para id="x_2f8">De plus, Mercurial traite chaque écriture comme la
   1.174          partie d'une <emphasis>transaction</emphasis> qui peut comprendre
   1.175          plusieurs fichiers. Une transaction est <emphasis>atomique</emphasis>
   1.176 -        : spot la transaction entière réussit et ses effets sont tous
   1.177 +        : soit la transaction entière réussie ses effets sont tous
   1.178          visibles aux lecteurs en une étape, soit la totalité est annulée.
   1.179          Cette garantie de l'atomicité signifie que si vous exécutez deux
   1.180          copies de Mercurial, où une lit les données et l'autre les écrit, le
   1.181 @@ -176,16 +176,16 @@
   1.182          <emphasis>récupération inefficace</emphasis> La plupart des systèmes
   1.183          de gestion de révisions stockent le contenu d'une révision comme une
   1.184          série incrémentale de modifications faites à un
   1.185 -        <quote>snapshot</quote>. (Certains basent le snapshot sur la plus
   1.186 +        <quote>snapshot</quote>. (Certains basent le <quote>snapshot</quote> sur la plus
   1.187          vieille révision, d'autres sur la plus récente.) Pour reconstruire
   1.188 -        une révision spécifique, vous devez d'abord lire le snapshot, et
   1.189 -        ensuite toutes les révisions entre le snapshot et votre révision
   1.190 +        une révision spécifique, vous devez d'abord lire le <quote>snapshot</quote>, et
   1.191 +        ensuite toutes les révisions entre le <quote>snapshot</quote> et votre révision
   1.192          cible. Plus vous avez d'historique accumulé dans un fichier, plus de
   1.193          révisions vous avez à lire, d'où la longueur que cela prend à
   1.194          reconstruire une révision particulière.</para>
   1.195  
   1.196        <figure id="fig:concepts:snapshot">
   1.197 -        <title>Snapshot d'un revlog, avec des deltas incrémentaux</title>
   1.198 +          <title><quote>Snapshot</quote> d'un <quote>revlog</quote>, avec des deltas incrémentaux</title>
   1.199          <mediaobject> <imageobject><imagedata
   1.200                fileref="figs/snapshot.png"/></imageobject>
   1.201            <textobject><phrase>XXX add text</phrase></textobject>
   1.202 @@ -195,15 +195,15 @@
   1.203        <para id="x_2fc">L'inovation que Mercurial apporte à ce problème est
   1.204          simple mais effective. Une fois que la quantité cumulée de deltas
   1.205          d'informations stockées depuis le dernier snapshot excède un seuil
   1.206 -        fixé, il stock un nouveau snapshot (compréssé biensûr), plutôt qu'un
   1.207 +        fixé, il stocke un nouveau <quote>snapshot</quote> (compressé bien sûr), plutôt qu'un
   1.208          nouveau delta. Ceci rend possible la reconstruction de
   1.209          <emphasis>toute</emphasis> révision d'un fichier rapidement. Cette
   1.210          approche fonctionne si bien que depuis, elle a été copiée par
   1.211          plusieurs autres systèmes de gestion de révisions.</para>
   1.212  
   1.213        <para id="x_2fd"><xref linkend="fig:concepts:snapshot"/> illustre
   1.214 -        l'idée. Dans une entrée d'un fichier d'index de revlog, Mercurial
   1.215 -        stock l'intervale des entrées depuis le fichier de données qu'il doit
   1.216 +          l'idée. Dans une entrée d'un fichier d'index de <quote>revlog</quote>, Mercurial
   1.217 +        stocke l'intervalle des entrées depuis le fichier de données qu'il doit
   1.218          lire pour reconstruire une révision particulière.</para>
   1.219  
   1.220        <sect3>
   1.221 @@ -232,57 +232,57 @@
   1.222  
   1.223        <para id="x_301">Les hash fournissent plus qu'un bon moyen de
   1.224          vérification contre la corruption ; il sont aussi utilisés comme
   1.225 -        identifiants pour les révisions. Le hash d'identification d'un
   1.226 -        changeset que vous voyez comme utilisateur final proviennent des
   1.227 -        révisions du changelog. Bien que les filelogs et le manifest
   1.228 -        utilisent aussi des hash, Mercurial ne les utilise qu'en arrière
   1.229 +        identifiants pour les révisions. Les <quote>hashs</quote> d'identifications d'un
   1.230 +        <quote>changeset</quote> que vous voyez comme utilisateur final proviennent des
   1.231 +        révisions du <quote>changelog</quote>. Bien que les <quote>filelogs</quote> et le <quote>manifest</quote>
   1.232 +        utilisent aussi des <quote>hashs</quote>, Mercurial ne les utilise qu'en arrière
   1.233          plan.</para>
   1.234  
   1.235 -      <para id="x_302">Mercurial vérifie que les hash sont corrects lorsqu'il
   1.236 +    <para id="x_302">Mercurial vérifie que les <quote>hashs</quote> sont corrects lorsqu'il
   1.237          récupère les révisions de fichiers et lorsqu'il récupère (pull) les
   1.238          changements d'un autre dépôt. S'il rencontre un problème d'intégrité,
   1.239 -        il se pleindra et arrêtera tout ce qu'il est en train de faire.</para>
   1.240 +        il se plaindra et arrêtera tout ce qu'il est en train de faire.</para>
   1.241  
   1.242        <para id="x_303">En plus de l'effet qu'il a sur l'efficacité des
   1.243 -        récupérations, l'utilisation de Mercurial de snapshots périodiques
   1.244 +          récupérations, l'utilisation par Mercurial de <quote>snapshots</quote> périodiques
   1.245          fait qu'il est plus robuste contre la corruption partielle de
   1.246 -        données. Si un revlog devient partiellement corrompu à cause d'une
   1.247 +        données. Si un <quote>revlog</quote> devient partiellement corrompu à cause d'une
   1.248          erreur matérielle ou d'un bug système, il est souvent possible de
   1.249          reconstruire certaines ou la plupart des révisions à partir des
   1.250 -        sections non corrompues du revlog, avant et après la section
   1.251 +        sections non corrompues du <quote>revlog</quote>, avant et après la section
   1.252          corrompue. Ceci ne serait pas possible à partir d'un modèle de
   1.253 -        stockage delta seul.</para>
   1.254 +        stockage de deltas seul.</para>
   1.255      </sect2>
   1.256    </sect1>
   1.257  
   1.258    <sect1>
   1.259      <title>Historique des révisions, branches et fusions (merge)</title>
   1.260  
   1.261 -    <para id="x_304">Chaque entrée dans un revlog Mercurial connaît
   1.262 -      l'identité de l'ancètre immédiat de la révision, habituellement référé
   1.263 +    <para id="x_304">Chaque entrée dans un <quote>revlog</quote> Mercurial connaît
   1.264 +      l'identité de l'ancêtre immédiat de la révision, habituellement désignée
   1.265        comme son <emphasis>parent</emphasis>. En fait, une révision contient
   1.266        de la place pour non pas un parent, mais deux. Mercurial utilise un
   1.267 -      hash spécial, appelé le <quote>null ID</quote> pour représenter l'idée
   1.268 -      qu'<quote>il n'y a pas de parent ici</quote>. Ce hash est simplement
   1.269 +      <quote>hash</quote> spécial, appelé le <quote>null ID</quote> pour représenter l'idée
   1.270 +      qu'<quote>il n'y a pas de parent ici</quote>. Ce <quote>hash</quote> est simplement
   1.271        une chaîne de zéros.</para>
   1.272  
   1.273      <para id="x_305">Dans <xref linkend="fig:concepts:revlog"/>, vous pouvez
   1.274 -      voir un exemple de la structure conceptuelle d'un revlog. Les filelogs,
   1.275 -      manifests et changelogs ont tous cette même structure ; ils difèrent
   1.276 +        voir un exemple de la structure conceptuelle d'un <quote>revlog</quote>. Les <quote>filelogs</quote>,
   1.277 +        <quote>manifests</quote> et <quote>changelogs</quote> ont tous cette même structure ; ils diffèrent
   1.278        simplement dans le type de donnée stockée dans chaque delta ou
   1.279 -      snapshot.</para>
   1.280 -
   1.281 -    <para id="x_306">La première révision d'un revlog (au bas de l'image) a
   1.282 -      le null ID dans chacune de ses cases parent. Pour une révision
   1.283 +      <quote>snapshot</quote>.</para>
   1.284 +
   1.285 +  <para id="x_306">La première révision d'un <quote>revlog</quote> (au bas de l'image) a
   1.286 +      le <quote>null ID</quote> dans chacune de ses cases parent. Pour une révision
   1.287        <quote>normale</quote>, sa première case parent contient l'ID de sa
   1.288 -      révision parent et la seconde contient le null ID, indiquant que cette
   1.289 +      révision parent et la seconde contient le <quote>null ID</quote>, indiquant que cette
   1.290        révision n'a qu'un seul vrai parent. Si deux révisions ont le même
   1.291        parent, il s'agit de branches. Une révision qui représente une fusion
   1.292        (merge) entre deux branches a deux identifiants de révision normaux
   1.293        dans ses cases parents.</para>
   1.294  
   1.295      <figure id="fig:concepts:revlog">
   1.296 -      <title>The conceptual structure of a revlog</title>
   1.297 +        <title>Le concept de la structure d'un <quote>revlog</quote></title>
   1.298        <mediaobject> <imageobject><imagedata
   1.299              fileref="figs/revlog.png"/></imageobject> <textobject><phrase>XXX
   1.300              add text</phrase></textobject>
   1.301 @@ -293,48 +293,48 @@
   1.302    <sect1>
   1.303      <title>Le répertoire de travail</title>
   1.304  
   1.305 -    <para id="x_307">Dans un répertoire de travail, Mercurial stock une image
   1.306 -      des fichiers du dépôt à un changeset particulier.</para>
   1.307 +    <para id="x_307">Dans un répertoire de travail, Mercurial stocke une image
   1.308 +        des fichiers du dépôt à un <quote>changeset</quote> particulier.</para>
   1.309  
   1.310      <para id="x_308">Le répertoire de travail <quote>sait</quote> quel
   1.311 -      changeset il contient. Lorsque vous mettez à jour (update) le
   1.312 -      répertoire de travail à un certain changeset, Mercurial regarde la
   1.313 -      révision appropriée du manifest pour trouver quels fichier il suivait
   1.314 -      au moment où le changeset a été committé, et quelle révision de chaque
   1.315 +        <quote>changeset</quote> il contient. Lorsque vous mettez à jour (update) le
   1.316 +        répertoire de travail à un certain <quote>changeset</quote>, Mercurial regarde la
   1.317 +        révision appropriée du <quote>manifest</quote> pour trouver quels fichiers il suivait
   1.318 +        au moment où le <quote>changeset</quote> a été <quote>committé</quote>, et quelle révision de chaque
   1.319        fichier était alors courante. Il recrée ensuite une copie de chacun de
   1.320 -      ces fichiers, avec le même contenu qu'ils avaient lorsque le changeset
   1.321 -      a été committé.</para>
   1.322 +      ces fichiers, avec le même contenu qu'ils avaient lorsque le <quote>changeset</quote>
   1.323 +      a été <quote>committé</quote>.</para>
   1.324  
   1.325      <para id="x_309">La structure spéciale <emphasis>dirstate</emphasis>
   1.326        contient la connaissance de Mercurial sur le répertoire de travail.
   1.327        Elle est maintenue par un fichier appelé
   1.328        <filename>.hg/dirstate</filename> dans un dépôt. Les détails du
   1.329 -      dirstate sont le changeset vers lequel le répertoire de travail se met
   1.330 +      dirstate sont le <quote>changeset</quote> vers lequel le répertoire de travail se met
   1.331        à jour (update), et tous les fichiers que Mercurial suit dans le
   1.332 -      répertoire de travail. Il permet aussi à Mercurial se connaître
   1.333 -      rapidement les fichiers modifiés, en enregistrant leurs heures de
   1.334 -      dernière modification et leur taille.</para>
   1.335 -
   1.336 -    <para id="x_30a">Puisqu'une révision de revlog a des emplacements pour
   1.337 +      répertoire de travail. Il permet aussi à Mercurial de connaître
   1.338 +      rapidement les fichiers modifiés, en enregistrant l'heure de
   1.339 +      dernière modification et la taille de chacun.</para>
   1.340 +
   1.341 +  <para id="x_30a">Puisqu'une révision de <quote>revlog</quote> a des emplacements pour
   1.342        deux parents et peut représenter aussi bien une révision normale (avec
   1.343 -      un parent) ou une fusion de deux révisions anciennes, le dirstate a des
   1.344 +      un parent) ou une fusion de deux révisions anciennes, le <quote>dirstate</quote> a des
   1.345        emplacements pour deux parents. Lorsque vous utilisez la commande
   1.346 -      <command role="hg-cmd">hg update</command>, le changeset que vous
   1.347 +      <command role="hg-cmd">hg update</command>, le <quote>changeset</quote> que vous
   1.348        mettez à jour est stocké dans l'emplacement du <quote>premier
   1.349 -        parent</quote>, et le null ID l'est dans le second. Lorsque vous
   1.350 +          parent</quote>, et le <quote>null ID</quote> l'est dans le second. Lorsque vous
   1.351        utilisez la commande <command role="hg-cmd">hg merge</command> avec un
   1.352        autre changeset, le premier parent reste inchangé, et le second est
   1.353 -      rempli avec le changeset à partir duquel vous êtes en train de
   1.354 +      rempli avec le <quote>changeset</quote> à partir duquel vous êtes en train de
   1.355        fusionner. La commande <command role="hg-cmd">hg parents</command> vous
   1.356        donne les parents du dirstate.</para>
   1.357  
   1.358      <sect2>
   1.359 -      <title>Que se passe-t-il lorsque vous committez</title>
   1.360 -
   1.361 -      <para id="x_30b">Le dirstate stock les informations sur les parents
   1.362 -        pour plusqu'un simple livre de stockage. Mercurial utilise les
   1.363 -        parents du distate comme <emphasis>les parents d'un nouveau
   1.364 -          changeset</emphasis> lorsque vous committez.</para>
   1.365 +        <title>Que se passe-t'il lorsque vous <quote>committez</quote></title>
   1.366 +
   1.367 +        <para id="x_30b">Le <quote>dirstate</quote> stocke les informations sur les parents
   1.368 +        pour plus qu'un simple livre de stockage. Mercurial utilise les
   1.369 +        parents du <quote>distate</quote> comme <emphasis>les parents d'un nouveau
   1.370 +            <quote>changeset</quote></emphasis> lorsque vous <quote>committez</quote>.</para>
   1.371  
   1.372        <figure id="fig:concepts:wdir"> 
   1.373          <title>Le répertoire de travail peut avoir deux parents</title>
   1.374 @@ -344,13 +344,13 @@
   1.375        </figure>
   1.376  
   1.377        <para id="x_30d"><xref linkend="fig:concepts:wdir"/> montre l'état
   1.378 -        normal d'un répertoire de travail, où il n'y a qu'un seul changeset
   1.379 -        comme parent. Ce changeset est le <emphasis>tip</emphasis>, le
   1.380 -        changeset le plus récent dans le dépôt n'a pas d'enfant.</para>
   1.381 +          normal d'un répertoire de travail, où il n'y a qu'un seul <quote>changeset</quote>
   1.382 +          comme parent. Ce <quote>changeset</quote> est le <emphasis>tip</emphasis>, le
   1.383 +          <quote>changeset</quote> le plus récent dans le dépôt n'a pas d'enfant.</para>
   1.384  
   1.385        <figure id="fig:concepts:wdir-after-commit">
   1.386          <title>Le répertoire de travail gagne de nouveaux parents après un
   1.387 -        commit</title>
   1.388 +            <quote>commit</quote></title>
   1.389          <mediaobject>
   1.390            <imageobject><imagedata
   1.391                fileref="figs/wdir-after-commit.png"/></imageobject>
   1.392 @@ -358,19 +358,19 @@
   1.393          </mediaobject>
   1.394        </figure>
   1.395  
   1.396 -      <para id="x_30f">Il est utile de penser du répertoire de travail qu'il
   1.397 -        est <quote>le changeset que je vais committer</quote>. Chaque fichier
   1.398 -        que vous dites à mercurial d'ajouter, de supprimer, de renommer ou de
   1.399 -        copier va être reflété dasn ce changeset, tout comme les
   1.400 +      <para id="x_30f">On peut se représenter le répertoire de travail comme
   1.401 +        <quote>le changeset que je vais committer</quote>. Chaque fichier
   1.402 +        que vous demandez à Mercurial d'ajouter, de supprimer, de renommer ou de
   1.403 +        copier va être intégré dans ce changeset, tout comme les
   1.404          modifications de n'importe quel fichier que Mercurial est déjà en
   1.405 -        train de suite ; le nouveau changeset aura les mêmes parents que le
   1.406 +        train de suivre ; le nouveau <quote>changeset</quote> aura les mêmes parents que le
   1.407          répertoire de travail.</para>
   1.408  
   1.409        <para id="x_310">Après un commit, Mercurial va mettre à jour les
   1.410 -        parents du répertoire de travail, ainsi, le premier parents est l'ID
   1.411 -        du nouveau changeset, et le second, le nullID. Ceci est illustré dans
   1.412 +        parents du répertoire de travail, ainsi, le premier parent est l'ID
   1.413 +        du nouveau <quote>changeset</quote>, et le second, le <quote>null ID</quote>. Ceci est illustré dans
   1.414          <xref linkend="fig:concepts:wdir-after-commit"/>. Mercurial ne touche
   1.415 -        à aucun des fichiers du répertoire de travail lorsque vous committez
   1.416 +        à aucun des fichiers du répertoire de travail lorsque vous <quote>committez</quote>
   1.417          ; il modifie simplement le dirstate pour noter ses nouveaux
   1.418          parents.</para>
   1.419  
   1.420 @@ -378,19 +378,19 @@
   1.421      <sect2>
   1.422        <title>Création d'une nouvelle <quote>head</quote></title>
   1.423  
   1.424 -      <para id="x_311">Il est parfaitement normal de faire un update du
   1.425 -        répertoire de travail à un changeset autre que le tip courant. Par
   1.426 -        exemple, vous pourriez vouloir savoir ce à quoi votre projet
   1.427 -        ressemblait le dernier Mardi, ou regarder le changeset qui a
   1.428 +      <para id="x_311">Il est parfaitement normal de faire un <quote>update</quote> du
   1.429 +          répertoire de travail à un <quote>changeset</quote> autre que le <quote>tip</quote> courant. Par
   1.430 +        exemple, vous pourriez vouloir savoir à quoi votre projet
   1.431 +        ressemblait mardi dernier, ou regarder le <quote>changeset</quote> qui a
   1.432          introduit un bug. Dans des cas comme ça, la chose naturelle à faire
   1.433 -        est de faire un update du répertoire de travail au changeset qui vous
   1.434 +        est de faire un <quote>update</quote> du répertoire de travail au <quote>changeset</quote> qui vous
   1.435          intéresse, et ensuite d'en examiner les fichiers pour regarder leurs
   1.436 -        contenus comme ils l'étaient lorsque vous avez commité ce changeset.
   1.437 +        contenus comme ils l'étaient lorsque vous avez <quote>commité</quote> ce <quote>changeset</quote>.
   1.438          L'effet de ceci est montré dans <xref
   1.439            linkend="fig:concepts:wdir-pre-branch"/>.</para>
   1.440  
   1.441        <figure id="fig:concepts:wdir-pre-branch">
   1.442 -        <title>Le répertoire de travail, "updaté" pour un changeset plus
   1.443 +          <title>Le répertoire de travail, <quote>updaté</quote> pour un <quote>changeset</quote> plus
   1.444          ancien</title>
   1.445          <mediaobject> <imageobject><imagedata
   1.446                fileref="figs/wdir-pre-branch.png"/></imageobject>
   1.447 @@ -398,19 +398,19 @@
   1.448          </mediaobject>
   1.449        </figure>
   1.450  
   1.451 -      <para id="x_313">En ayant fait un update du répertoire de travail vers
   1.452 -        un changeset plus ancien, qu'est-ce qu'il se passe si vous faites des
   1.453 -        changements et ensuite committez ? Mercurial se comporte comme je
   1.454 +      <para id="x_313">En ayant fait un <quote>update</quote> du répertoire de travail vers
   1.455 +          un <quote>changeset</quote> plus ancien, que se passe-t'il si vous faites des
   1.456 +          changements et ensuite <quote>committez</quote> ? Mercurial se comporte comme je
   1.457          l'ai fait remarqué plus haut. Les parents du répertoire de travail
   1.458 -        deviennent les parents du nouveau changeset. Ce nouveau changeset n'a
   1.459 -        pas d'enfant, donc il devient le nouveau tip. Le dépôt contient
   1.460 -        maintenant deux changesets qui n'ont pas d'enfant ; on appelle ceci
   1.461 -        des <emphasis>heads</emphasis>. Vous pouvez voir la structire que
   1.462 +        deviennent les parents du nouveau <quote>changeset</quote>. Ce nouveau <quote>changeset</quote> n'a
   1.463 +        pas d'enfant, donc il devient le nouveau <quote>tip</quote>. Le dépôt contient
   1.464 +        maintenant deux <quote>changesets</quote> qui n'ont pas d'enfant ; on appelle ceci
   1.465 +        des <emphasis>heads</emphasis>. Vous pouvez voir la structure que
   1.466          cela crée dans <xref linkend="fig:concepts:wdir-branch"/>.</para>
   1.467  
   1.468        <figure id="fig:concepts:wdir-branch">
   1.469 -        <title>Après un commit fait pendant la synchronisation avec un ancien
   1.470 -        changeset</title>
   1.471 +          <title>Après un <quote>commit</quote> fait pendant la synchronisation avec un ancien
   1.472 +              <quote>changeset</quote></title>
   1.473          <mediaobject> <imageobject><imagedata
   1.474                fileref="figs/wdir-branch.png"/></imageobject>
   1.475            <textobject><phrase>XXX add text</phrase></textobject>
   1.476 @@ -422,19 +422,19 @@
   1.477            à l'esprit une <quote>erreur</quote> commune, qui est d'utiliser la
   1.478            commande <command role="hg-cmd">hg pull</command> sans aucune
   1.479            option. Par défaut, la commande <command role="hg-cmd">hg
   1.480 -            pull</command> <emphasis>ne fait pas</emphasis> d'update sur le
   1.481 +              pull</command> <emphasis>ne fait pas</emphasis> d'<quote>update</quote> sur le
   1.482            répertoire de travail, ainsi, vous allez récupérer les nouveaux
   1.483            changesets dans votre dépôt, mais le répertoire de travail va
   1.484 -          rester synchroniser au même changeset qu'il l'était avant le pull.
   1.485 -          Si vous faites des changements et committez ensuite, vous allez
   1.486 -          créer une nouvelle head puisque votre répertoire de travail n'est
   1.487 -          pas synchronisé à ce que le tip actuel est. Pour combiner les
   1.488 -          opérations d'un pull suivi d'un update, exécutez run <command>hg
   1.489 +          rester synchronisé au même <quote>changeset</quote> qu'il l'était avant le <quote>pull</quote>.
   1.490 +          Si vous faites des changements et <quote>committez</quote> ensuite, vous allez
   1.491 +          créer une nouvelle <quote>head</quote> puisque votre répertoire de travail n'est
   1.492 +          pas synchronisé au <quote>tip</quote> actuel. Pour combiner les
   1.493 +          opérations d'un <quote>pull</quote> suivi d'un <quote>update</quote>, exécutez <command>hg
   1.494              pull -u</command>.</para>
   1.495        
   1.496          <para id="x_316">Je place le mot <quote>erreur</quote> entre
   1.497            guillemets parce que tous ce dont vous avez besoin de faire pour
   1.498 -          rectifier la situation où vous avez créé une nouvelle head par
   1.499 +          rectifier la situation où vous avez créé une nouvelle <quote>head</quote> par
   1.500            accident est un <command role="hg-cmd">hg merge</command> suivi
   1.501            d'un <command role="hg-cmd">hg commit</command>.  En d'autres mots,
   1.502            ceci n'a presque jamais de conséquences négatives ; il s'agit juste
   1.503 @@ -450,11 +450,11 @@
   1.504        <para id="x_317">Lorsque vous exécutez la commande <command
   1.505            role="hg-cmd">hg merge</command>, Mercurial laisse le premier
   1.506          parent du répertoire de travail inchangé et fixe le second au
   1.507 -        changeset avec lequel vous fusionnez (merge), comme montré dans <xref
   1.508 +        <quote>changeset</quote> avec lequel vous fusionnez (merge), comme montré dans <xref
   1.509            linkend="fig:concepts:wdir-merge"/>.</para>
   1.510  
   1.511        <figure id="fig:concepts:wdir-merge">
   1.512 -        <title>Fusionner (merge) deux heads</title>
   1.513 +          <title>Fusionner (merge) deux <quote>heads</quote></title>
   1.514          <mediaobject>
   1.515            <imageobject> <imagedata fileref="figs/wdir-merge.png"/>
   1.516          </imageobject> <textobject><phrase>XXX add text</phrase></textobject>
   1.517 @@ -462,28 +462,28 @@
   1.518        </figure>
   1.519  
   1.520        <para id="x_319">Mercurial doit aussi modifier le répertoire de
   1.521 -        travail pour fusionner les fichiers gérés dans les deux changesets.
   1.522 +          travail pour fusionner les fichiers gérés dans les deux <quote>changesets</quote>.
   1.523          Un peu simplifié, le processus de fusion fonctionne comme ça : pour
   1.524 -        chaque fichier dans le manifest de chaque changeset.</para>
   1.525 +        chaque fichier dans le <quote>manifest</quote> de chaque <quote>changeset</quote>.</para>
   1.526  
   1.527        <itemizedlist>
   1.528 -        <listitem><para id="x_31a">Si aucun changeset n'a modifié un fichier,
   1.529 +          <listitem><para id="x_31a">Si aucun <quote>changeset</quote> n'a modifié un fichier,
   1.530              ne rien faire avec ce fichier.</para> </listitem>
   1.531 -        <listitem><para id="x_31b">Si un changeset a modifié un fichier et
   1.532 +    <listitem><para id="x_31b">Si un <quote>changeset</quote> a modifié un fichier et
   1.533              que l'autre ne l'a pas fait, créer une copie modifiée du fichier
   1.534              dans le répertoire de travail.</para> </listitem>
   1.535 -        <listitem><para id="x_31c">Si un changeset a modifié un fichier, et
   1.536 +    <listitem><para id="x_31c">Si un <quote>changeset</quote> a modifié un fichier, et
   1.537              que l'autre ne l'a pas fait (ou l'a supprimé), supprimer le
   1.538              fichier du répertoire de travail.</para> </listitem>
   1.539 -        <listitem><para id="x_31d">Si un changeset a supprimé un fichier,
   1.540 +    <listitem><para id="x_31d">Si un <quote>changeset</quote> a supprimé un fichier,
   1.541              mais que l'autre a modifié le fichier, demander à l'utilisateur
   1.542              quoi faire : garder le fichier modifié ou le supprimer ?</para>
   1.543          </listitem>
   1.544 -        <listitem><para id="x_31e">Si chacun des chengeset a modifié un
   1.545 +        <listitem><para id="x_31e">Si chacun des <quote>changeset</quote> a modifié un
   1.546              fichier, invoquer le programme externe de fusion pour choisir les
   1.547              nouveaux contenus pour le fichier fusionné. Ceci peut demander
   1.548              des entrées de l'utilisateur.</para></listitem>
   1.549 -        <listitem><para id="x_31f">Si un changeset a modifié un fichier, et
   1.550 +    <listitem><para id="x_31f">Si un <quote>changeset</quote> a modifié un fichier, et
   1.551              que l'autre a renommé ou copié le fichier, être sûr que les
   1.552              changements suivent le nouveau nom du fichier.</para></listitem>
   1.553        </itemizedlist>
   1.554 @@ -496,22 +496,22 @@
   1.555          besoin d'entrées pour résoudre un conflit.</para>
   1.556  
   1.557        <para id="x_321">Lorsque vous pensez à ce qu'il se passe lorsque vous
   1.558 -        committez après un merge, une fois encore, le répertoire de travail
   1.559 +          <quote>committez</quote> après un <quote>merge</quote>, une fois encore, le répertoire de travail
   1.560          est <quote>le changeset que je suis sur le point de
   1.561            committer</quote>. Après que la commande <command role="hg-cmd">hg
   1.562            merge</command> ait terminé, le répertoire de travail a deux
   1.563          parents ; ceux ci vont devenir les parents du nouveau
   1.564 -        changeset.</para>
   1.565 +        <quote>changeset</quote>.</para>
   1.566  
   1.567        <para id="x_322">Mercurial vous permet d'exécuter de multiples fusions,
   1.568 -        mais vous devez committer le résultat de chaque fusion individuelle
   1.569 -        comme vous avancez. Ceci est nécessaire puisque Mercurial ne stock
   1.570 +          mais vous devez <quote>committer</quote> le résultat de chaque fusion individuellement
   1.571 +        au fur et à mesure. Ceci est nécessaire puisque Mercurial ne stocke
   1.572          que deux parents pour chaque révision et le répertoire de travail.
   1.573 -        Alors qu'il serait techniquement faisble de fusionner de multiples
   1.574 -        changesets en même temps, Mercurial interdit cette simplicité. Avec
   1.575 -        des fusions multplus, les risques de confision utilisateur, de
   1.576 -        conflits néfastes de résolutions, et faire une pagaille d'une fusion
   1.577 -        grossiraient intollérablement.</para>
   1.578 +        Alors qu'il serait techniquement faisable de fusionner de multiples
   1.579 +        <quote>changesets</quote> en même temps, Mercurial interdit cette simplicité. Avec
   1.580 +        des fusions multiples, les risques de confusion pour l'utilisateur, de
   1.581 +        conflits de résolutions, et de pagaille dans les fusions
   1.582 +        augmenteraient de façon Intolérable.</para>
   1.583  
   1.584      </sect2>
   1.585  
   1.586 @@ -519,17 +519,17 @@
   1.587        <title>Fusions et renommages</title>
   1.588  
   1.589        <para id="x_69a">Un nombre surprenant de systèmes de gestion de
   1.590 -        révision fait peu ou pas attention à un <emphasis>nom</emphasis> au
   1.591 +        révisions fait peu ou pas attention à un <emphasis>nom</emphasis> au
   1.592          cours du temps. Par exemple, il était habituel que si un fichier
   1.593          était renommé d'un coté de la fusion, les changements à partir de
   1.594          l'autre coté étaient supprimés silencieusement.</para>
   1.595  
   1.596        <para id="x_69b">Mercurial enregistre les metadata lorsque vous lui
   1.597 -        dite d'exécuter un renommage ou une copie. Il utilise ces metadata
   1.598 +        dite d'exécuter un renommage ou une copie. Il utilise ces metadatas
   1.599          durant une fusion pour faire les bonnes choses dans le cas d'un
   1.600 -        merge. Par exemple, si je renomme un fichier et que vous l'éditez
   1.601 +        <quote>merge</quote>. Par exemple, si je renomme un fichier et que vous l'éditez
   1.602          sans le renommer, lorsque l'on fusionne, le fichier sera renommé et
   1.603 -        aura les éditions appliquées.</para>
   1.604 +        aura les changements appliqués.</para>
   1.605  
   1.606      </sect2>
   1.607    </sect1>
   1.608 @@ -537,24 +537,24 @@
   1.609    <sect1>
   1.610      <title>D'autres fonctionnalités intéressantes</title>
   1.611  
   1.612 -    <para id="x_323">Dans les sections au dessus, j'ai tenté de mettre
   1.613 +    <para id="x_323">Dans les sections au-dessus, j'ai tenté de mettre
   1.614        l'accent sur certains aspects importants du design de Mercurial pour
   1.615        illustrer l'attention particulière qui a été portée à la fiabilité et à
   1.616 -      la performance.Cependant, l'attention aux détails ne s'arrête pas ici.
   1.617 +      la performance. Cependant, l'attention aux détails ne s'arrête pas ici.
   1.618        Il y a de nombreux aspects sur la construction de Mercurial que je
   1.619 -      trouve personnellement intéressante. Je détaillerai quelques un d'eux
   1.620 -      ici, séparément des éléments du <quote>big ticket</quote> ci dessus,
   1.621 +      trouve personnellement intéressante. J'en détaillerai quelques-uns 
   1.622 +      ici, séparément des éléments du <quote>big ticket</quote> ci-dessus,
   1.623        ainsi, si vous êtes intéressés, vous pourrez avoir une meilleure idée
   1.624 -      de la quantité de pensées qu'il y a derrière un système bien
   1.625 -      défini.</para>
   1.626 +      de la quantité d'ingéniosité qu'il y a derrière un système bien
   1.627 +      conçu.</para>
   1.628  
   1.629      <sect2>
   1.630        <title>Compression élégante</title>
   1.631  
   1.632        <para id="x_324">Lorsque cela est approprié, Mercurial stocke les
   1.633 -        snapshots et deltas sous une forme compressée. Il le fait en
   1.634 -        <emphasis>essayant</emphasis> toujours de compression un snapshot ou
   1.635 -        un delta, mais en ne stockant la version compression que si celle ci
   1.636 +          <quote>snapshots</quote> et deltas sous une forme compressée. Il le fait en
   1.637 +          <emphasis>essayant</emphasis> toujours de compresser un <quote>snapshot</quote> ou
   1.638 +        un delta, mais en ne stockant la version compressée que si celle-ci
   1.639          est plus petite que la version non compressée.</para>
   1.640  
   1.641        <para id="x_325">Ceci signifie que Mercurial fait <quote>la bonne
   1.642 @@ -569,8 +569,8 @@
   1.643          sont habituellement plus gros que les snapshots du fichier, et
   1.644          Mercurial fait à nouveau <quote>la bonne chose</quote> dans ces cas.
   1.645          Il trouve qu'un delta dépasse le seuil auquel il devrait stocker un
   1.646 -        snapshot complet du ficheir, alors il stocke le snapshot, en gagnant
   1.647 -        encore de la place en comparaison à une approche naïve delta
   1.648 +        <quote>snapshot</quote> complet du fichier, alors il stocke le <quote>snapshot</quote>, en gagnant
   1.649 +        encore de la place en comparaison d'une approche naïve avec un delta
   1.650          seulement.</quote>
   1.651  
   1.652        <sect3>
   1.653 @@ -580,29 +580,29 @@
   1.654            Mercurial utilise l'algorithme de compression
   1.655            <quote>deflate</quote> (le même que celui utilisé pour le format
   1.656            d'archive populaire <literal>zip</literal>), qui est un bon
   1.657 -          comprimis entre la vitesse et le taux de compression. Cependant,
   1.658 +          compromis entre la vitesse et le taux de compression. Cependant,
   1.659            lors de la transmission d'une révision de données par une connexion
   1.660            réseau, Mercurial décompresse les données de révision
   1.661            compressées.</para>
   1.662        
   1.663 -        <para id="x_328">Si la connexion est au dessus de HTTP, mercurial
   1.664 +        <para id="x_328">Si la connexion passe par HTTP, Mercurial
   1.665            recompresse le flux entier de données en utilisant un algorithme de
   1.666            compression qui donne un meilleur taux de compression (l'algorithme
   1.667 -          Burrows-Wheeler utilisé principalement par le package de
   1.668 +          Burrows-Wheeler utilisé principalement par le logiciel de
   1.669            compression <literal>bzip2</literal>). Cette combinaison de
   1.670            l'algorithme et de compression du flux entier (plutôt que pour une
   1.671 -          révision à la fois) réduit substanciellement le nombre de bits qui
   1.672 -          sont transférés, résultant dans une performance réseau accrue sur
   1.673 +          révision à la fois) réduit substantiellement le nombre de bits qui
   1.674 +          sont transférés, résultant en une performance réseau accrue sur
   1.675            la plupart des supports.</para>
   1.676        
   1.677 -        <para id="x_329">Si la connexion est au dessus de
   1.678 +        <para id="x_329">Si la connexion passe par
   1.679            <command>ssh</command>, Mercurial <emphasis>ne</emphasis>
   1.680            recompresse <emphasis>pas</emphasis> le flux puisque
   1.681            <command>ssh</command> peut déjà le faire par lui même. Vous pouvez
   1.682            demander à Mercurial de toujours utiliser la compression
   1.683            <command>ssh</command> en éditant le fichier
   1.684 -          <filename>.hgrc</filename> de votre répertoire personnale comme ci
   1.685 -          dessous.</para>
   1.686 +          <filename>.hgrc</filename> de votre répertoire personnel comme ci-dessous.
   1.687 +      </para>
   1.688        
   1.689          <programlisting>[ui]
   1.690  ssh = ssh -C</programlisting>
   1.691 @@ -612,76 +612,76 @@
   1.692      <sect2>
   1.693        <title>Ordres de Lecture/Écriture et atomicité</title>
   1.694  
   1.695 -      <para id="x_32a">Ajouter à la fin des fichiers n'est pas toute
   1.696 -        l'histoire lorsque l'on cherche à garantir que le lecteur ne verra
   1.697 +      <para id="x_32a">L'histoire ne se résume pas à ajouter à la fin des fichiers
   1.698 +        lorsque l'on cherche à garantir que le lecteur ne verra
   1.699          pas qu'une écriture partielle. Si vous relisez <xref
   1.700 -          linkend="fig:concepts:metadata"/>, les révisions dans le changelog
   1.701 -        pointent vers les révisions dans le manifest, et les révisions du
   1.702 -        manifest pointent vers les révisions du filelog. Cette hiérarchie est
   1.703 +            linkend="fig:concepts:metadata"/>, les révisions dans le <quote>changelog</quote>
   1.704 +        pointent vers les révisions dans le <quote>manifest</quote>, et les révisions du
   1.705 +        <quote>manifest</quote> pointent vers les révisions du <quote>filelog</quote>. Cette hiérarchie est
   1.706          délibérée.</para>
   1.707  
   1.708 -      <para id="x_32b">L'écriture commence une transaction en écrivant dans
   1.709 -        le filelog et dans les données du manifest, et n'écrit aucune donnée
   1.710 -        changelog tant que ce n'est pas terminé. La lecture commence en
   1.711 -        lisant les données du changelog, puis les données du manifest, et
   1.712 -        enfin les données du filelog.</para>
   1.713 +      <para id="x_32b">L'écriture commence par une transaction en écrivant dans
   1.714 +          le <quote>filelog</quote> et dans les données du <quote>manifest</quote>, et n'écrit aucune donnée
   1.715 +        du  <quote>changelog</quote> tant que ce n'est pas terminé. La lecture commence en
   1.716 +        lisant les données du <quote>changelog</quote>, puis les données du <quote>manifest</quote>, et
   1.717 +        enfin les données du <quote>filelog</quote>.</para>
   1.718  
   1.719        <para id="x_32c">Puisque que l'écriture ne finit pas d'écrire les
   1.720 -        données du filelog et du manifest avant d'écrire dans le changelog,
   1.721 -        la lecture ne verra jamais un pointeur vers une révision du manifest
   1.722 -        partiellement écrite à partir du changelog, et ne lira jamais un
   1.723 -        pointeur vers une révision du filelog partiellement écrite dans le
   1.724 -        manifest.</para>
   1.725 +          données du <quote>filelog</quote> et du <quote>manifest</quote> avant d'écrire dans le <quote>changelog</quote>,
   1.726 +          la lecture ne verra jamais un pointeur vers une révision du <quote>manifest</quote>
   1.727 +          partiellement écrite à partir du <quote>changelog</quote>, et ne lira jamais un
   1.728 +          pointeur vers une révision du <quote>filelog</quote> partiellement écrite dans le
   1.729 +          <quote>manifest</quote>.</para>
   1.730  
   1.731      </sect2>
   1.732      <sect2>
   1.733        <title>Accès concurrent</title>
   1.734  
   1.735        <para id="x_32d">La garantie de l'ordre de lecture/écriture et
   1.736 -        de l'atomicite signifie que Mercurial n'a jamais besoin de poser de
   1.737 +        de l'atomicité signifie que Mercurial n'a jamais besoin de poser de
   1.738          <emphasis>lock</emphasis> sur un dépôt lorsqu'il lit des données,
   1.739          même si le dépôt est en train d'être écrit au même moment que la
   1.740 -        lecture a lieue. Ceci a un grand impact sur la fiabilité ; vous
   1.741 +        lecture a lieu. Ceci a un grand impact sur la fiabilité ; vous
   1.742          pouvez avoir un nombre arbitraire de processus Mercurial qui lisent
   1.743 -        dans risque en même temps les données d'un dépôt, peu importe s'il
   1.744 +        sans risque les données d'un dépôt en même temps, peu importe s'il
   1.745          est en train d'être lu ou non.</para>
   1.746  
   1.747        <para id="x_32e">La nature sans <quote>lock</quote> de la lecture
   1.748          signifie que si vous partagez un dépôt sur un système
   1.749          multi-utilisateurs, vous n'avez pas besoin de donner aux autres
   1.750          utilisateurs locaux la permission d'<emphasis>écrire</emphasis> sur
   1.751 -        votre dépôt pour qu'ils soient capable de faire un clone ou un pull
   1.752 +        votre dépôt pour qu'ils soient capable de faire un clone ou un <quote>pull</quote>
   1.753          des changements à partir de celui ci ; ils ont seulement besoin de la
   1.754          permission en <emphasis>lecture</emphasis>. (Il
   1.755          <emphasis>ne</emphasis> s'agit <emphasis>pas</emphasis> d'une
   1.756 -        fonctionnalité commune à travers les systèmes de gestion de révision,
   1.757 -        donc ne prenez pas ça pour garanti ! La plupart ont besoin que les
   1.758 +        fonctionnalité commune à travers les systèmes de gestion de révisions,
   1.759 +        donc ne prenez pas ça pour garantie ! La plupart ont besoin que les
   1.760          lecteurs soient capables de mettre un lock sur le dépôt pour y
   1.761          accéder en toute sécurité, et ceci demande des permissions en
   1.762 -        écriture, sur au moins un dépertoire, ce qui provoque biensûr toutes
   1.763 +        écriture, sur au moins un répertoire, ce qui provoque bien sûr toutes
   1.764          sortes de problèmes néfastes et ennuyants relatifs à la sécurité et à
   1.765          l'administration.)</para>
   1.766  
   1.767 -      <para id="x_32f">Mercurial utilise des locs pour assurer qu'un seul
   1.768 +    <para id="x_32f">Mercurial utilise des <quote>locks</quote> pour assurer qu'un seul
   1.769          processus peut écrire dans le dépôt à un moment donné (le mécanisme
   1.770 -        de lock est sûr, même sur des systèmes de fichiers qui sont connus
   1.771 -        pour être hostiles aux locks, comme NFS). Si un dépôt dispose d'un
   1.772 -        lock, un processus qui cherche à écrire va attendre un peu avant de
   1.773 -        retenter pour voir si le dépôt perd son lock, mais le dépôt garde
   1.774 -        trop longtemps son lock, le processus qui tente d'écrire va expirer
   1.775 -        (time out) après un moment. Celà veut dire par exemple que vous
   1.776 -        scripts lancés quotidiennement n'attendront pas toujours et boucler
   1.777 -        si un système crashait sans avertissement, par exemple. (Oui, le
   1.778 +        de <quote>lock</quote> est sûr, même sur des systèmes de fichiers qui sont connus
   1.779 +        pour être hostiles aux <quote>locks</quote>, comme NFS). Si un dépôt dispose d'un
   1.780 +        <quote>lock</quote>, un processus qui cherche à écrire va attendre un peu avant de
   1.781 +        retenter pour voir si le dépôt perd son <quote>lock</quote>, mais si le dépôt garde
   1.782 +        trop longtemps son <quote>lock</quote>, le processus qui tente d'écrire va expirer
   1.783 +        (time out) après un moment. Cela veut dire par exemple que vos
   1.784 +        scripts lancés quotidiennement n'attendront pas toujours et boucleront
   1.785 +        si un système plantait sans avertissement, par exemple. (Oui, le
   1.786          timeout est configurable, de zéro à l'infini.)</para>
   1.787  
   1.788        <sect3>
   1.789 -	<title>Accès dirstate sûr</title>
   1.790 -
   1.791 -	<para id="x_330">Comme avec les données de révision, Mercurial ne prend pas
   1.792 -    de lock pour lire le fichier dirstate ; il n'acquier pas un lock pour
   1.793 -    y écrire. Pour empécher la possibilité de lire une copie partiellement
   1.794 -    écrite du fichier dirstate, Mercurial écrit à un fichier avec un nom
   1.795 -    unique dans le même répertoire que le fichier dirstate, ensuite renomme
   1.796 +          <title>Accès <quote>dirstate</quote> sûr</title>
   1.797 +
   1.798 +	<para id="x_330">Comme avec les données de révision, Mercurial n'utilise pas
   1.799 +        de <quote>lock</quote> pour lire le fichier <quote>dirstate</quote> ; il n'acquiert pas un <quote>lock</quote> pour
   1.800 +    y écrire. Pour empêcher la possibilité de lire une copie partiellement
   1.801 +    écrite du fichier <quote>dirstate</quote>, Mercurial écrit sur un fichier avec un nom
   1.802 +    unique dans le même répertoire que le fichier <quote>dirstate</quote>, ensuite renomme
   1.803      le fichier temporaire automatiquement en <filename>dirstate</filename>.
   1.804      Le fichier nommé <filename>dirstate</filename> est ainsi garanti d'être
   1.805      écrit totalement, et non partiellement.</para>
   1.806 @@ -689,22 +689,22 @@
   1.807        </sect3>
   1.808      </sect2>
   1.809      <sect2>
   1.810 -      <title>Empécher les recherches</title>
   1.811 +      <title>Empêcher les recherches</title>
   1.812  
   1.813        <para id="x_331">L'absence de recherche sur les têtes de disques est
   1.814          critique pour la performance de Mercurial, puisque toute recherche
   1.815          est beaucoup plus coûteuse comparativement à une grosse opération de
   1.816          lecture.</para>
   1.817  
   1.818 -      <para id="x_332">C'est pour ça, par exemple, que le dirstate est stocké
   1.819 -        dans un unique fichier. S'il y avait eu un dirstate par répertoire
   1.820 -        que Mercurial suivait, le disque aurait recherché une fois par
   1.821 -        répertoire. Au lieu de ça, Mercurial lit entièrement un unique
   1.822 -        fichier, en une étape.</para>
   1.823 +    <para id="x_332">C'est pour ça, par exemple, que le <quote>dirstate</quote> est stocké
   1.824 +        dans un fichier unique. S'il y avait eu un <quote>dirstate</quote> par répertoire
   1.825 +        que Mercurial suivrait, le disque aurait recherché une fois par
   1.826 +        répertoire. Au lieu de ça, Mercurial lit entièrement un 
   1.827 +        fichier unique, en une étape.</para>
   1.828  
   1.829        <para id="x_333">Mercurial utilise aussi un schéma <quote>copie à
   1.830            l'écriture</quote> lorsqu'il clone un dépôt sur un stockage local.
   1.831 -        Au lieu de copier chaque fichier revlog depuis l'ancien dépôt vers le
   1.832 +      Au lieu de copier chaque <quote>fichier</quote> revlog depuis l'ancien dépôt vers le
   1.833          nouveau dépôt, il crée un <quote>lien physique</quote>, qui est le
   1.834          plus court chemin pour dire <quote>Ces deux noms pointent vers le
   1.835            même fichier</quote>. Lorsque Mercurial est sur le point d'écrire
   1.836 @@ -714,22 +714,22 @@
   1.837          du fichier qui est privée à ce dépôt.</para>
   1.838  
   1.839        <para id="x_334">Quelques développeurs de systèmes de gestion de
   1.840 -        révision ont montré que cette idée de faire une copie privée complète
   1.841 -        d'un fichier n'est pas vraiment efficace dans son utilisation du
   1.842 +        révisions ont montré que cette idée de faire une copie privée complète
   1.843 +        d'un fichier n'est pas vraiment efficace au niveau du
   1.844          stockage. Bien que ce soit vrai, le stockage est peu onéreux, et
   1.845          cette méthode donne la plus grande performance lorsque l'on reporte
   1.846          la plupart des journalisations au système d'exploitation. Un schéma
   1.847          alternatif réduirait certainement la performance tout en augmentant
   1.848 -        la complexité du logiciel, mais la vitesse et la simplicité sont els
   1.849 -        clefs du <quote>sentiment</quote> de l'utilisation
   1.850 +        la complexité du logiciel, mais la vitesse et la simplicité sont les
   1.851 +        clefs du <quote>confort</quote> de l'utilisation
   1.852          quotidienne.</para>
   1.853  
   1.854      </sect2>
   1.855      <sect2>
   1.856 -      <title>Autres contenus du dirstate</title>
   1.857 -
   1.858 -      <para id="x_335">Puisque Mercurial ne vous force pas à dire lorsque
   1.859 -        vous modifiez un fichier, il utilise le dirstate pour stocker
   1.860 +        <title>Autres contenus du <quote>dirstate</quote></title>
   1.861 +
   1.862 +      <para id="x_335">Puisque Mercurial ne vous force pas à signaler que
   1.863 +          vous modifiez un fichier, il utilise le <quote>dirstate</quote> pour stocker
   1.864          certaines informations supplémentaires pour déterminer efficacement
   1.865          si vous avez ou non modifié un fichier. Pour chaque fichier du
   1.866          répertoire de travail, il stocke l'heure à laquelle il a été modifié,
   1.867 @@ -739,22 +739,22 @@
   1.868            role="hg-cmd">hg add</command>, <command role="hg-cmd">hg
   1.869            remove</command>, <command role="hg-cmd">hg rename</command> ou
   1.870          <command role="hg-cmd">hg copy</command> sur des fichiers, Mercurial
   1.871 -        met à jour le dirstate afin de savoir quoi faire lorsque vous
   1.872 -        effectuez un commit.</para>
   1.873 -
   1.874 -      <para id="x_337">Le dirstate aide Mercurial à vérifier efficacement le
   1.875 -        status des fichiers dans un dépôt.</para>
   1.876 +        met à jour le <quote>dirstate</quote> afin de savoir quoi faire lorsque vous
   1.877 +        effectuez un <quote>commit</quote>.</para>
   1.878 +
   1.879 +    <para id="x_337">Le <quote>dirstate</quote> aide Mercurial à vérifier efficacement le
   1.880 +        statut des fichiers dans un dépôt.</para>
   1.881  
   1.882        <itemizedlist>
   1.883          <listitem> <para id="x_726"> Lorsque Mercurial vérifie l'état d'un
   1.884              fichier du répertoire de travail, il compare d'abord la date de
   1.885              dernière modification du fichier avec celle enregistrée dans le
   1.886 -            dirstate qui correspond à Mercurial a écrit en dernier sur ce
   1.887 +            <quote>dirstate</quote> qui correspond à celle que Mercurial a écrit en dernier sur ce
   1.888              fichier. Si le temps de dernière modification correspond au temps
   1.889              où Mercurial a écrit le fichier, celui ci n'a pas été modifié,
   1.890              donc mercurial n'a pas besoin de revérifier.</para> </listitem>
   1.891 -        <listitem> <para id="x_727"> Si la taille du fichier a changé, celui
   1.892 -            ci a été modifié. Si la date de modification a changé mais que la
   1.893 +    <listitem> <para id="x_727"> Si la taille du fichier a changé, celui-ci 
   1.894 +            a été modifié. Si la date de modification a changé mais que la
   1.895              taille est restée inchangée, seulement à ce moment là Mercurial
   1.896              doit vérifier le contenu du fichier pour savoir s'il a été
   1.897              modifié.</para> </listitem>