hgbook
changeset 1001:669ae1a09e46
French translation : ch04-concepts translated
author | Frédéric Bouquet <youshe.jaalon@gmail.com> |
---|---|
date | Mon Sep 14 01:18:56 2009 +0200 (2009-09-14) |
parents | 71dbda516572 |
children | 55d1bf9b47a4 |
files | fr/ch04-concepts.xml |
line diff
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>