| 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
|
|
youshe@993
|
7 <para id="x_2e8">À la différence de beaucoup d'outils de gestion de versions,
|
|
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.
|
|
youshe@993
|
10 Bien que leur connaissance ne soit pas nécéssaire, 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,
|
|
youshe@993
|
16 si il m'est facile de garder en tête ce que le logiciel fait lorsque
|
|
youshe@993
|
17 j'accompli 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
|
|
youshe@993
|
22 uns des 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
|
|
youshe@993
|
32 dans le filelog contient assez d'informations pour reconstituer une
|
|
youshe@993
|
33 révision du fichier correspondant. Les filelogs sont des fichiers
|
|
youshe@993
|
34 stockés dans le répertoire <filename role="special"
|
|
youshe@993
|
35 class="directory">.hg/store/data</filename>. Un filelog contient
|
|
youshe@993
|
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
|
|
youshe@993
|
41 historique, son filelog se voit stocker 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
|
|
youshe@993
|
45 et le filelog 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
|
|
youshe@993
|
50 leurs filelogs 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
|
|
youshe@993
|
62 les fichiers dont il gère le suivi. Chaque entrée dans ce manifest
|
|
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>
|
|
youshe@1001
|
70 <title>Enregistrer les informations des changeset</title>
|
|
youshe@1001
|
71
|
|
youshe@1001
|
72 <para id="x_2ef">Le <emphasis>changelog</emphasis> contient les
|
|
youshe@1001
|
73 informations sur chaque changeset. Chaque révision enregistre qui a
|
|
youshe@1001
|
74 committé un changement, le commentaire du changeset, d'autres
|
|
youshe@1001
|
75 morceaux d'information relatives au changeset et la révision du
|
|
youshe@1001
|
76 manifest à 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
|
|
youshe@1001
|
82 <para id="x_2f0">A l'intérieur d'un changelog, d'un manifest, ou d'un
|
|
youshe@1001
|
83 filelog, 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
|
|
youshe@1001
|
90 <para id="x_2f1">Pour chaque changeset dans un dépôt, il y a exactement
|
|
youshe@1001
|
91 une révision stockée dans le changelog. Chaque révision du changelog
|
|
youshe@1001
|
92 contient un pointeur vers une unique révision du manifest. Une
|
|
youshe@1001
|
93 révision du manifeste garde un pointeur vers une unique révision pour
|
|
youshe@1001
|
94 chaque filelog suivi lorsque le changeset 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
|
|
youshe@1001
|
105 <para id="x_2f3">Comme l'illustration le monde, il
|
|
youshe@1001
|
106 <emphasis>n'</emphasis>y a <emphasis>pas</emphasis> de relation
|
|
youshe@1001
|
107 <quote>un à un</quote> entre les révisions dans un changelog,
|
|
youshe@1001
|
108 manifest ou filelog. Si un fichier que Mercurial suit n'a pas changé
|
|
youshe@1001
|
109 entre deux changesets, l'entrée pour ce fichier dans les deux
|
|
youshe@1001
|
110 révisions du manifest pointera vers la même révision de son filelog
|
|
youshe@1001
|
111 <footnote> <para id="x_725">Il est possible (bien qu'inhabituel)
|
|
youshe@1001
|
112 qu'un manifest reste le même entre deux changesets, auquel cas
|
|
youshe@1001
|
113 l'entrée du changelog pour ces changesets pointera vers la même
|
|
youshe@1001
|
114 révision du manifest.</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
|
|
youshe@1001
|
122 <para id="x_2f4">Les fondements des changelogs, des manifests et des
|
|
youshe@1001
|
123 filelogs sont fournis par une unique structure appelée le
|
|
bos@559
|
124 <emphasis>revlog</emphasis>.</para>
|
|
bos@559
|
125
|
|
bos@559
|
126 <sect2>
|
|
youshe@1001
|
127 <title>stockage efficace</title>
|
|
youshe@1001
|
128
|
|
youshe@1001
|
129 <para id="x_2f5">Le revlog fournit un stockage efficace des révision en
|
|
youshe@1001
|
130 utilisant un mécanisme <emphasis>delta</emphasis>. A lieu de stocker
|
|
youshe@1001
|
131 une copie complète d'un fichier à chaque révision, il stocke les
|
|
youshe@1001
|
132 changements requis pour transformer une révision plus ancienne en la
|
|
youshe@1001
|
133 nouvelle révision. Pour plusieurs type 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
|
|
youshe@1001
|
137 <para id="x_2f6">Certains systèmes de gestion de révisions obselè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
|
|
youshe@1001
|
150 données à la fin d'un fichier revlog. Il ne modifie jamais la section
|
|
youshe@1001
|
151 d'un fichier après qu'il l'ait écrite. C'est à la foit 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
|
|
youshe@1001
|
155 <para id="x_2f8">De plus, Mercurial traite chaque écriture comme une
|
|
youshe@1001
|
156 partie d'une <emphasis>transaction</emphasis> qui peut comprendre
|
|
youshe@1001
|
157 plusieurs fichiers. Une transaction est <emphasis>atomique</emphasis>
|
|
youshe@1001
|
158 : spot 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
|
|
youshe@1001
|
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
|
|
youshe@1001
|
179 <quote>snapshot</quote>. (Certains basent le snapshot sur la plus
|
|
youshe@1001
|
180 vieille révision, d'autres sur la plus récente.) Pour reconstruire
|
|
youshe@1001
|
181 une révision spécifique, vous devez d'abord lire le snapshot, et
|
|
youshe@1001
|
182 ensuite toutes les révisions entre le snapshot 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">
|
|
youshe@1001
|
188 <title>Snapshot d'un revlog, 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
|
|
youshe@1001
|
195 <para id="x_2fc">L'inovation que Mercurial apporte à ce problème est
|
|
youshe@1001
|
196 simple mais effective. Une fois que la quantité cumulée de deltas
|
|
youshe@1001
|
197 d'informations stockées depuis le dernier snapshot excède un seuil
|
|
youshe@1001
|
198 fixé, il stock un nouveau snapshot (compréssé biensû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
|
|
youshe@1001
|
205 l'idée. Dans une entrée d'un fichier d'index de revlog, Mercurial
|
|
youshe@1001
|
206 stock l'intervale 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>
|
|
youshe@1001
|
210 <title>En amont : 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
|
|
youshe@1001
|
213 avez déjà regardé un programme TV par cable ou par un service
|
|
youshe@1001
|
214 satellite, vous devez savoir que la plupart des schémas de
|
|
youshe@1001
|
215 compression vidéo stockent chaque frame de vidéo comme un delta vis
|
|
youshe@1001
|
216 à vis de la frame 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
|
|
youshe@1001
|
235 identifiants pour les révisions. Le hash d'identification d'un
|
|
youshe@1001
|
236 changeset que vous voyez comme utilisateur final proviennent des
|
|
youshe@1001
|
237 révisions du changelog. Bien que les filelogs et le manifest
|
|
youshe@1001
|
238 utilisent aussi des hash, Mercurial ne les utilise qu'en arrière
|
|
youshe@1001
|
239 plan.</para>
|
|
youshe@1001
|
240
|
|
youshe@1001
|
241 <para id="x_302">Mercurial vérifie que les hash 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é,
|
|
youshe@1001
|
244 il se pleindra 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
|
|
youshe@1001
|
247 récupérations, l'utilisation de Mercurial de snapshots périodiques
|
|
youshe@1001
|
248 fait qu'il est plus robuste contre la corruption partielle de
|
|
youshe@1001
|
249 données. Si un revlog 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
|
|
youshe@1001
|
252 sections non corrompues du revlog, avant et après la section
|
|
youshe@1001
|
253 corrompue. Ceci ne serait pas possible à partir d'un modèle de
|
|
youshe@1001
|
254 stockage delta 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
|
|
youshe@1001
|
261 <para id="x_304">Chaque entrée dans un revlog Mercurial connaît
|
|
youshe@1001
|
262 l'identité de l'ancètre immédiat de la révision, habituellement référé
|
|
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
|
|
youshe@1001
|
265 hash spécial, appelé le <quote>null ID</quote> pour représenter l'idée
|
|
youshe@1001
|
266 qu'<quote>il n'y a pas de parent ici</quote>. Ce hash 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
|
|
youshe@1001
|
270 voir un exemple de la structure conceptuelle d'un revlog. Les filelogs,
|
|
youshe@1001
|
271 manifests et changelogs ont tous cette même structure ; ils difèrent
|
|
youshe@1001
|
272 simplement dans le type de donnée stockée dans chaque delta ou
|
|
bos@559
|
273 snapshot.</para>
|
|
bos@559
|
274
|
|
youshe@1001
|
275 <para id="x_306">La première révision d'un revlog (au bas de l'image) a
|
|
youshe@1001
|
276 le null ID 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
|
|
youshe@1001
|
278 révision parent et la seconde contient le null ID, 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">
|
|
bos@591
|
285 <title>The conceptual structure of a revlog</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
|
|
youshe@1001
|
296 <para id="x_307">Dans un répertoire de travail, Mercurial stock une image
|
|
youshe@1001
|
297 des fichiers du dépôt à un changeset particulier.</para>
|
|
youshe@1001
|
298
|
|
youshe@1001
|
299 <para id="x_308">Le répertoire de travail <quote>sait</quote> quel
|
|
youshe@1001
|
300 changeset il contient. Lorsque vous mettez à jour (update) le
|
|
youshe@1001
|
301 répertoire de travail à un certain changeset, Mercurial regarde la
|
|
youshe@1001
|
302 révision appropriée du manifest pour trouver quels fichier il suivait
|
|
youshe@1001
|
303 au moment où le changeset a été committé, et quelle révision de chaque
|
|
youshe@1001
|
304 fichier était alors courante. Il recrée ensuite une copie de chacun de
|
|
youshe@1001
|
305 ces fichiers, avec le même contenu qu'ils avaient lorsque le changeset
|
|
youshe@1001
|
306 a été committé.</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
|
|
youshe@1001
|
312 dirstate sont le changeset vers lequel le répertoire de travail se met
|
|
youshe@1001
|
313 à jour (update), et tous les fichiers que Mercurial suit dans le
|
|
youshe@1001
|
314 répertoire de travail. Il permet aussi à Mercurial se connaître
|
|
youshe@1001
|
315 rapidement les fichiers modifiés, en enregistrant leurs heures de
|
|
youshe@1001
|
316 dernière modification et leur taille.</para>
|
|
youshe@1001
|
317
|
|
youshe@1001
|
318 <para id="x_30a">Puisqu'une révision de revlog a des emplacements pour
|
|
youshe@1001
|
319 deux parents et peut représenter aussi bien une révision normale (avec
|
|
youshe@1001
|
320 un parent) ou une fusion de deux révisions anciennes, le dirstate a des
|
|
youshe@1001
|
321 emplacements pour deux parents. Lorsque vous utilisez la commande
|
|
youshe@1001
|
322 <command role="hg-cmd">hg update</command>, le changeset que vous
|
|
youshe@1001
|
323 mettez à jour est stocké dans l'emplacement du <quote>premier
|
|
youshe@1001
|
324 parent</quote>, et le null ID 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
|
|
youshe@1001
|
327 rempli avec le changeset à 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>
|
|
youshe@1001
|
332 <title>Que se passe-t-il lorsque vous committez</title>
|
|
youshe@1001
|
333
|
|
youshe@1001
|
334 <para id="x_30b">Le dirstate stock les informations sur les parents
|
|
youshe@1001
|
335 pour plusqu'un simple livre de stockage. Mercurial utilise les
|
|
youshe@1001
|
336 parents du distate comme <emphasis>les parents d'un nouveau
|
|
youshe@1001
|
337 changeset</emphasis> lorsque vous committez.</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
|
|
youshe@1001
|
347 normal d'un répertoire de travail, où il n'y a qu'un seul changeset
|
|
youshe@1001
|
348 comme parent. Ce changeset est le <emphasis>tip</emphasis>, le
|
|
youshe@1001
|
349 changeset 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
|
|
youshe@1001
|
353 commit</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
|
|
youshe@1001
|
361 <para id="x_30f">Il est utile de penser du répertoire de travail qu'il
|
|
youshe@1001
|
362 est <quote>le changeset que je vais committer</quote>. Chaque fichier
|
|
youshe@1001
|
363 que vous dites à mercurial d'ajouter, de supprimer, de renommer ou de
|
|
youshe@1001
|
364 copier va être reflété dasn ce changeset, tout comme les
|
|
youshe@1001
|
365 modifications de n'importe quel fichier que Mercurial est déjà en
|
|
youshe@1001
|
366 train de suite ; le nouveau changeset 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
|
|
youshe@1001
|
370 parents du répertoire de travail, ainsi, le premier parents est l'ID
|
|
youshe@1001
|
371 du nouveau changeset, et le second, le nullID. Ceci est illustré dans
|
|
youshe@1001
|
372 <xref linkend="fig:concepts:wdir-after-commit"/>. Mercurial ne touche
|
|
youshe@1001
|
373 à aucun des fichiers du répertoire de travail lorsque vous committez
|
|
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
|
|
youshe@1001
|
381 <para id="x_311">Il est parfaitement normal de faire un update du
|
|
youshe@1001
|
382 répertoire de travail à un changeset autre que le tip courant. Par
|
|
youshe@1001
|
383 exemple, vous pourriez vouloir savoir ce à quoi votre projet
|
|
youshe@1001
|
384 ressemblait le dernier Mardi, ou regarder le changeset qui a
|
|
youshe@1001
|
385 introduit un bug. Dans des cas comme ça, la chose naturelle à faire
|
|
youshe@1001
|
386 est de faire un update du répertoire de travail au changeset qui vous
|
|
youshe@1001
|
387 intéresse, et ensuite d'en examiner les fichiers pour regarder leurs
|
|
youshe@1001
|
388 contenus comme ils l'étaient lorsque vous avez commité ce changeset.
|
|
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">
|
|
youshe@1001
|
393 <title>Le répertoire de travail, "updaté" pour un changeset 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
|
|
youshe@1001
|
401 <para id="x_313">En ayant fait un update du répertoire de travail vers
|
|
youshe@1001
|
402 un changeset plus ancien, qu'est-ce qu'il se passe si vous faites des
|
|
youshe@1001
|
403 changements et ensuite committez ? Mercurial se comporte comme je
|
|
youshe@1001
|
404 l'ai fait remarqué plus haut. Les parents du répertoire de travail
|
|
youshe@1001
|
405 deviennent les parents du nouveau changeset. Ce nouveau changeset n'a
|
|
youshe@1001
|
406 pas d'enfant, donc il devient le nouveau tip. Le dépôt contient
|
|
youshe@1001
|
407 maintenant deux changesets qui n'ont pas d'enfant ; on appelle ceci
|
|
youshe@1001
|
408 des <emphasis>heads</emphasis>. Vous pouvez voir la structire 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">
|
|
youshe@1001
|
412 <title>Après un commit fait pendant la synchronisation avec un ancien
|
|
youshe@1001
|
413 changeset</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>
|
|
youshe@1001
|
421 <para id="x_315">Si vous êtes nouveau à 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
|
|
youshe@1001
|
425 pull</command> <emphasis>ne fait pas</emphasis> d'update 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
|
|
youshe@1001
|
428 rester synchroniser au même changeset qu'il l'était avant le pull.
|
|
youshe@1001
|
429 Si vous faites des changements et committez ensuite, vous allez
|
|
youshe@1001
|
430 créer une nouvelle head puisque votre répertoire de travail n'est
|
|
youshe@1001
|
431 pas synchronisé à ce que le tip actuel est. Pour combiner les
|
|
youshe@1001
|
432 opérations d'un pull suivi d'un update, exécutez run <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
|
|
youshe@1001
|
436 guillemets parce que tous ce dont vous avez besoin de faire pour
|
|
youshe@1001
|
437 rectifier la situation où vous avez créé une nouvelle head 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
|
|
youshe@1001
|
453 changeset 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">
|
|
youshe@1001
|
457 <title>Fusionner (merge) deux heads</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
|
|
youshe@1001
|
465 travail pour fusionner les fichiers gérés dans les deux changesets.
|
|
youshe@1001
|
466 Un peu simplifié, le processus de fusion fonctionne comme ça : pour
|
|
youshe@1001
|
467 chaque fichier dans le manifest de chaque changeset.</para>
|
|
youshe@1001
|
468
|
|
bos@559
|
469 <itemizedlist>
|
|
youshe@1001
|
470 <listitem><para id="x_31a">Si aucun changeset n'a modifié un fichier,
|
|
youshe@1001
|
471 ne rien faire avec ce fichier.</para> </listitem>
|
|
youshe@1001
|
472 <listitem><para id="x_31b">Si un changeset 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>
|
|
youshe@1001
|
475 <listitem><para id="x_31c">Si un changeset 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>
|
|
youshe@1001
|
478 <listitem><para id="x_31d">Si un changeset 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>
|
|
youshe@1001
|
482 <listitem><para id="x_31e">Si chacun des chengeset 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
|
|
youshe@1001
|
485 des entrées de l'utilisateur.</para></listitem>
|
|
youshe@1001
|
486 <listitem><para id="x_31f">Si un changeset 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
|
|
youshe@1001
|
492 cas anguleux&emdash;mais ceux-ci sont des chois plus communs qui sont
|
|
youshe@1001
|
493 invoqués pendant une fusion (merge). Comme vous pouvez le voir, la
|
|
youshe@1001
|
494 plupart des cas sont entièrement automatiques, et effectivement, la
|
|
youshe@1001
|
495 plupart des fusions (merge) se terminent automatiquement, sans avoir
|
|
youshe@1001
|
496 besoin d'entrées 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
|
|
youshe@1001
|
499 committez après un merge, 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
|
|
youshe@1001
|
502 merge</command> ait terminé, le répertoire de travail a deux
|
|
youshe@1001
|
503 parents ; ceux ci vont devenir les parents du nouveau
|
|
youshe@1001
|
504 changeset.</para>
|
|
youshe@1001
|
505
|
|
youshe@1001
|
506 <para id="x_322">Mercurial vous permet d'exécuter de multiples fusions,
|
|
youshe@1001
|
507 mais vous devez committer le résultat de chaque fusion individuelle
|
|
youshe@1001
|
508 comme vous avancez. Ceci est nécessaire puisque Mercurial ne stock
|
|
youshe@1001
|
509 que deux parents pour chaque révision et le répertoire de travail.
|
|
youshe@1001
|
510 Alors qu'il serait techniquement faisble de fusionner de multiples
|
|
youshe@1001
|
511 changesets en même temps, Mercurial interdit cette simplicité. Avec
|
|
youshe@1001
|
512 des fusions multplus, les risques de confision utilisateur, de
|
|
youshe@1001
|
513 conflits néfastes de résolutions, et faire une pagaille d'une fusion
|
|
youshe@1001
|
514 grossiraient intollérablement.</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
|
|
youshe@1001
|
522 révision fait peu ou pas attention à un <emphasis>nom</emphasis> 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
|
|
youshe@1001
|
528 dite d'exécuter un renommage ou une copie. Il utilise ces metadata
|
|
youshe@1001
|
529 durant une fusion pour faire les bonnes choses dans le cas d'un
|
|
youshe@1001
|
530 merge. 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
|
|
youshe@1001
|
532 aura les éditions appliquées.</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
|
|
youshe@1001
|
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 à
|
|
youshe@1001
|
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
|
|
youshe@1001
|
545 trouve personnellement intéressante. Je détaillerai quelques un d'eux
|
|
youshe@1001
|
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
|
|
youshe@1001
|
548 de la quantité de pensées qu'il y a derrière un système bien
|
|
youshe@1001
|
549 défini.</para>
|
|
youshe@1001
|
550
|
|
youshe@1001
|
551 <sect2>
|
|
youshe@1001
|
552 <title>Compression élégante</title>
|
|
youshe@1001
|
553
|
|
youshe@1001
|
554 <para id="x_324">Lorsque cela est approprié, Mercurial stocke les
|
|
youshe@1001
|
555 snapshots et deltas sous une forme compressée. Il le fait en
|
|
youshe@1001
|
556 <emphasis>essayant</emphasis> toujours de compression un snapshot ou
|
|
youshe@1001
|
557 un delta, mais en ne stockant la version compression 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
|
|
youshe@1001
|
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
|
|
youshe@1001
|
572 snapshot complet du ficheir, alors il stocke le snapshot, en gagnant
|
|
youshe@1001
|
573 encore de la place en comparaison à une approche naïve delta
|
|
youshe@1001
|
574 seulement.</quote>
|
|
bos@559
|
575
|
|
bos@559
|
576 <sect3>
|
|
youshe@1001
|
577 <title>Recompression 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
|
|
youshe@1001
|
581 <quote>deflate</quote> (le même que celui utilisé pour le format
|
|
youshe@1001
|
582 d'archive populaire <literal>zip</literal>), qui est un bon
|
|
youshe@1001
|
583 comprimis 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
|
|
youshe@1001
|
588 <para id="x_328">Si la connexion est au dessus de 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
|
|
youshe@1001
|
591 Burrows-Wheeler utilisé principalement par le package de
|
|
youshe@1001
|
592 compression <literal>bzip2</literal>). Cette combinaison de
|
|
youshe@1001
|
593 l'algorithme et de compression du flux entier (plutôt que pour une
|
|
youshe@1001
|
594 révision à la fois) réduit substanciellement le nombre de bits qui
|
|
youshe@1001
|
595 sont transférés, résultant dans une performance réseau accrue sur
|
|
youshe@1001
|
596 la plupart des supports.</para>
|
|
youshe@1001
|
597
|
|
youshe@1001
|
598 <para id="x_329">Si la connexion est au dessus de
|
|
youshe@1001
|
599 <command>ssh</command>, Mercurial <emphasis>ne</emphasis>
|
|
youshe@1001
|
600 recompresse <emphasis>pas</emphasis> le flux puisque
|
|
youshe@1001
|
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
|
|
youshe@1001
|
604 <filename>.hgrc</filename> de votre répertoire personnale comme ci
|
|
youshe@1001
|
605 dessous.</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>
|
|
youshe@1001
|
613 <title>Ordres de Lecture/Écriture et atomicité</title>
|
|
youshe@1001
|
614
|
|
youshe@1001
|
615 <para id="x_32a">Ajouter à la fin des fichiers n'est pas toute
|
|
youshe@1001
|
616 l'histoire lorsque l'on cherche à garantir que le lecteur ne verra
|
|
youshe@1001
|
617 pas qu'une écriture partielle. Si vous relisez <xref
|
|
youshe@1001
|
618 linkend="fig:concepts:metadata"/>, les révisions dans le changelog
|
|
youshe@1001
|
619 pointent vers les révisions dans le manifest, et les révisions du
|
|
youshe@1001
|
620 manifest pointent vers les révisions du filelog. Cette hiérarchie est
|
|
youshe@1001
|
621 délibérée.</para>
|
|
youshe@1001
|
622
|
|
youshe@1001
|
623 <para id="x_32b">L'écriture commence une transaction en écrivant dans
|
|
youshe@1001
|
624 le filelog et dans les données du manifest, et n'écrit aucune donnée
|
|
youshe@1001
|
625 changelog tant que ce n'est pas terminé. La lecture commence en
|
|
youshe@1001
|
626 lisant les données du changelog, puis les données du manifest, et
|
|
youshe@1001
|
627 enfin les données du filelog.</para>
|
|
youshe@1001
|
628
|
|
youshe@1001
|
629 <para id="x_32c">Puisque que l'écriture ne finit pas d'écrire les
|
|
youshe@1001
|
630 données du filelog et du manifest avant d'écrire dans le changelog,
|
|
youshe@1001
|
631 la lecture ne verra jamais un pointeur vers une révision du manifest
|
|
youshe@1001
|
632 partiellement écrite à partir du changelog, et ne lira jamais un
|
|
youshe@1001
|
633 pointeur vers une révision du filelog partiellement écrite dans le
|
|
youshe@1001
|
634 manifest.</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
|
|
youshe@1001
|
641 de l'atomicite 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
|
|
youshe@1001
|
644 lecture a lieue. Ceci a un grand impact sur la fiabilité ; vous
|
|
youshe@1001
|
645 pouvez avoir un nombre arbitraire de processus Mercurial qui lisent
|
|
youshe@1001
|
646 dans risque en même temps les données d'un dépôt, 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
|
|
youshe@1001
|
653 votre dépôt pour qu'ils soient capable de faire un clone ou un pull
|
|
youshe@1001
|
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
|
|
youshe@1001
|
657 fonctionnalité commune à travers les systèmes de gestion de révision,
|
|
youshe@1001
|
658 donc ne prenez pas ça pour garanti ! 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
|
|
youshe@1001
|
661 écriture, sur au moins un dépertoire, ce qui provoque biensûr toutes
|
|
youshe@1001
|
662 sortes de problèmes néfastes et ennuyants relatifs à la sécurité et à
|
|
youshe@1001
|
663 l'administration.)</para>
|
|
youshe@1001
|
664
|
|
youshe@1001
|
665 <para id="x_32f">Mercurial utilise des locs pour assurer qu'un seul
|
|
youshe@1001
|
666 processus peut écrire dans le dépôt à un moment donné (le mécanisme
|
|
youshe@1001
|
667 de lock est sûr, même sur des systèmes de fichiers qui sont connus
|
|
youshe@1001
|
668 pour être hostiles aux locks, comme NFS). Si un dépôt dispose d'un
|
|
youshe@1001
|
669 lock, un processus qui cherche à écrire va attendre un peu avant de
|
|
youshe@1001
|
670 retenter pour voir si le dépôt perd son lock, mais le dépôt garde
|
|
youshe@1001
|
671 trop longtemps son lock, le processus qui tente d'écrire va expirer
|
|
youshe@1001
|
672 (time out) après un moment. Celà veut dire par exemple que vous
|
|
youshe@1001
|
673 scripts lancés quotidiennement n'attendront pas toujours et boucler
|
|
youshe@1001
|
674 si un système crashait 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>
|
|
youshe@1001
|
678 <title>Accès dirstate sûr</title>
|
|
youshe@1001
|
679
|
|
youshe@1001
|
680 <para id="x_330">Comme avec les données de révision, Mercurial ne prend pas
|
|
youshe@1001
|
681 de lock pour lire le fichier dirstate ; il n'acquier pas un lock pour
|
|
youshe@1001
|
682 y écrire. Pour empécher la possibilité de lire une copie partiellement
|
|
youshe@1001
|
683 écrite du fichier dirstate, Mercurial écrit à un fichier avec un nom
|
|
youshe@1001
|
684 unique dans le même répertoire que le fichier dirstate, 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>
|
|
youshe@1001
|
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
|
|
youshe@1001
|
699 <para id="x_332">C'est pour ça, par exemple, que le dirstate est stocké
|
|
youshe@1001
|
700 dans un unique fichier. S'il y avait eu un dirstate par répertoire
|
|
youshe@1001
|
701 que Mercurial suivait, le disque aurait recherché une fois par
|
|
youshe@1001
|
702 répertoire. Au lieu de ça, Mercurial lit entièrement un unique
|
|
youshe@1001
|
703 fichier, 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.
|
|
youshe@1001
|
707 Au lieu de copier chaque fichier 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
|
|
youshe@1001
|
717 révision ont montré que cette idée de faire une copie privée complète
|
|
youshe@1001
|
718 d'un fichier n'est pas vraiment efficace dans son utilisation 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
|
|
youshe@1001
|
723 la complexité du logiciel, mais la vitesse et la simplicité sont els
|
|
youshe@1001
|
724 clefs du <quote>sentiment</quote> de l'utilisation
|
|
youshe@1001
|
725 quotidienne.</para>
|
|
youshe@1001
|
726
|
|
youshe@1001
|
727 </sect2>
|
|
youshe@1001
|
728 <sect2>
|
|
youshe@1001
|
729 <title>Autres contenus du dirstate</title>
|
|
youshe@1001
|
730
|
|
youshe@1001
|
731 <para id="x_335">Puisque Mercurial ne vous force pas à dire lorsque
|
|
youshe@1001
|
732 vous modifiez un fichier, il utilise le dirstate 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
|
|
youshe@1001
|
742 met à jour le dirstate afin de savoir quoi faire lorsque vous
|
|
youshe@1001
|
743 effectuez un commit.</para>
|
|
youshe@1001
|
744
|
|
youshe@1001
|
745 <para id="x_337">Le dirstate aide Mercurial à vérifier efficacement le
|
|
youshe@1001
|
746 status 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
|
|
youshe@1001
|
752 dirstate qui correspond à Mercurial a écrit en dernier sur ce
|
|
youshe@1001
|
753 fichier. Si le temps de dernière modification correspond au temps
|
|
youshe@1001
|
754 où Mercurial a écrit le fichier, celui ci n'a pas été modifié,
|
|
youshe@1001
|
755 donc mercurial n'a pas besoin de revérifier.</para> </listitem>
|
|
youshe@1001
|
756 <listitem> <para id="x_727"> Si la taille du fichier a changé, celui
|
|
youshe@1001
|
757 ci 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 -->
|
