hgbook
annotate fr/ch04-concepts.xml @ 1114:527b86d55d4a
inotify: update installation information
inotify is shipped in Mercurial since 1.0, which greatly simplifies the installation process
inotify is shipped in Mercurial since 1.0, which greatly simplifies the installation process
author | Nicolas Dumazet <nicdumz.commits@gmail.com> |
---|---|
date | Sun Dec 13 16:35:56 2009 +0900 (2009-12-13) |
parents | 53dfddc566d8 |
children |
rev | line source |
---|---|
belaran@964 | 1 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : --> |
belaran@964 | 2 |
bos@559 | 3 <chapter id="chap:concepts"> |
bos@572 | 4 <?dbhtml filename="behind-the-scenes.html"?> |
youshe@993 | 5 <title>Derrière le décor</title> |
youshe@993 | 6 |
wilk@1008 | 7 <para id="x_2e8">À la différence de beaucoup d'outils de gestion de révisions, |
youshe@993 | 8 les concepts sur lesquels se base Mercurial sont assez simples pour |
youshe@993 | 9 qu'il soit facile de comprendre comment le logiciel fonctionne. |
wilk@1008 | 10 Bien que leur connaissance ne soit pas indispensable, je trouve utile |
youshe@993 | 11 d'avoir un <quote>modèle mental</quote> de ce qui se passe.</para> |
youshe@993 | 12 |
youshe@993 | 13 <para id="x_2e9">En effet, cette compréhension m'apporte la confiance que |
youshe@993 | 14 Mercurial a été développé avec soin pour être à la fois |
youshe@993 | 15 <emphasis>sûr</emphasis> et <emphasis>efficace</emphasis>. De surcroît, |
wilk@1008 | 16 s'il m'est facile de garder en tête ce que le logiciel fait lorsque |
andre@1017 | 17 j'accomplis des tâches de révision, j'aurai moins de risques d'être |
youshe@993 | 18 surpris par son comportement.</para> |
youshe@993 | 19 |
youshe@993 | 20 <para id="x_2ea">Dans ce chapitre, nous décrirons tout d'abord les concepts |
youshe@993 | 21 essentiels de l'architecture de Mercurial, pour ensuite discuter quelques |
andre@1017 | 22 détails intéressants de son implémentation.</para> |
bos@559 | 23 |
bos@559 | 24 <sect1> |
youshe@993 | 25 <title>Conservation de l'historique sous Mercurial</title> |
youshe@993 | 26 <sect2> |
youshe@993 | 27 <title>Suivi de l'historique pour un seul fichier</title> |
youshe@993 | 28 |
youshe@993 | 29 <para id="x_2eb">Lorsque Mercurial effectue un suivi des modifications |
youshe@993 | 30 faites à un fichier, il conserve l'historique pour ce fichier dans un |
youshe@993 | 31 <emphasis>filelog</emphasis> sous forme de métadonnées. Chaque entrée |
wilk@1008 | 32 dans le <quote>filelog</quote> contient assez d'informations pour reconstituer une |
wilk@1008 | 33 révision du fichier correspondant. Les <quote>filelogs</quote> sont des fichiers |
youshe@993 | 34 stockés dans le répertoire <filename role="special" |
wilk@1008 | 35 class="directory">.hg/store/data</filename>. Un <quote>filelog</quote> contient |
andre@1017 | 36 des informations de deux types : les données de révision, et un index |
youshe@993 | 37 pour permettre à Mercurial une recherche efficace d'une révision |
youshe@993 | 38 donnée.</para> |
youshe@993 | 39 |
youshe@993 | 40 <para id="x_2ec">Lorsqu'un fichier devient trop gros ou a un long |
wilk@1008 | 41 historique, son <quote>filelog</quote> se voit stocké dans un fichier de données |
youshe@993 | 42 (avec un suffixe <quote><literal>.d</literal></quote>) et un fichier |
youshe@993 | 43 index (avec un suffixe<quote><literal>.i</literal></quote>) |
youshe@993 | 44 distincts. La relation entre un fichier dans le répertoire de travail |
wilk@1008 | 45 et le <quote>filelog</quote> couvrant le suivi de son historique dans le dépôt est |
youshe@993 | 46 illustré à la figure <xref linkend="fig:concepts:filelog"/>.</para> |
bos@559 | 47 |
bos@591 | 48 <figure id="fig:concepts:filelog"> |
youshe@993 | 49 <title>Relations entre les fichiers dans le répertoire de travail et |
wilk@1008 | 50 leurs <quote>filelogs</quote> dans le dépôt</title> |
youshe@993 | 51 <mediaobject> <imageobject><imagedata |
youshe@993 | 52 fileref="figs/filelog.png"/></imageobject> |
youshe@993 | 53 <textobject><phrase>XXX add text</phrase></textobject> |
youshe@993 | 54 </mediaobject> </figure> |
youshe@993 | 55 |
youshe@993 | 56 </sect2> |
youshe@993 | 57 <sect2> |
youshe@993 | 58 <title>Gestion des fichiers suivis</title> |
youshe@993 | 59 |
youshe@993 | 60 <para id="x_2ee">Mercurial a recours à une structure nommée |
youshe@993 | 61 <emphasis>manifest</emphasis> pour rassembler les informations sur |
wilk@1008 | 62 les fichiers dont il gère le suivi. Chaque entrée dans ce <quote>manifest</quote> |
youshe@993 | 63 contient des informations sur les fichiers présents dans une révision |
youshe@1001 | 64 donnée. Une entrée enregistre la liste des fichiers faisant partie de la |
youshe@993 | 65 révision, la version de chaque fichier, et quelques autres |
youshe@993 | 66 métadonnées sur ces fichiers.</para> |
bos@559 | 67 |
bos@559 | 68 </sect2> |
bos@559 | 69 <sect2> |
wilk@1008 | 70 <title>Enregistrer les informations des <quote>changesets</quote></title> |
youshe@1001 | 71 |
youshe@1001 | 72 <para id="x_2ef">Le <emphasis>changelog</emphasis> contient les |
wilk@1008 | 73 informations sur chaque <quote>changeset</quote>. Chaque révision enregistre qui a |
wilk@1008 | 74 <quote>committé</quote> un changement, le commentaire du <quote>changeset</quote>, d'autres |
wilk@1008 | 75 morceaux d'information relatives au <quote>changeset</quote> et la révision du |
wilk@1008 | 76 <quote>manifest</quote> à utiliser.</para> |
youshe@1001 | 77 |
youshe@1001 | 78 </sect2> |
youshe@1001 | 79 <sect2> |
youshe@1001 | 80 <title>Relations entre les révisions</title> |
youshe@1001 | 81 |
andre@1017 | 82 <para id="x_2f0">À l'intérieur d'un <quote>changelog</quote>, d'un <quote>manifest</quote>, ou d'un |
wilk@1008 | 83 <quote>filelog</quote>, chaque révision enregistre un pointeur vers son parent |
youshe@1001 | 84 immédiat (ou à ses deux parents s'il s'agit d'une révision |
youshe@1001 | 85 correspondant à une fusion (merge)). Comme mentionné plus haut, il y |
youshe@1001 | 86 a aussi des relations entre les révisions <emphasis>à |
youshe@1001 | 87 travers</emphasis> ces structures, qui sont de nature |
youshe@1001 | 88 hiérarchique.</para> |
youshe@1001 | 89 |
wilk@1008 | 90 <para id="x_2f1">Pour chaque <quote>changeset</quote> dans un dépôt, il y a exactement |
wilk@1008 | 91 une révision stockée dans le <quote>changelog</quote>. Chaque révision du <quote>changelog</quote> |
wilk@1008 | 92 contient un pointeur vers une unique révision du <quote>manifest</quote>. Une |
wilk@1008 | 93 révision du <quote>manifest</quote> garde un pointeur vers une unique révision pour |
wilk@1008 | 94 chaque <quote>filelog</quote> suivi lorsque le <quote>changeset</quote> est créé. Ces relations |
youshe@1001 | 95 sont illustrées dans <xref linkend="fig:concepts:metadata"/>.</para> |
bos@559 | 96 |
bos@591 | 97 <figure id="fig:concepts:metadata"> |
youshe@1001 | 98 <title>Metadata relationships</title> |
youshe@1001 | 99 <mediaobject> <imageobject><imagedata |
youshe@1001 | 100 fileref="figs/metadata.png"/></imageobject> |
youshe@1001 | 101 <textobject><phrase>XXX add text</phrase></textobject> |
youshe@1001 | 102 </mediaobject> |
bos@591 | 103 </figure> |
bos@559 | 104 |
wilk@1008 | 105 <para id="x_2f3">Comme l'illustration le montre, il |
youshe@1001 | 106 <emphasis>n'</emphasis>y a <emphasis>pas</emphasis> de relation |
wilk@1008 | 107 <quote>un à un</quote> entre les révisions dans un <quote>changelog</quote>, |
wilk@1008 | 108 <quote>manifest</quote> ou <quote>filelog</quote>. Si un fichier que Mercurial suit n'a pas changé |
wilk@1008 | 109 entre deux <quote>changesets</quote>, l'entrée pour ce fichier dans les deux |
wilk@1008 | 110 révisions du <quote>manifest</quote> pointera vers la même révision de son <quote>filelog</quote> |
youshe@1001 | 111 <footnote> <para id="x_725">Il est possible (bien qu'inhabituel) |
wilk@1008 | 112 qu'un <quote>manifest</quote> reste le même entre deux <quote>changesets</quote>, auquel cas |
wilk@1008 | 113 l'entrée du <quote>changelog</quote> pour ces <quote>changesets</quote> pointera vers la même |
wilk@1008 | 114 révision du <quote>manifest</quote>.</para> |
youshe@1001 | 115 </footnote>.</para> |
bos@559 | 116 |
bos@559 | 117 </sect2> |
bos@559 | 118 </sect1> |
bos@559 | 119 <sect1> |
youshe@1001 | 120 <title>Stockage sûr et efficace</title> |
youshe@1001 | 121 |
wilk@1008 | 122 <para id="x_2f4">Les fondements des <quote>changelogs</quote>, des <quote>manifests</quote> et des |
wilk@1008 | 123 <quote>filelogs</quote> sont fournis par une unique structure appelée le |
bos@559 | 124 <emphasis>revlog</emphasis>.</para> |
bos@559 | 125 |
bos@559 | 126 <sect2> |
andre@1017 | 127 <title>Stockage efficace</title> |
youshe@1001 | 128 |
wilk@1008 | 129 <para id="x_2f5">Le <quote>revlog</quote> fournit un stockage efficace des révisions en |
andre@1017 | 130 utilisant un mécanisme <emphasis>delta</emphasis>. Au lieu de stocker |
youshe@1001 | 131 une copie complète d'un fichier à chaque révision, il stocke les |
wilk@1008 | 132 changements requis pour transformer une révision plus ancienne en une |
andre@1017 | 133 nouvelle révision. Pour plusieurs types de données, ces deltas sont |
youshe@1001 | 134 typiquement une fraction de pourcentage de la taille de la copie |
youshe@1001 | 135 complète d'un fichier.</para> |
youshe@1001 | 136 |
wilk@1008 | 137 <para id="x_2f6">Certains systèmes de gestion de révisions obsolètes |
youshe@1001 | 138 peuvent seulement travailler avec les deltas de fichiers texte. Il |
youshe@1001 | 139 doivent d'ailleurs stocker les fichiers binaires comme des images |
youshe@1001 | 140 complètes ou encodées avec une représentation texte, chacune de ces |
youshe@1001 | 141 approches étant gaspilleuse. Mercurial peut traiter les deltas de |
youshe@1001 | 142 fichiers avec du contenu binaire arbitraire ; il n'a pas besoin de |
youshe@1001 | 143 traiter spécialement du texte.</para> |
bos@559 | 144 |
bos@559 | 145 </sect2> |
bos@559 | 146 <sect2 id="sec:concepts:txn"> |
youshe@1001 | 147 <title>Opérations sûres</title> |
youshe@1001 | 148 |
youshe@1001 | 149 <para id="x_2f7">Mercurial <emphasis>empile</emphasis> toujours les |
wilk@1008 | 150 données à la fin d'un fichier <quote>revlog</quote>. Il ne modifie jamais la section |
wilk@1008 | 151 d'un fichier après qu'il l'ait écrite. C'est à la fois plus robuste |
youshe@1001 | 152 et efficace que les schémas qui ont besoin de modifier ou réécrire |
youshe@1001 | 153 les données.</para> |
youshe@1001 | 154 |
wilk@1008 | 155 <para id="x_2f8">De plus, Mercurial traite chaque écriture comme la |
youshe@1001 | 156 partie d'une <emphasis>transaction</emphasis> qui peut comprendre |
youshe@1001 | 157 plusieurs fichiers. Une transaction est <emphasis>atomique</emphasis> |
andre@1017 | 158 : soit la transaction entière réussit et ses effets sont tous |
youshe@1001 | 159 visibles aux lecteurs en une étape, soit la totalité est annulée. |
youshe@1001 | 160 Cette garantie de l'atomicité signifie que si vous exécutez deux |
youshe@1001 | 161 copies de Mercurial, où une lit les données et l'autre les écrit, le |
youshe@1001 | 162 lecteur ne verra jamais un résultat partiellement écrit qui pourrait |
youshe@1001 | 163 le perturber.</para> |
youshe@1001 | 164 |
youshe@1001 | 165 <para id="x_2f9">Le fait que Mercurial ne fasse qu'ajouter aux fichiers |
youshe@1001 | 166 fait qu'il est facile de fournir cette garantie de transaction. Plus |
youshe@1001 | 167 les choses sont faites simplement comme ça, plus vous pouvez être |
youshe@1001 | 168 rassurés qu'elles sont bien faites.</para> |
youshe@1001 | 169 |
youshe@1001 | 170 </sect2> |
youshe@1001 | 171 <sect2> |
youshe@1001 | 172 <title>Récupération rapide</title> |
youshe@1001 | 173 |
youshe@1001 | 174 <para id="x_2fa">Mercurial évite habillement un piège commun à tous les |
youshe@1001 | 175 vieux systèmes de gestion de révisions : le problème de la |
andre@1017 | 176 <emphasis>récupération inefficace</emphasis>. La plupart des systèmes |
youshe@1001 | 177 de gestion de révisions stockent le contenu d'une révision comme une |
youshe@1001 | 178 série incrémentale de modifications faites à un |
wilk@1008 | 179 <quote>snapshot</quote>. (Certains basent le <quote>snapshot</quote> sur la plus |
youshe@1001 | 180 vieille révision, d'autres sur la plus récente.) Pour reconstruire |
wilk@1008 | 181 une révision spécifique, vous devez d'abord lire le <quote>snapshot</quote>, et |
wilk@1008 | 182 ensuite toutes les révisions entre le <quote>snapshot</quote> et votre révision |
youshe@1001 | 183 cible. Plus vous avez d'historique accumulé dans un fichier, plus de |
youshe@1001 | 184 révisions vous avez à lire, d'où la longueur que cela prend à |
youshe@1001 | 185 reconstruire une révision particulière.</para> |
bos@559 | 186 |
bos@591 | 187 <figure id="fig:concepts:snapshot"> |
wilk@1008 | 188 <title><quote>Snapshot</quote> d'un <quote>revlog</quote>, avec des deltas incrémentaux</title> |
youshe@1001 | 189 <mediaobject> <imageobject><imagedata |
youshe@1001 | 190 fileref="figs/snapshot.png"/></imageobject> |
youshe@1001 | 191 <textobject><phrase>XXX add text</phrase></textobject> |
youshe@1001 | 192 </mediaobject> |
bos@591 | 193 </figure> |
bos@559 | 194 |
andre@1017 | 195 <para id="x_2fc">L'innovation que Mercurial apporte à ce problème est |
andre@1017 | 196 simple mais efficace. Une fois que la quantité cumulée de deltas |
youshe@1001 | 197 d'informations stockées depuis le dernier snapshot excède un seuil |
wilk@1008 | 198 fixé, il stocke un nouveau <quote>snapshot</quote> (compressé bien sûr), plutôt qu'un |
youshe@1001 | 199 nouveau delta. Ceci rend possible la reconstruction de |
youshe@1001 | 200 <emphasis>toute</emphasis> révision d'un fichier rapidement. Cette |
youshe@1001 | 201 approche fonctionne si bien que depuis, elle a été copiée par |
youshe@1001 | 202 plusieurs autres systèmes de gestion de révisions.</para> |
youshe@1001 | 203 |
youshe@1001 | 204 <para id="x_2fd"><xref linkend="fig:concepts:snapshot"/> illustre |
wilk@1008 | 205 l'idée. Dans une entrée d'un fichier d'index de <quote>revlog</quote>, Mercurial |
wilk@1008 | 206 stocke l'intervalle des entrées depuis le fichier de données qu'il doit |
youshe@1001 | 207 lire pour reconstruire une révision particulière.</para> |
bos@559 | 208 |
bos@559 | 209 <sect3> |
andre@1017 | 210 <title>Aparté : l'influence de la compression vidéo</title> |
youshe@1001 | 211 |
youshe@1001 | 212 <para id="x_2fe">Si vous êtes familiés de la compression vidéo ou |
andre@1017 | 213 avez déjà regardé un programme TV par câble ou par un service |
youshe@1001 | 214 satellite, vous devez savoir que la plupart des schémas de |
andre@1017 | 215 compression vidéo stockent chaque trame de vidéo comme un delta |
andre@1017 | 216 vis-à-vis de la trame précédente.</para> |
youshe@1001 | 217 |
youshe@1001 | 218 <para id="x_2ff">Mercurial emprunte cette idée pour rendre possible |
youshe@1001 | 219 la reconstruction d'une révision à partir d'un snapshot et d'un |
youshe@1001 | 220 petit nombre de deltas.</para> |
bos@559 | 221 |
bos@559 | 222 </sect3> |
bos@559 | 223 </sect2> |
bos@559 | 224 <sect2> |
youshe@1001 | 225 <title>Identification et intégrité forte</title> |
youshe@1001 | 226 |
youshe@1001 | 227 <para id="x_300">Avec les deltas ou l'information du snapshot, une |
youshe@1001 | 228 entrée d'un revlog contient un hash cryptographique des données qu'il |
youshe@1001 | 229 représente. Ceci fait qu'il est difficile de construire les données |
youshe@1001 | 230 d'une révision, mais facile de détecter une corruption |
youshe@1001 | 231 accidentelle.</para> |
youshe@1001 | 232 |
youshe@1001 | 233 <para id="x_301">Les hash fournissent plus qu'un bon moyen de |
youshe@1001 | 234 vérification contre la corruption ; il sont aussi utilisés comme |
wilk@1008 | 235 identifiants pour les révisions. Les <quote>hashs</quote> d'identifications d'un |
wilk@1008 | 236 <quote>changeset</quote> que vous voyez comme utilisateur final proviennent des |
wilk@1008 | 237 révisions du <quote>changelog</quote>. Bien que les <quote>filelogs</quote> et le <quote>manifest</quote> |
andre@1017 | 238 utilisent aussi des <quote>hashs</quote>, Mercurial ne les utilise qu'en |
andre@1017 | 239 arrière-plan.</para> |
youshe@1001 | 240 |
wilk@1008 | 241 <para id="x_302">Mercurial vérifie que les <quote>hashs</quote> sont corrects lorsqu'il |
youshe@1001 | 242 récupère les révisions de fichiers et lorsqu'il récupère (pull) les |
youshe@1001 | 243 changements d'un autre dépôt. S'il rencontre un problème d'intégrité, |
wilk@1008 | 244 il se plaindra et arrêtera tout ce qu'il est en train de faire.</para> |
youshe@1001 | 245 |
youshe@1001 | 246 <para id="x_303">En plus de l'effet qu'il a sur l'efficacité des |
wilk@1008 | 247 récupérations, l'utilisation par Mercurial de <quote>snapshots</quote> périodiques |
youshe@1001 | 248 fait qu'il est plus robuste contre la corruption partielle de |
wilk@1008 | 249 données. Si un <quote>revlog</quote> devient partiellement corrompu à cause d'une |
youshe@1001 | 250 erreur matérielle ou d'un bug système, il est souvent possible de |
youshe@1001 | 251 reconstruire certaines ou la plupart des révisions à partir des |
wilk@1008 | 252 sections non corrompues du <quote>revlog</quote>, avant et après la section |
youshe@1001 | 253 corrompue. Ceci ne serait pas possible à partir d'un modèle de |
wilk@1008 | 254 stockage de deltas seul.</para> |
bos@559 | 255 </sect2> |
bos@559 | 256 </sect1> |
bos@701 | 257 |
bos@559 | 258 <sect1> |
youshe@1001 | 259 <title>Historique des révisions, branches et fusions (merge)</title> |
youshe@1001 | 260 |
wilk@1008 | 261 <para id="x_304">Chaque entrée dans un <quote>revlog</quote> Mercurial connaît |
wilk@1008 | 262 l'identité de l'ancêtre immédiat de la révision, habituellement désignée |
youshe@1001 | 263 comme son <emphasis>parent</emphasis>. En fait, une révision contient |
youshe@1001 | 264 de la place pour non pas un parent, mais deux. Mercurial utilise un |
wilk@1008 | 265 <quote>hash</quote> spécial, appelé le <quote>null ID</quote> pour représenter l'idée |
wilk@1008 | 266 qu'<quote>il n'y a pas de parent ici</quote>. Ce <quote>hash</quote> est simplement |
youshe@1001 | 267 une chaîne de zéros.</para> |
youshe@1001 | 268 |
youshe@1001 | 269 <para id="x_305">Dans <xref linkend="fig:concepts:revlog"/>, vous pouvez |
wilk@1008 | 270 voir un exemple de la structure conceptuelle d'un <quote>revlog</quote>. Les <quote>filelogs</quote>, |
wilk@1008 | 271 <quote>manifests</quote> et <quote>changelogs</quote> ont tous cette même structure ; ils diffèrent |
youshe@1001 | 272 simplement dans le type de donnée stockée dans chaque delta ou |
wilk@1008 | 273 <quote>snapshot</quote>.</para> |
wilk@1008 | 274 |
wilk@1008 | 275 <para id="x_306">La première révision d'un <quote>revlog</quote> (au bas de l'image) a |
wilk@1008 | 276 le <quote>null ID</quote> dans chacune de ses cases parent. Pour une révision |
youshe@1001 | 277 <quote>normale</quote>, sa première case parent contient l'ID de sa |
wilk@1008 | 278 révision parent et la seconde contient le <quote>null ID</quote>, indiquant que cette |
youshe@1001 | 279 révision n'a qu'un seul vrai parent. Si deux révisions ont le même |
youshe@1001 | 280 parent, il s'agit de branches. Une révision qui représente une fusion |
youshe@1001 | 281 (merge) entre deux branches a deux identifiants de révision normaux |
youshe@1001 | 282 dans ses cases parents.</para> |
bos@559 | 283 |
bos@591 | 284 <figure id="fig:concepts:revlog"> |
wilk@1008 | 285 <title>Le concept de la structure d'un <quote>revlog</quote></title> |
youshe@1001 | 286 <mediaobject> <imageobject><imagedata |
youshe@1001 | 287 fileref="figs/revlog.png"/></imageobject> <textobject><phrase>XXX |
youshe@1001 | 288 add text</phrase></textobject> |
bos@591 | 289 </mediaobject> |
bos@591 | 290 </figure> |
bos@559 | 291 |
bos@559 | 292 </sect1> |
bos@559 | 293 <sect1> |
youshe@1001 | 294 <title>Le répertoire de travail</title> |
youshe@1001 | 295 |
wilk@1008 | 296 <para id="x_307">Dans un répertoire de travail, Mercurial stocke une image |
wilk@1008 | 297 des fichiers du dépôt à un <quote>changeset</quote> particulier.</para> |
youshe@1001 | 298 |
youshe@1001 | 299 <para id="x_308">Le répertoire de travail <quote>sait</quote> quel |
wilk@1008 | 300 <quote>changeset</quote> il contient. Lorsque vous mettez à jour (update) le |
wilk@1008 | 301 répertoire de travail à un certain <quote>changeset</quote>, Mercurial regarde la |
wilk@1008 | 302 révision appropriée du <quote>manifest</quote> pour trouver quels fichiers il suivait |
wilk@1008 | 303 au moment où le <quote>changeset</quote> a été <quote>committé</quote>, et quelle révision de chaque |
youshe@1001 | 304 fichier était alors courante. Il recrée ensuite une copie de chacun de |
wilk@1008 | 305 ces fichiers, avec le même contenu qu'ils avaient lorsque le <quote>changeset</quote> |
wilk@1008 | 306 a été <quote>committé</quote>.</para> |
youshe@1001 | 307 |
youshe@1001 | 308 <para id="x_309">La structure spéciale <emphasis>dirstate</emphasis> |
youshe@1001 | 309 contient la connaissance de Mercurial sur le répertoire de travail. |
youshe@1001 | 310 Elle est maintenue par un fichier appelé |
youshe@1001 | 311 <filename>.hg/dirstate</filename> dans un dépôt. Les détails du |
wilk@1008 | 312 dirstate sont le <quote>changeset</quote> vers lequel le répertoire de travail se met |
youshe@1001 | 313 à jour (update), et tous les fichiers que Mercurial suit dans le |
wilk@1008 | 314 répertoire de travail. Il permet aussi à Mercurial de connaître |
wilk@1008 | 315 rapidement les fichiers modifiés, en enregistrant l'heure de |
wilk@1008 | 316 dernière modification et la taille de chacun.</para> |
wilk@1008 | 317 |
wilk@1008 | 318 <para id="x_30a">Puisqu'une révision de <quote>revlog</quote> a des emplacements pour |
youshe@1001 | 319 deux parents et peut représenter aussi bien une révision normale (avec |
wilk@1008 | 320 un parent) ou une fusion de deux révisions anciennes, le <quote>dirstate</quote> a des |
youshe@1001 | 321 emplacements pour deux parents. Lorsque vous utilisez la commande |
wilk@1008 | 322 <command role="hg-cmd">hg update</command>, le <quote>changeset</quote> que vous |
youshe@1001 | 323 mettez à jour est stocké dans l'emplacement du <quote>premier |
wilk@1008 | 324 parent</quote>, et le <quote>null ID</quote> l'est dans le second. Lorsque vous |
youshe@1001 | 325 utilisez la commande <command role="hg-cmd">hg merge</command> avec un |
youshe@1001 | 326 autre changeset, le premier parent reste inchangé, et le second est |
wilk@1008 | 327 rempli avec le <quote>changeset</quote> à partir duquel vous êtes en train de |
youshe@1001 | 328 fusionner. La commande <command role="hg-cmd">hg parents</command> vous |
youshe@1001 | 329 donne les parents du dirstate.</para> |
youshe@1001 | 330 |
youshe@1001 | 331 <sect2> |
andre@1017 | 332 <title>Que se passe-t-il lorsque vous <quote>committez</quote></title> |
wilk@1008 | 333 |
wilk@1008 | 334 <para id="x_30b">Le <quote>dirstate</quote> stocke les informations sur les parents |
andre@1017 | 335 pour plus qu'une simple comptabilité. Mercurial utilise les |
andre@1017 | 336 parents du <quote>dirstate</quote> comme <emphasis>les parents d'un nouveau |
wilk@1008 | 337 <quote>changeset</quote></emphasis> lorsque vous <quote>committez</quote>.</para> |
youshe@1001 | 338 |
youshe@1001 | 339 <figure id="fig:concepts:wdir"> |
youshe@1001 | 340 <title>Le répertoire de travail peut avoir deux parents</title> |
youshe@1001 | 341 <mediaobject> |
youshe@1001 | 342 <imageobject><imagedata fileref="figs/wdir.png"/></imageobject> |
youshe@1001 | 343 <textobject><phrase>XXX add text</phrase></textobject></mediaobject> |
bos@591 | 344 </figure> |
bos@559 | 345 |
youshe@1001 | 346 <para id="x_30d"><xref linkend="fig:concepts:wdir"/> montre l'état |
wilk@1008 | 347 normal d'un répertoire de travail, où il n'y a qu'un seul <quote>changeset</quote> |
wilk@1008 | 348 comme parent. Ce <quote>changeset</quote> est le <emphasis>tip</emphasis>, le |
wilk@1008 | 349 <quote>changeset</quote> le plus récent dans le dépôt n'a pas d'enfant.</para> |
bos@559 | 350 |
bos@591 | 351 <figure id="fig:concepts:wdir-after-commit"> |
youshe@1001 | 352 <title>Le répertoire de travail gagne de nouveaux parents après un |
wilk@1008 | 353 <quote>commit</quote></title> |
youshe@1001 | 354 <mediaobject> |
youshe@1001 | 355 <imageobject><imagedata |
youshe@1001 | 356 fileref="figs/wdir-after-commit.png"/></imageobject> |
youshe@1001 | 357 <textobject><phrase>XXX add text</phrase></textobject> |
youshe@1001 | 358 </mediaobject> |
bos@591 | 359 </figure> |
bos@559 | 360 |
wilk@1008 | 361 <para id="x_30f">On peut se représenter le répertoire de travail comme |
wilk@1008 | 362 <quote>le changeset que je vais committer</quote>. Chaque fichier |
wilk@1008 | 363 que vous demandez à Mercurial d'ajouter, de supprimer, de renommer ou de |
wilk@1008 | 364 copier va être intégré dans ce changeset, tout comme les |
youshe@1001 | 365 modifications de n'importe quel fichier que Mercurial est déjà en |
wilk@1008 | 366 train de suivre ; le nouveau <quote>changeset</quote> aura les mêmes parents que le |
youshe@1001 | 367 répertoire de travail.</para> |
youshe@1001 | 368 |
youshe@1001 | 369 <para id="x_310">Après un commit, Mercurial va mettre à jour les |
wilk@1008 | 370 parents du répertoire de travail, ainsi, le premier parent est l'ID |
wilk@1008 | 371 du nouveau <quote>changeset</quote>, et le second, le <quote>null ID</quote>. Ceci est illustré dans |
youshe@1001 | 372 <xref linkend="fig:concepts:wdir-after-commit"/>. Mercurial ne touche |
wilk@1008 | 373 à aucun des fichiers du répertoire de travail lorsque vous <quote>committez</quote> |
youshe@1001 | 374 ; il modifie simplement le dirstate pour noter ses nouveaux |
youshe@1001 | 375 parents.</para> |
youshe@1001 | 376 |
youshe@1001 | 377 </sect2> |
youshe@1001 | 378 <sect2> |
youshe@1001 | 379 <title>Création d'une nouvelle <quote>head</quote></title> |
youshe@1001 | 380 |
wilk@1008 | 381 <para id="x_311">Il est parfaitement normal de faire un <quote>update</quote> du |
wilk@1008 | 382 répertoire de travail à un <quote>changeset</quote> autre que le <quote>tip</quote> courant. Par |
wilk@1008 | 383 exemple, vous pourriez vouloir savoir à quoi votre projet |
wilk@1008 | 384 ressemblait mardi dernier, ou regarder le <quote>changeset</quote> qui a |
youshe@1001 | 385 introduit un bug. Dans des cas comme ça, la chose naturelle à faire |
wilk@1008 | 386 est de faire un <quote>update</quote> du répertoire de travail au <quote>changeset</quote> qui vous |
youshe@1001 | 387 intéresse, et ensuite d'en examiner les fichiers pour regarder leurs |
andre@1017 | 388 contenus comme ils l'étaient lorsque vous avez <quote>committé</quote> ce <quote>changeset</quote>. |
youshe@1001 | 389 L'effet de ceci est montré dans <xref |
youshe@1001 | 390 linkend="fig:concepts:wdir-pre-branch"/>.</para> |
bos@559 | 391 |
bos@591 | 392 <figure id="fig:concepts:wdir-pre-branch"> |
wilk@1008 | 393 <title>Le répertoire de travail, <quote>updaté</quote> pour un <quote>changeset</quote> plus |
youshe@1001 | 394 ancien</title> |
youshe@1001 | 395 <mediaobject> <imageobject><imagedata |
youshe@1001 | 396 fileref="figs/wdir-pre-branch.png"/></imageobject> |
youshe@1001 | 397 <textobject><phrase>XXX add text</phrase></textobject> |
youshe@1001 | 398 </mediaobject> |
bos@591 | 399 </figure> |
bos@559 | 400 |
wilk@1008 | 401 <para id="x_313">En ayant fait un <quote>update</quote> du répertoire de travail vers |
andre@1017 | 402 un <quote>changeset</quote> plus ancien, que se passe-t-il si vous faites des |
wilk@1008 | 403 changements et ensuite <quote>committez</quote> ? Mercurial se comporte comme je |
youshe@1001 | 404 l'ai fait remarqué plus haut. Les parents du répertoire de travail |
wilk@1008 | 405 deviennent les parents du nouveau <quote>changeset</quote>. Ce nouveau <quote>changeset</quote> n'a |
wilk@1008 | 406 pas d'enfant, donc il devient le nouveau <quote>tip</quote>. Le dépôt contient |
wilk@1008 | 407 maintenant deux <quote>changesets</quote> qui n'ont pas d'enfant ; on appelle ceci |
wilk@1008 | 408 des <emphasis>heads</emphasis>. Vous pouvez voir la structure que |
youshe@1001 | 409 cela crée dans <xref linkend="fig:concepts:wdir-branch"/>.</para> |
bos@559 | 410 |
bos@591 | 411 <figure id="fig:concepts:wdir-branch"> |
wilk@1008 | 412 <title>Après un <quote>commit</quote> fait pendant la synchronisation avec un ancien |
wilk@1008 | 413 <quote>changeset</quote></title> |
youshe@1001 | 414 <mediaobject> <imageobject><imagedata |
youshe@1001 | 415 fileref="figs/wdir-branch.png"/></imageobject> |
youshe@1001 | 416 <textobject><phrase>XXX add text</phrase></textobject> |
youshe@1001 | 417 </mediaobject> |
bos@591 | 418 </figure> |
bos@559 | 419 |
bos@559 | 420 <note> |
andre@1017 | 421 <para id="x_315">Si vous êtes un nouvel utilisateur de Mercurial, vous devez garder |
youshe@1001 | 422 à l'esprit une <quote>erreur</quote> commune, qui est d'utiliser la |
youshe@1001 | 423 commande <command role="hg-cmd">hg pull</command> sans aucune |
youshe@1001 | 424 option. Par défaut, la commande <command role="hg-cmd">hg |
wilk@1008 | 425 pull</command> <emphasis>ne fait pas</emphasis> d'<quote>update</quote> sur le |
youshe@1001 | 426 répertoire de travail, ainsi, vous allez récupérer les nouveaux |
youshe@1001 | 427 changesets dans votre dépôt, mais le répertoire de travail va |
wilk@1008 | 428 rester synchronisé au même <quote>changeset</quote> qu'il l'était avant le <quote>pull</quote>. |
wilk@1008 | 429 Si vous faites des changements et <quote>committez</quote> ensuite, vous allez |
wilk@1008 | 430 créer une nouvelle <quote>head</quote> puisque votre répertoire de travail n'est |
wilk@1008 | 431 pas synchronisé au <quote>tip</quote> actuel. Pour combiner les |
wilk@1008 | 432 opérations d'un <quote>pull</quote> suivi d'un <quote>update</quote>, exécutez <command>hg |
youshe@1001 | 433 pull -u</command>.</para> |
youshe@1001 | 434 |
youshe@1001 | 435 <para id="x_316">Je place le mot <quote>erreur</quote> entre |
andre@1017 | 436 guillemets parce que tout ce dont vous avez besoin de faire pour |
wilk@1008 | 437 rectifier la situation où vous avez créé une nouvelle <quote>head</quote> par |
youshe@1001 | 438 accident est un <command role="hg-cmd">hg merge</command> suivi |
youshe@1001 | 439 d'un <command role="hg-cmd">hg commit</command>. En d'autres mots, |
youshe@1001 | 440 ceci n'a presque jamais de conséquences négatives ; il s'agit juste |
youshe@1001 | 441 d'une surprise pour les nouveaux arrivants. Je discuterai d'autres |
youshe@1001 | 442 moyens d'éviter ce comportement, et pourquoi Mercurial agit de |
youshe@1001 | 443 cette façon surprenante plus tard.</para> |
bos@559 | 444 </note> |
bos@559 | 445 |
bos@559 | 446 </sect2> |
bos@559 | 447 <sect2> |
youshe@1001 | 448 <title>Fusionner (merge) les changements</title> |
youshe@1001 | 449 |
youshe@1001 | 450 <para id="x_317">Lorsque vous exécutez la commande <command |
youshe@1001 | 451 role="hg-cmd">hg merge</command>, Mercurial laisse le premier |
youshe@1001 | 452 parent du répertoire de travail inchangé et fixe le second au |
wilk@1008 | 453 <quote>changeset</quote> avec lequel vous fusionnez (merge), comme montré dans <xref |
youshe@1001 | 454 linkend="fig:concepts:wdir-merge"/>.</para> |
bos@559 | 455 |
bos@591 | 456 <figure id="fig:concepts:wdir-merge"> |
wilk@1008 | 457 <title>Fusionner (merge) deux <quote>heads</quote></title> |
youshe@1001 | 458 <mediaobject> |
youshe@1001 | 459 <imageobject> <imagedata fileref="figs/wdir-merge.png"/> |
youshe@1001 | 460 </imageobject> <textobject><phrase>XXX add text</phrase></textobject> |
youshe@1001 | 461 </mediaobject> |
bos@591 | 462 </figure> |
bos@559 | 463 |
youshe@1001 | 464 <para id="x_319">Mercurial doit aussi modifier le répertoire de |
wilk@1008 | 465 travail pour fusionner les fichiers gérés dans les deux <quote>changesets</quote>. |
youshe@1001 | 466 Un peu simplifié, le processus de fusion fonctionne comme ça : pour |
wilk@1008 | 467 chaque fichier dans le <quote>manifest</quote> de chaque <quote>changeset</quote>.</para> |
youshe@1001 | 468 |
bos@559 | 469 <itemizedlist> |
wilk@1008 | 470 <listitem><para id="x_31a">Si aucun <quote>changeset</quote> n'a modifié un fichier, |
youshe@1001 | 471 ne rien faire avec ce fichier.</para> </listitem> |
wilk@1008 | 472 <listitem><para id="x_31b">Si un <quote>changeset</quote> a modifié un fichier et |
youshe@1001 | 473 que l'autre ne l'a pas fait, créer une copie modifiée du fichier |
youshe@1001 | 474 dans le répertoire de travail.</para> </listitem> |
wilk@1008 | 475 <listitem><para id="x_31c">Si un <quote>changeset</quote> a modifié un fichier, et |
youshe@1001 | 476 que l'autre ne l'a pas fait (ou l'a supprimé), supprimer le |
youshe@1001 | 477 fichier du répertoire de travail.</para> </listitem> |
wilk@1008 | 478 <listitem><para id="x_31d">Si un <quote>changeset</quote> a supprimé un fichier, |
youshe@1001 | 479 mais que l'autre a modifié le fichier, demander à l'utilisateur |
youshe@1001 | 480 quoi faire : garder le fichier modifié ou le supprimer ?</para> |
youshe@1001 | 481 </listitem> |
andre@1017 | 482 <listitem><para id="x_31e">Si chacun des <quote>changesets</quote> a modifié un |
youshe@1001 | 483 fichier, invoquer le programme externe de fusion pour choisir les |
youshe@1001 | 484 nouveaux contenus pour le fichier fusionné. Ceci peut demander |
andre@1017 | 485 une intervention de l'utilisateur.</para></listitem> |
wilk@1008 | 486 <listitem><para id="x_31f">Si un <quote>changeset</quote> a modifié un fichier, et |
youshe@1001 | 487 que l'autre a renommé ou copié le fichier, être sûr que les |
youshe@1001 | 488 changements suivent le nouveau nom du fichier.</para></listitem> |
youshe@1001 | 489 </itemizedlist> |
youshe@1001 | 490 |
youshe@1001 | 491 <para id="x_320">Il y a plus de détails&emdash;fusionner a beaucoup de |
andre@1023 | 492 cas épineux&emdash;mais ceux-ci sont des choix plus communs qui sont |
andre@1017 | 493 liés à une fusion (merge). Comme vous pouvez le voir, la |
youshe@1001 | 494 plupart des cas sont entièrement automatiques, et effectivement, la |
andre@1017 | 495 plupart des fusions (merge) se terminent automatiquement, sans nécessiter |
andre@1017 | 496 votre intervention pour résoudre un conflit.</para> |
youshe@1001 | 497 |
youshe@1001 | 498 <para id="x_321">Lorsque vous pensez à ce qu'il se passe lorsque vous |
wilk@1008 | 499 <quote>committez</quote> après un <quote>merge</quote>, une fois encore, le répertoire de travail |
youshe@1001 | 500 est <quote>le changeset que je suis sur le point de |
youshe@1001 | 501 committer</quote>. Après que la commande <command role="hg-cmd">hg |
andre@1017 | 502 merge</command> soit terminée, le répertoire de travail a deux |
youshe@1001 | 503 parents ; ceux ci vont devenir les parents du nouveau |
wilk@1008 | 504 <quote>changeset</quote>.</para> |
youshe@1001 | 505 |
youshe@1001 | 506 <para id="x_322">Mercurial vous permet d'exécuter de multiples fusions, |
wilk@1008 | 507 mais vous devez <quote>committer</quote> le résultat de chaque fusion individuellement |
wilk@1008 | 508 au fur et à mesure. Ceci est nécessaire puisque Mercurial ne stocke |
youshe@1001 | 509 que deux parents pour chaque révision et le répertoire de travail. |
wilk@1008 | 510 Alors qu'il serait techniquement faisable de fusionner de multiples |
andre@1017 | 511 <quote>changesets</quote> en même temps, Mercurial interdit cela pour être plus simple. Avec |
wilk@1008 | 512 des fusions multiples, les risques de confusion pour l'utilisateur, de |
andre@1017 | 513 mauvaie résolution de conflits, et de pagaille dans les fusions |
andre@1017 | 514 augmenteraient de façon intolérable.</para> |
youshe@1001 | 515 |
youshe@1001 | 516 </sect2> |
youshe@1001 | 517 |
youshe@1001 | 518 <sect2> |
youshe@1001 | 519 <title>Fusions et renommages</title> |
youshe@1001 | 520 |
youshe@1001 | 521 <para id="x_69a">Un nombre surprenant de systèmes de gestion de |
andre@1017 | 522 révisions fait peu ou pas attention à un <emphasis>nom</emphasis> de fichier au |
youshe@1001 | 523 cours du temps. Par exemple, il était habituel que si un fichier |
youshe@1001 | 524 était renommé d'un coté de la fusion, les changements à partir de |
youshe@1001 | 525 l'autre coté étaient supprimés silencieusement.</para> |
youshe@1001 | 526 |
youshe@1001 | 527 <para id="x_69b">Mercurial enregistre les metadata lorsque vous lui |
andre@1017 | 528 dites d'exécuter un renommage ou une copie. Il utilise ces metadatas |
youshe@1001 | 529 durant une fusion pour faire les bonnes choses dans le cas d'un |
wilk@1008 | 530 <quote>merge</quote>. Par exemple, si je renomme un fichier et que vous l'éditez |
youshe@1001 | 531 sans le renommer, lorsque l'on fusionne, le fichier sera renommé et |
wilk@1008 | 532 aura les changements appliqués.</para> |
youshe@1001 | 533 |
bos@620 | 534 </sect2> |
bos@559 | 535 </sect1> |
bos@620 | 536 |
bos@559 | 537 <sect1> |
youshe@1001 | 538 <title>D'autres fonctionnalités intéressantes</title> |
youshe@1001 | 539 |
wilk@1008 | 540 <para id="x_323">Dans les sections au-dessus, j'ai tenté de mettre |
youshe@1001 | 541 l'accent sur certains aspects importants du design de Mercurial pour |
youshe@1001 | 542 illustrer l'attention particulière qui a été portée à la fiabilité et à |
wilk@1008 | 543 la performance. Cependant, l'attention aux détails ne s'arrête pas ici. |
youshe@1001 | 544 Il y a de nombreux aspects sur la construction de Mercurial que je |
andre@1017 | 545 trouve personnellement intéressants. J'en détaillerai quelques-uns |
wilk@1008 | 546 ici, séparément des éléments du <quote>big ticket</quote> ci-dessus, |
youshe@1001 | 547 ainsi, si vous êtes intéressés, vous pourrez avoir une meilleure idée |
wilk@1008 | 548 de la quantité d'ingéniosité qu'il y a derrière un système bien |
wilk@1008 | 549 conçu.</para> |
youshe@1001 | 550 |
youshe@1001 | 551 <sect2> |
andre@1017 | 552 <title>Compression astucieuse</title> |
youshe@1001 | 553 |
youshe@1001 | 554 <para id="x_324">Lorsque cela est approprié, Mercurial stocke les |
wilk@1008 | 555 <quote>snapshots</quote> et deltas sous une forme compressée. Il le fait en |
wilk@1008 | 556 <emphasis>essayant</emphasis> toujours de compresser un <quote>snapshot</quote> ou |
wilk@1008 | 557 un delta, mais en ne stockant la version compressée que si celle-ci |
youshe@1001 | 558 est plus petite que la version non compressée.</para> |
youshe@1001 | 559 |
youshe@1001 | 560 <para id="x_325">Ceci signifie que Mercurial fait <quote>la bonne |
youshe@1001 | 561 chose</quote> lorsqu'il stocke un fichier dont la forme native est |
youshe@1001 | 562 compressée, comme une archive <literal>zip</literal> ou une image |
youshe@1001 | 563 JPEG. Lorsque ces types de fichiers sont compressés une seconde fois, |
youshe@1001 | 564 le fichier obtenu est habituellement plus gros que la forme |
youshe@1001 | 565 compressée une seule fois et Mercurial stockera alors le |
youshe@1001 | 566 <literal>zip</literal> ou JPEG.</para> |
youshe@1001 | 567 |
andre@1017 | 568 <para id="x_326">Les deltas entre les révisions d'un fichier compressé |
youshe@1001 | 569 sont habituellement plus gros que les snapshots du fichier, et |
youshe@1001 | 570 Mercurial fait à nouveau <quote>la bonne chose</quote> dans ces cas. |
youshe@1001 | 571 Il trouve qu'un delta dépasse le seuil auquel il devrait stocker un |
wilk@1008 | 572 <quote>snapshot</quote> complet du fichier, alors il stocke le <quote>snapshot</quote>, en gagnant |
wilk@1008 | 573 encore de la place en comparaison d'une approche naïve avec un delta |
andre@1020 | 574 seulement.</para> |
bos@559 | 575 |
bos@559 | 576 <sect3> |
andre@1017 | 577 <title>Recompression sur le réseau</title> |
youshe@1001 | 578 |
youshe@1001 | 579 <para id="x_327">Lors du stockage des révisions sur le disque, |
youshe@1001 | 580 Mercurial utilise l'algorithme de compression |
andre@1017 | 581 <quote>deflate</quote> (le même que celui utilisé pour le format populaire |
andre@1017 | 582 d'archive <literal>zip</literal>), qui est un bon |
wilk@1008 | 583 compromis entre la vitesse et le taux de compression. Cependant, |
youshe@1001 | 584 lors de la transmission d'une révision de données par une connexion |
youshe@1001 | 585 réseau, Mercurial décompresse les données de révision |
youshe@1001 | 586 compressées.</para> |
youshe@1001 | 587 |
wilk@1008 | 588 <para id="x_328">Si la connexion passe par HTTP, Mercurial |
youshe@1001 | 589 recompresse le flux entier de données en utilisant un algorithme de |
youshe@1001 | 590 compression qui donne un meilleur taux de compression (l'algorithme |
wilk@1008 | 591 Burrows-Wheeler utilisé principalement par le logiciel de |
youshe@1001 | 592 compression <literal>bzip2</literal>). Cette combinaison de |
andre@1017 | 593 l'algorithme et de la compression du flux entier (plutôt que pour une |
wilk@1008 | 594 révision à la fois) réduit substantiellement le nombre de bits qui |
wilk@1008 | 595 sont transférés, résultant en une performance réseau accrue sur |
youshe@1001 | 596 la plupart des supports.</para> |
youshe@1001 | 597 |
wilk@1008 | 598 <para id="x_329">Si la connexion passe par |
youshe@1001 | 599 <command>ssh</command>, Mercurial <emphasis>ne</emphasis> |
youshe@1001 | 600 recompresse <emphasis>pas</emphasis> le flux puisque |
andre@1017 | 601 <command>ssh</command> peut déjà le faire par lui-même. Vous pouvez |
youshe@1001 | 602 demander à Mercurial de toujours utiliser la compression |
youshe@1001 | 603 <command>ssh</command> en éditant le fichier |
wilk@1008 | 604 <filename>.hgrc</filename> de votre répertoire personnel comme ci-dessous. |
wilk@1008 | 605 </para> |
youshe@1001 | 606 |
youshe@1001 | 607 <programlisting>[ui] |
bos@701 | 608 ssh = ssh -C</programlisting> |
bos@559 | 609 |
bos@559 | 610 </sect3> |
bos@559 | 611 </sect2> |
bos@559 | 612 <sect2> |
andre@1017 | 613 <title>Ordre de lecture/écriture et atomicité</title> |
youshe@1001 | 614 |
wilk@1008 | 615 <para id="x_32a">L'histoire ne se résume pas à ajouter à la fin des fichiers |
wilk@1008 | 616 lorsque l'on cherche à garantir que le lecteur ne verra |
youshe@1001 | 617 pas qu'une écriture partielle. Si vous relisez <xref |
wilk@1008 | 618 linkend="fig:concepts:metadata"/>, les révisions dans le <quote>changelog</quote> |
wilk@1008 | 619 pointent vers les révisions dans le <quote>manifest</quote>, et les révisions du |
wilk@1008 | 620 <quote>manifest</quote> pointent vers les révisions du <quote>filelog</quote>. Cette hiérarchie est |
youshe@1001 | 621 délibérée.</para> |
youshe@1001 | 622 |
wilk@1008 | 623 <para id="x_32b">L'écriture commence par une transaction en écrivant dans |
wilk@1008 | 624 le <quote>filelog</quote> et dans les données du <quote>manifest</quote>, et n'écrit aucune donnée |
wilk@1008 | 625 du <quote>changelog</quote> tant que ce n'est pas terminé. La lecture commence en |
wilk@1008 | 626 lisant les données du <quote>changelog</quote>, puis les données du <quote>manifest</quote>, et |
wilk@1008 | 627 enfin les données du <quote>filelog</quote>.</para> |
youshe@1001 | 628 |
youshe@1001 | 629 <para id="x_32c">Puisque que l'écriture ne finit pas d'écrire les |
wilk@1008 | 630 données du <quote>filelog</quote> et du <quote>manifest</quote> avant d'écrire dans le <quote>changelog</quote>, |
wilk@1008 | 631 la lecture ne verra jamais un pointeur vers une révision du <quote>manifest</quote> |
wilk@1008 | 632 partiellement écrite à partir du <quote>changelog</quote>, et ne lira jamais un |
wilk@1008 | 633 pointeur vers une révision du <quote>filelog</quote> partiellement écrite dans le |
wilk@1008 | 634 <quote>manifest</quote>.</para> |
youshe@1001 | 635 |
youshe@1001 | 636 </sect2> |
youshe@1001 | 637 <sect2> |
youshe@1001 | 638 <title>Accès concurrent</title> |
youshe@1001 | 639 |
youshe@1001 | 640 <para id="x_32d">La garantie de l'ordre de lecture/écriture et |
wilk@1008 | 641 de l'atomicité signifie que Mercurial n'a jamais besoin de poser de |
youshe@1001 | 642 <emphasis>lock</emphasis> sur un dépôt lorsqu'il lit des données, |
youshe@1001 | 643 même si le dépôt est en train d'être écrit au même moment que la |
wilk@1008 | 644 lecture a lieu. Ceci a un grand impact sur la fiabilité ; vous |
youshe@1001 | 645 pouvez avoir un nombre arbitraire de processus Mercurial qui lisent |
wilk@1008 | 646 sans risque les données d'un dépôt en même temps, peu importe s'il |
youshe@1001 | 647 est en train d'être lu ou non.</para> |
youshe@1001 | 648 |
youshe@1001 | 649 <para id="x_32e">La nature sans <quote>lock</quote> de la lecture |
youshe@1001 | 650 signifie que si vous partagez un dépôt sur un système |
youshe@1001 | 651 multi-utilisateurs, vous n'avez pas besoin de donner aux autres |
youshe@1001 | 652 utilisateurs locaux la permission d'<emphasis>écrire</emphasis> sur |
wilk@1008 | 653 votre dépôt pour qu'ils soient capable de faire un clone ou un <quote>pull</quote> |
andre@1017 | 654 des changements à partir de celui-ci ; ils ont seulement besoin de la |
youshe@1001 | 655 permission en <emphasis>lecture</emphasis>. (Il |
youshe@1001 | 656 <emphasis>ne</emphasis> s'agit <emphasis>pas</emphasis> d'une |
wilk@1008 | 657 fonctionnalité commune à travers les systèmes de gestion de révisions, |
andre@1017 | 658 donc ne prenez pas ça pour argent comptant ! La plupart ont besoin que les |
youshe@1001 | 659 lecteurs soient capables de mettre un lock sur le dépôt pour y |
youshe@1001 | 660 accéder en toute sécurité, et ceci demande des permissions en |
wilk@1008 | 661 écriture, sur au moins un répertoire, ce qui provoque bien sûr toutes |
andre@1017 | 662 sortes de problèmes pénibles et agaçants relatifs à la sécurité et à |
youshe@1001 | 663 l'administration.)</para> |
youshe@1001 | 664 |
wilk@1008 | 665 <para id="x_32f">Mercurial utilise des <quote>locks</quote> pour assurer qu'un seul |
youshe@1001 | 666 processus peut écrire dans le dépôt à un moment donné (le mécanisme |
wilk@1008 | 667 de <quote>lock</quote> est sûr, même sur des systèmes de fichiers qui sont connus |
wilk@1008 | 668 pour être hostiles aux <quote>locks</quote>, comme NFS). Si un dépôt dispose d'un |
wilk@1008 | 669 <quote>lock</quote>, un processus qui cherche à écrire va attendre un peu avant de |
wilk@1008 | 670 retenter pour voir si le dépôt perd son <quote>lock</quote>, mais si le dépôt garde |
wilk@1008 | 671 trop longtemps son <quote>lock</quote>, le processus qui tente d'écrire va expirer |
wilk@1008 | 672 (time out) après un moment. Cela veut dire par exemple que vos |
wilk@1008 | 673 scripts lancés quotidiennement n'attendront pas toujours et boucleront |
wilk@1008 | 674 si un système plantait sans avertissement, par exemple. (Oui, le |
youshe@1001 | 675 timeout est configurable, de zéro à l'infini.)</para> |
bos@559 | 676 |
bos@559 | 677 <sect3> |
wilk@1008 | 678 <title>Accès <quote>dirstate</quote> sûr</title> |
wilk@1008 | 679 |
wilk@1008 | 680 <para id="x_330">Comme avec les données de révision, Mercurial n'utilise pas |
wilk@1008 | 681 de <quote>lock</quote> pour lire le fichier <quote>dirstate</quote> ; il n'acquiert pas un <quote>lock</quote> pour |
wilk@1008 | 682 y écrire. Pour empêcher la possibilité de lire une copie partiellement |
wilk@1008 | 683 écrite du fichier <quote>dirstate</quote>, Mercurial écrit sur un fichier avec un nom |
wilk@1008 | 684 unique dans le même répertoire que le fichier <quote>dirstate</quote>, ensuite renomme |
youshe@1001 | 685 le fichier temporaire automatiquement en <filename>dirstate</filename>. |
youshe@1001 | 686 Le fichier nommé <filename>dirstate</filename> est ainsi garanti d'être |
youshe@1001 | 687 écrit totalement, et non partiellement.</para> |
bos@559 | 688 |
bos@559 | 689 </sect3> |
bos@559 | 690 </sect2> |
bos@559 | 691 <sect2> |
wilk@1008 | 692 <title>Empêcher les recherches</title> |
youshe@1001 | 693 |
youshe@1001 | 694 <para id="x_331">L'absence de recherche sur les têtes de disques est |
youshe@1001 | 695 critique pour la performance de Mercurial, puisque toute recherche |
youshe@1001 | 696 est beaucoup plus coûteuse comparativement à une grosse opération de |
youshe@1001 | 697 lecture.</para> |
youshe@1001 | 698 |
wilk@1008 | 699 <para id="x_332">C'est pour ça, par exemple, que le <quote>dirstate</quote> est stocké |
wilk@1008 | 700 dans un fichier unique. S'il y avait eu un <quote>dirstate</quote> par répertoire |
wilk@1008 | 701 que Mercurial suivrait, le disque aurait recherché une fois par |
wilk@1008 | 702 répertoire. Au lieu de ça, Mercurial lit entièrement un |
wilk@1008 | 703 fichier unique, en une étape.</para> |
youshe@1001 | 704 |
youshe@1001 | 705 <para id="x_333">Mercurial utilise aussi un schéma <quote>copie à |
youshe@1001 | 706 l'écriture</quote> lorsqu'il clone un dépôt sur un stockage local. |
wilk@1008 | 707 Au lieu de copier chaque <quote>fichier</quote> revlog depuis l'ancien dépôt vers le |
youshe@1001 | 708 nouveau dépôt, il crée un <quote>lien physique</quote>, qui est le |
youshe@1001 | 709 plus court chemin pour dire <quote>Ces deux noms pointent vers le |
youshe@1001 | 710 même fichier</quote>. Lorsque Mercurial est sur le point d'écrire |
youshe@1001 | 711 sur l'un des revlogs de ces fichiers, il vérifie si le nombre de noms |
youshe@1001 | 712 pointant sur ce fichier est plus grand que un. Si c'est le cas, plus |
youshe@1001 | 713 d'un dépôt utilise le fichier, donc Mercurial crée une nouvelle copie |
youshe@1001 | 714 du fichier qui est privée à ce dépôt.</para> |
youshe@1001 | 715 |
youshe@1001 | 716 <para id="x_334">Quelques développeurs de systèmes de gestion de |
wilk@1008 | 717 révisions ont montré que cette idée de faire une copie privée complète |
wilk@1008 | 718 d'un fichier n'est pas vraiment efficace au niveau du |
youshe@1001 | 719 stockage. Bien que ce soit vrai, le stockage est peu onéreux, et |
youshe@1001 | 720 cette méthode donne la plus grande performance lorsque l'on reporte |
youshe@1001 | 721 la plupart des journalisations au système d'exploitation. Un schéma |
youshe@1001 | 722 alternatif réduirait certainement la performance tout en augmentant |
wilk@1008 | 723 la complexité du logiciel, mais la vitesse et la simplicité sont les |
wilk@1008 | 724 clefs du <quote>confort</quote> de l'utilisation |
youshe@1001 | 725 quotidienne.</para> |
youshe@1001 | 726 |
youshe@1001 | 727 </sect2> |
youshe@1001 | 728 <sect2> |
wilk@1008 | 729 <title>Autres contenus du <quote>dirstate</quote></title> |
wilk@1008 | 730 |
wilk@1008 | 731 <para id="x_335">Puisque Mercurial ne vous force pas à signaler que |
wilk@1008 | 732 vous modifiez un fichier, il utilise le <quote>dirstate</quote> pour stocker |
youshe@1001 | 733 certaines informations supplémentaires pour déterminer efficacement |
youshe@1001 | 734 si vous avez ou non modifié un fichier. Pour chaque fichier du |
youshe@1001 | 735 répertoire de travail, il stocke l'heure à laquelle il a été modifié, |
youshe@1001 | 736 ainsi que la taille du fichier à cette heure.</para> |
youshe@1001 | 737 |
youshe@1001 | 738 <para id="x_336">Lorsque vous faites explicitement un <command |
youshe@1001 | 739 role="hg-cmd">hg add</command>, <command role="hg-cmd">hg |
youshe@1001 | 740 remove</command>, <command role="hg-cmd">hg rename</command> ou |
youshe@1001 | 741 <command role="hg-cmd">hg copy</command> sur des fichiers, Mercurial |
andre@1017 | 742 met à jour le <quote>dirstate</quote> afin de savoir que faire lorsque vous |
wilk@1008 | 743 effectuez un <quote>commit</quote>.</para> |
wilk@1008 | 744 |
wilk@1008 | 745 <para id="x_337">Le <quote>dirstate</quote> aide Mercurial à vérifier efficacement le |
wilk@1008 | 746 statut des fichiers dans un dépôt.</para> |
bos@701 | 747 |
bos@701 | 748 <itemizedlist> |
youshe@1001 | 749 <listitem> <para id="x_726"> Lorsque Mercurial vérifie l'état d'un |
youshe@1001 | 750 fichier du répertoire de travail, il compare d'abord la date de |
youshe@1001 | 751 dernière modification du fichier avec celle enregistrée dans le |
wilk@1008 | 752 <quote>dirstate</quote> qui correspond à celle que Mercurial a écrit en dernier sur ce |
andre@1017 | 753 fichier. Si la date de dernière modification correspond à la date |
youshe@1001 | 754 où Mercurial a écrit le fichier, celui ci n'a pas été modifié, |
andre@1017 | 755 donc Mercurial n'a pas besoin de revérifier.</para> </listitem> |
wilk@1008 | 756 <listitem> <para id="x_727"> Si la taille du fichier a changé, celui-ci |
wilk@1008 | 757 a été modifié. Si la date de modification a changé mais que la |
youshe@1001 | 758 taille est restée inchangée, seulement à ce moment là Mercurial |
youshe@1001 | 759 doit vérifier le contenu du fichier pour savoir s'il a été |
youshe@1001 | 760 modifié.</para> </listitem> |
bos@701 | 761 </itemizedlist> |
bos@701 | 762 |
youshe@1001 | 763 <para id="x_728">Enregistrer la date de modification et la taille |
youshe@1001 | 764 réduit grandement le nombre d'opérations de lecture que Mercurial |
youshe@1001 | 765 doit effectuer lorsque l'on utilise une commande comme <command>hg |
youshe@1001 | 766 status</command>. Le résultat est un grand gain de |
youshe@1001 | 767 performance.</para> |
bos@559 | 768 </sect2> |
bos@559 | 769 </sect1> |
belaran@964 | 770 </chapter> |
belaran@964 | 771 |
belaran@964 | 772 <!-- |
belaran@964 | 773 local variables: |
belaran@964 | 774 sgml-parent-document: ("00book.xml" "book" "chapter") |
belaran@964 | 775 end: |
bos@559 | 776 --> |