hgbook
view fr/ch05-daily.xml @ 988:72de97557f11
French translation : 75% of ch05-daily translated
| author | Frédéric Bouquet <youshe.jaalon@gmail.com> |
|---|---|
| date | Thu Sep 10 01:08:16 2009 +0200 (2009-09-10) |
| parents | f0110009e946 |
| children | a3a9eabfe2a4 |
line source
1 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
3 <chapter id="chap:daily">
4 <?dbhtml filename="mercurial-in-daily-use.html"?>
5 <title>Mercurial in daily use</title>
7 <sect1>
8 <title>Telling Mercurial which files to track</title>
10 <para id="x_1a3">Mercurial ne fonctionne pas avec les fichiers de votre
11 dépôt tant que vous ne lui avez pas dit de les gérer. La commande
12 <command role="hg-cmd">hg status</command> vous dira quels fichier sont
13 inconnus de Mercurial. Il utilise un
14 <quote><literal>?</literal></quote> pour montrer ces fichiers.</para>
16 <para id="x_1a4">Pour informer Mercurial de suivre un fichier, utilisez
17 la commande <command role="hg-cmd">hg add</command>. Une fois que vous
18 avez ajouté un fichier, la ligne correspondante à ce fichier dans la
19 sortie de <command role="hg-cmd">hg status</command> change de
20 <quote><literal>?</literal></quote> à
21 <quote><literal>A</literal></quote>.</para>
23 &interaction.daily.files.add;
25 <para id="x_1a5">Après avoir exécuté un <command role="hg-cmd">hg
26 commit</command>, les fichiers que vous avez ajouté avant le commit
27 ne seront plus listé dans la sortie de <command role="hg-cmd">hg
28 status</command>. La raison de ceci est que par défaut, <command
29 role="hg-cmd">hg status</command> ne vous montre que les fichiers
30 <quote>intéressants</quote> &emdash;ceux que vous avez (par exemple)
31 modifiés, supprimés ou renommés. Si vous avez un dépôt qui contient un
32 millier de fichiers, vous ne voudrez certainement que rarement entendre
33 parler des fichiers que Mercurial suit, mais qui n'ont pas changés.
34 (Vous pouvez quand même avoir cette information, nous y reviendrons
35 plus tard.)</para>
37 <para id="x_1a6">Une fois que vous ajoutez un fichier, Mercurial ne fait
38 rien du tout avec celui-ci immédiatement. A lieu de ça, il va prendre
39 un "snapshot" de l'état du fichier la prochaine fois que vous
40 exécuterez un commit. Il continuera ensuite à suivre les changements
41 que vous avez fait au fichier chaque fois que vous committerez, jusqu'à
42 ce que vous supprimiez le fichier.</para>
44 <sect2>
45 <title>Nommage des fichiers explicite versus implicite</title>
47 <para id="x_1a7">Un comportement utile que Mercurial possède est que si
48 vous passez le nom d'un répertoire à une commande, toute commande
49 Mercurial la traitera comme <quote>Je veux opérer sur chaque fichier
50 dans ce répertoire et ses sous-répertoires</quote>.</para>
52 &interaction.daily.files.add-dir;
54 <para id="x_1a8">Remarquez que dans cet exemple, Mercurial affiche le
55 nom des fichiers qu'il a ajouté, alors qu'il ne l'a pas fait lorsque
56 nous avons ajouté le fichier nommé <filename>myfile.txt</filename>
57 dans l'exemple précédent.</para>
59 <para id="x_1a9">Ce qu'il se passe est que dans le premier cas, nous
60 avons nommé explicitement le fichier à ajouter sur la ligne de
61 commande. La supposition que Mercurial fait dans ces cas est que nous
62 savons ce que nous faisons, il n'affiche dont rien en sortie.</para>
64 <para id="x_1aa">Cependant, lorsque nous avons
65 <emphasis>implicitement</emphasis> donné les fichiers à l'aide du nom
66 d'un répertoire, Mercurial prend le l'initiative d'afficher le nom de
67 chaque fichier avec lequel il fait quelque chose. Ceci clarifie ce
68 qu'il se passe, et réduit la probabilité d'une surprise silencieuse
69 et désagréable. Ce comportement est commun à la plupart des commandes
70 Mercurial.</para>
71 </sect2>
72 <sect2>
73 <title>Mercurial suit les fichiers, pas les répertoires</title>
75 <para id="x_1ab">Mercurial ne suit pas les informations sur les
76 répertoire. En contrepartie, il suit le chemin vers un fichier. Avant
77 de créer un fichier, il crée au préalable les répertoires manquants
78 dans le chemin. Après avoir supprimé un fichier, il supprime chaque
79 répertoire vide qui apparaît dans le chemin du fichier. Ceci apparaît
80 comme une distinction triviale, cependant, ceci a une conséquence
81 pratique mineure : il n'est pas possible de représenter un répertoire
82 totalement vide dans Mercurial.</para>
84 <para id="x_1ac">Les répertoires vides sont rarement utiles. Il existe
85 des solutions alternatives et non intrusives que vous pouvez utiliser
86 pour obtenir l'effet approprié. Les développeurs de Mercurial ont
87 ainsi pensé que la complexité requise pour gérer les répertoires
88 n'était pas aussi importante que le bénéfice que cette fonctionnalité
89 apporterait.</para>
91 <para id="x_1ad">Si vous avez besoin d'un répertoire vide dans votre
92 dépôt, il existe quelques façons d'y arriver. L'une d'elles est de
93 créer un répertoire et d'ensuite, faire un <command role="hg-cmd">hg
94 add</command> sur un fichier <quote>hidden</quote> file dans ce
95 répertoire. Sur les fichiers de type Unix, tout fichier dont le nom
96 commence avec un point (<quote><literal>.</literal></quote>) est
97 considéré comme caché par la plupart des commandes et outils
98 graphiques. Cette approche est illustré ci-après.</para>
100 &interaction.daily.files.hidden;
102 <para id="x_1ae">Une autre façon de s'attaquer au besoin d'un
103 répertoire vide est de simplement en créer un dans vos scripts
104 de construction avant qu'ils n'en aient le besoin.</para>
105 </sect2>
106 </sect1>
108 <sect1>
109 <title>Comment arrêter de suivre un fichier</title>
111 <para id="x_1af">Une fois que vous décidez qu'un fichier n'appartient
112 plus à votre dépôt, utilisez la commande <command role="hg-cmd">hg
113 remove</command>. Ceci supprime le fichier et informe Mercurial
114 d'arrêter de le suivre (ce qui prendra effet lors du prochain commit).
115 Un fichier supprimé est représenté dans la sortie de la commande
116 <command role="hg-cmd">hg status</command> par un
117 <quote><literal>R</literal></quote>.</para>
119 &interaction.daily.files.remove;
121 <para id="x_1b0">Après avoir fait un <command role="hg-cmd">hg
122 remove</command> sur un fichier, Mercurial ne suivra plus aucun
123 changement sur ce fichier, même si vous recréez un fichier avec le même
124 nom dans le répertoire de travail. Si vous recréez un fichier avec le
125 même nom et que vous désirez que Mercurial suive ce dernier, faite
126 simplement un <command role="hg-cmd">hg add</command> sur celui-ci.
127 Mercurial saura alors que le nouveau fichier ne fait pas référence à
128 l'ancien fichier qui portait le même nom.</para>
130 <sect2>
131 <title>Supprimer un fichier n'affecte pas son historique</title>
133 <para id="x_1b1">Il est important de comprendre que supprmer un fichier
134 n'a que deux effets.</para>
136 <itemizedlist>
137 <listitem><para id="x_1b2">Il supprime la version actuelle de ce
138 fichier du répertoire de travail.</para>
139 </listitem>
140 <listitem><para id="x_1b3">Il arrête, à partir du prochain commit, le
141 suivi de Mercurial sur les changements qui ont lieu sur ce
142 fichier.</para>
143 </listitem></itemizedlist>
145 <para id="x_1b4">Supprimer un fichier <emphasis>n'</emphasis>affecte en
146 <emphasis>aucun</emphasis> cas l'<emphasis>historique</emphasis> du
147 fichier.</para>
149 <para id="x_1b5">Si vous mettez à jour le répertoire de travail à un
150 changeset qui a été commité alors que le fichier que vous venez de
151 supprimer était encore suivi, ce fichier réaparaittra dans le
152 répertoire de travail, avec le contenu qu'il avait lorsque vous aviez
153 commité ce changeset. Si vous mettez à jour (update) le répertoire de
154 travail à un changeset ultérieur, dans lequel le fichier a été
155 supprimé, Mercurial supprimera une nouvelle fois le fichier du
156 répertoire de travail.</para>
157 </sect2>
159 <sect2>
160 <title>Fichier manquants</title>
162 <para id="x_1b6">Mercurial considère qu'un fichier que vous avez
163 supprimé sans utiliser<command role="hg-cmd">hg remove</command>
164 comme étant <emphasis>manquant</emphasis>. Un fichier manquant est
165 représenté avec un <quote><literal>!</literal></quote> en sortie de
166 <command role="hg-cmd">hg status</command>.
167 Les commandes Mercurial ne feront rien avec les fichiers
168 manquants.</para>
170 &interaction.daily.files.missing;
172 <para id="x_1b7">Si votre dépôt contient un fichier que <command
173 role="hg-cmd">hg status</command> repporte comme manquant, et que
174 vous voulez que ce fichier reste supprimé, vous pouvez exécuter
175 <command role="hg-cmd">hg remove <option
176 role="hg-opt-remove">--after</option></command> à tout moment
177 pour dire à Mercurial que vous aviez bien voulu supprimer ce
178 fichier.</para>
180 &interaction.daily.files.remove-after;
182 <para id="x_1b8">D'un autre coté, si vous avez supprimé le fichier
183 manquant par accident, donnez à la commande <command role="hg-cmd">hg
184 revert</command> le nom du fichier à retrouver. Il réaparaitra dans
185 sa forme non modifiée.</para>
187 &interaction.daily.files.recover-missing;
189 </sect2>
191 <sect2>
192 <title>Entre nous : Pourquoi dire explicitement à Mercurial de supprimer un
193 fichier ?</title>
195 <para id="x_1b9">Vous pourriez vous demander pourquoi il est nécessaire
196 de dire exprécement à Mercurial que vous souhaitez supprimer un
197 fichier. Au début du développement de Mercurial, celui ci vous
198 laissait pourtant supprimer un fichier sans soucis ; Mercurial vous
199 aurait automatiquement informé de l'absence du fichier lorsque vous
200 auriez lancé un <command role="hg-cmd">hg commit</command> et arrêté
201 de le suivre. En pratique, ceci a montré qu'il était trop facile de
202 supprimer accidentellement un fichier sans le remarquer.</para>
203 </sect2>
205 <sect2>
206 <title>Racourcis utile&emdash;ajouter et supprimer des fichiers en une
207 seule étape.</title>
209 <para id="x_1ba">Mercurial offre une commande combinée, <command
210 role="hg-cmd">hg addremove</command>, qui ajoute les fichiers non
211 suivis et marque les fichiers manquants comme supprimés.</para>
213 &interaction.daily.files.addremove;
215 <para id="x_1bb">La commande <command role="hg-cmd">hg commit</command>
216 fournit aussi une option <option role="hg-opt-commit">-A</option> qui
217 exécute le même ajouter-et-supprimer, immédiatement suivi d'un
218 commit.</para>
220 &interaction.daily.files.commit-addremove;
222 </sect2>
223 </sect1>
225 <sect1 id="chap:daily.copy">
226 <title>Copier des fichiers</title>
228 <para id="x_1bc">Mercurial fournit une commande <command role="hg-cmd">hg
229 copy</command> qui vous permet de faire une nouvelle copie d'un
230 fichier. Lorsque vous copiez un fichier en utilisant cette commande,
231 Mercurial crée un enregistrement du fait que ce nouveau fichier est une
232 copie du fichier originel. Il traite ces fichiers copiés spécialement
233 lorsque vous faites une fusion (merge) de votre travail avec quelqu'un
234 d'autre.</para>
236 <sect2>
237 <title>Les résultat d'une copie durant une fusion (merge)</title>
239 <para id="x_1bd">Ce qu'il se passe durant une fusion (merge) est que
240 les changements <quote>suivent</quote> une copie. Pour illustrer ce
241 que ça veut dire de la meilleure façon, créons un exemple. Nous
242 allons commencer avec le mini dépôt usuel qui contient un simple
243 fichier.</para>
245 &interaction.daily.copy.init;
247 <para id="x_1be">Nous devons faire du travail en parallèle, ainsi,
248 nous aurons quelque chose à fusionner (merge). Donc clonons notre
249 dépôt.</para>
251 &interaction.daily.copy.clone;
253 <para id="x_1bf">De retour dans notre dépôt initial, utilisons la
254 commande <command role="hg-cmd">hg copy</command> pour faire une
255 copie du premier fichier que nous avons créé.</para>
257 &interaction.daily.copy.copy;
259 <para id="x_1c0">Si nous regardons ensuite à la sortie de la commande
260 <command role="hg-cmd">hg status</command>, les fichiers copiés
261 ont l'air de fichiers normalement ajoutés.</para>
263 &interaction.daily.copy.status;
265 <para id="x_1c1">Mais si nous passons l'option <option
266 role="hg-opt-status">-C</option> à <command role="hg-cmd">hg
267 status</command>, il affiche une autre ligne de sortie : il s'agit
268 du fichier <emphasis>source</emphasis> pour notre copie.</para>
270 &interaction.daily.copy.status-copy;
272 <para id="x_1c2">Maintenant, de retour dans le dépôt que nous avons
273 cloné, et créons un changement en parallèle. Nous allons ajouter une
274 ligne de contenu au fichier original qui a été créé.</para>
276 &interaction.daily.copy.other;
278 <para id="x_1c3">Maintenant, nous avons un fichier
279 <filename>file</filename> modifié dans ce dépôt. Lorsque nous
280 récupérons (pull) les changements depuis le premier répertoire et
281 fusionnons (merge) les deux HEADS, Mercurial propagera les
282 changements que nous avons fait localement au fichier
283 <filename>file</filename> dans sa copie
284 <filename>new-file</filename>.</para>
286 &interaction.daily.copy.merge;
288 </sect2>
289 <sect2 id="sec:daily:why-copy">
290 <title>Pourquoi les changements devraient suivre les copies ?</title>
292 <para id="x_1c4">Ce comportement&emdash;des changements d'un fichiers
293 qui se propagent aux copies de ce fichier&emdash;peut sembler
294 ésotérique, mais, dans la plupart des cas, c'est hautement
295 désirable.</para>
297 <para id="x_1c5">Pour commencer, souvenez vous que cette propagation
298 a lieue <emphasis>seulement</emphasis> lors des fusions (merge).
299 Donc, si vous faites un <command role="hg-cmd">hg copy</command> sur
300 un fichier, et par la suite modifiez le fichier original durant le
301 cours normal de votre travail, rien n'a lieu.</para>
303 <para id="x_1c6">La deuxième chose à savoir c'est que les modifications
304 ne se propageront à travers une copie que si le changeset à partir
305 duquel vous faites une fusion (merge) <emphasis>n'a pas encore
306 vu</emphasis> la copie.</para>
308 <para id="x_1c7">La raison pour laquelle Mercurial fait ainsi est une
309 règle. Disons que je corrige un important bug dans un fichier source
310 et commit mes changements. Pendant ce temps, vous avez décidé de
311 faire un <command role="hg-cmd">hg copy</command> du fichier dans
312 votre dépôt, sans rien savoir au sujet du bug ou sans avoir rien vu à
313 propos de la correction, et vous avez commencé à "hacker" sur votre
314 copie du fichier.</para>
316 <para id="x_1c8">Si vous aviez récupéré (pull) et fusionné (merge) mes
317 changements, et que Mercurial <emphasis>n'avait pas</emphasis>
318 propagé les changements à travers les copies, votre nouveau fichier
319 source contiendrait maintenant le bug, et à moins que vous sachiez
320 qu'il faille propager la correction du bug à la main, le bug aurait
321 <emphasis>subsisté</emphasis> dans votre copie du fichier.</para>
323 <para id="x_1c9">En propageant automatiquement les changements qui
324 fixent les bugs à partir du fichier original vers les copies,
325 Mercurial prévient ce type de problèmes. A ma connaissance, Mercurial
326 est le <emphasis>seul</emphasis> système de gestion de révisions qui
327 propage les changements à travers les copies comme ceci.</para>
329 <para id="x_1ca">Une fois que votre historique des changements a un
330 enregistrement concernant une copie et une fusion postérieure qui a
331 eu lieue, il n'y a d'habitude pas d'autre besoin de propager les
332 changements du fichier originel vers le fichier copié, et c'est
333 pourquoi Mercurial ne propage les changements à travers les copies
334 seulement à la première fusion, et pas d'avantage.</para>
335 </sect2>
337 <sect2>
338 <title>Comment faire des changements qui <emphasis>ne</emphasis>
339 suivent <emphasis>pas</emphasis> une copie</title>
341 <para id="x_1cb">Si pour une raison ou une autre, vous décidez que
342 cette fonctionnalité de propager automatiquement les changements à
343 travers les copies n'est pas pour vous, utilisez simplement la
344 commande normale de copie de votre système (sur les systèmes de type
345 Unix, il s'agit de <command>cp</command>) pour faire une copie d'un
346 fichier. Utilisez ensuite <command role="hg-cmd">hg add</command>
347 pour ajouter les nouveaux fichiers à la main. Cependant, avant d'en
348 faire ainsi, relisez <xref linkend="sec:daily:why-copy"/>, et faites
349 un choix en tout état de cause que cette fonctionnalité n'est pas
350 appropriée à votre cas spécifique.</para>
352 </sect2>
353 <sect2>
354 <title>Comportement de la commande <command role="hg-cmd">hg copy</command></title>
356 <para id="x_1cc">Lorsque vous utilisez la commande <command
357 role="hg-cmd">hg copy</command>, Mercurial crée une copie de chaque
358 fichier source tel qu'il est actuellement dans le répertoire de
359 travail. Cela signifie que si vous faites des modifications à un
360 fichier, puis faites un <command role="hg-cmd">hg copy</command> sur
361 celui-ci sans avoir au préalable commité ces changements, la nouvelle
362 copie contiendra aussi les modifications que vous avez fait jusqu'à
363 ce point. modifications you have made up until that point. (Je
364 trouve ce comportement quelque peu contre intuitif, c'est pourquoi
365 j'en fais mention ici.)</para>
367 <para id="x_1cd">La commande <command role="hg-cmd">hg copy</command>
368 agit comme la commande Unix <command>cp</command> (vous pouvez
369 utilisez l'alias <command role="hg-cmd">hg cp</command> si vous
370 préférez). Nous devons lui donner deux ou plus arguments où le
371 dernier est considéré comme la <emphasis>destination</emphasis>, et
372 les autres comme les <emphasis>sources</emphasis>.</para>
374 <para id="x_685">Si vous passez à <command role="hg-cmd">hg
375 copy</command> un seul fichier source, et que la destination
376 n'existe pas, ceci créera un nouveau fichier avec ce nom.</para>
378 &interaction.daily.copy.simple;
380 <para id="x_1ce">Si la destination est un répertoire, Mercurial copie
381 les sources dans ce répertoire.</para>
383 &interaction.daily.copy.dir-dest;
385 <para id="x_1cf">La copie de répertoire est récursive et préserve la
386 structure du répertoire source.</para>
388 &interaction.daily.copy.dir-src;
390 <para id="x_1d0">Si la source et la destination sont tous deux des
391 répertoires, l'arborescence de la source est recrée dans le
392 répertoire destination.</para>
394 &interaction.daily.copy.dir-src-dest;
396 <para id="x_1d1">Comme avec la commande <command role="hg-cmd">hg
397 remove</command>, si vous copiez un fichier manuellement et voulez
398 que Mercurial sache qu'il s'agit d'une copie, utilisez simplement
399 l'option <option role="hg-opt-copy">--after</option> avec <command
400 role="hg-cmd">hg copy</command>.</para>
402 &interaction.daily.copy.after;
403 </sect2>
404 </sect1>
406 <sect1>
407 <title>Renommer les fichiers</title>
409 <para id="x_1d2">Il est plus commun d'avoir besoin de renommer un
410 fichier que d'en faire une copie. La raison pour laquelle j'ai discuté
411 de la commande <command role="hg-cmd">hg copy</command> avant de parler
412 de renommage des fichiers est que Mercurial traite les renommages
413 essenciellement comme une copie. Ainsi, savoir comment Mercurial traite
414 les copies de fichiers vous informe sur ce que vous êtes en droit
415 d'attendre lorsque vous renommez un fichier.</para>
417 <para id="x_1d3">Lorsque vous utilisez la commande <command
418 role="hg-cmd">hg rename</command>, Mercurial crée uen copie de chaque
419 fichier source, les supprime et marque ces fichiers comme étant
420 supprimés.</para>
422 &interaction.daily.rename.rename;
424 <para id="x_1d4">La commande <command role="hg-cmd">hg status</command>
425 montre le nouveau fichier comme ajouté et le fichier origine comme
426 supprimé.</para>
428 &interaction.daily.rename.status;
430 <para id="x_1d5">A cause du <command role="hg-cmd">hg copy</command>,
431 nous devons utiliser l'option <option role="hg-opt-status">-C</option>
432 pour <command role="hg-cmd">hg status</command> afin d'observer que le
433 fichier ajouté est bien suivi par Mercurial comme étant une copie de
434 l'original maintenant supprimé.</para>
436 &interaction.daily.rename.status-copy;
438 <para id="x_1d6">Comme avec <command role="hg-cmd">hg remove</command> et
439 <command role="hg-cmd">hg copy</command>, vous pouvez informer
440 Mercurial à propos d'un renommage après coup en utilisant l'option
441 <option role="hg-opt-rename">--after</option>. Dans le plus grand
442 respet, le comportement de la commande <command role="hg-cmd">hg
443 rename</command>, et les options qu'il accepte sont similaires à la
444 commande <command role="hg-cmd">hg copy</command>.</para>
446 <para id="x_686">Si vous êtes familié avec la ligne de commande Unix,
447 vous serez heureux d'apprendre que la commande <command
448 role="hg-cmd">hg rename</command> peut être invoquée par <command
449 role="hg-cmd">hg mv</command>.</para>
451 <sect2>
452 <title>Renommer les fichiers et fusionner (merge) les changements</title>
454 <para id="x_1d7">Puise que le rename de Mercurial est implanté comme un
455 "copy-and-remove", la même propagation des changements a lieue
456 lorsque vous fusionnez (merge) après un "rename" qu'après un
457 "copy".</para>
459 <para id="x_1d8">Si je modifie un fichier et que vous le renommez, si
460 ensuite nous fusionnons nos changements respectifs, mes modifications
461 sur le fichier sous son nom originel seront propagés vers le même
462 fichier sous son nouveau nom. (C'est quelque chose que vous pourriez
463 espérer voir <quote>fonctionner simplement</quote>, mais tous les
464 systèmes de gestion de version ne le font pas.)</para>
466 <para id="x_1d9">Tandis qu'avoir des changements qui suivent une copie
467 est une fonctionnalité où vous hocheriez sûrement la tête en disant
468 <quote>oui, cela pourrait être utile</quote>, il est clair que les
469 voir suivre un renommage est définitivement important. Sans cette
470 aptitude, il serait simplement trop facile d'avoir des changements
471 qui deviennent orphelins lorsque des fichiers sont renommés.</para>
472 </sect2>
474 <sect2>
475 <title>Renommages divergeants et fusion (merge)</title>
477 <para id="x_1da">Le cas de noms divergeants a lieu lorsque deux
478 développeurs commencent avec un fichier&emdash;apprelons le
479 <filename>foo</filename>&emdash;dans leurs dépôts respectifs.</para>
481 &interaction.rename.divergent.clone;
483 <para id="x_1db">Anne renomme le fichier en
484 <filename>bar</filename>.</para>
486 &interaction.rename.divergent.rename.anne;
488 <para id="x_1dc">Pendant ce temps, Bob le renomme en
489 <filename>quux</filename>. (Souvenez vous que <command
490 role="hg-cmd">hg mv</command> est un alias pour <command
491 role="hg-cmd">hg rename</command>.)</para>
493 &interaction.rename.divergent.rename.bob;
495 <para id="x_1dd">J'aime à penser qu'il s'agit d'un conflit puisque
496 chaque développeur a exprimé différentes intentions au sujet de ce
497 que le nom de ce fichier aurait du être.</para>
499 <para id="x_1de">Que pensez vous qu'il devrait se produire lorsqu'ils
500 fusionnent (merge) leurs travaux ? Le comportement actuel de
501 Mercurial est qu'il préserve toujours les <emphasis>deux</emphasis>
502 noms lorsqu'il fusionne (merge) des changesets qui contiennent des
503 renommages divergeants.</para>
505 &interaction.rename.divergent.merge;
507 <para id="x_1df">Remarquez que bien que Mercurial vous avertisse au
508 sujet de la divergeance des renommages, il vous laisse faire quelque
509 chose au sujet de la divergeance après la fusion (merge).</para>
510 </sect2>
512 <sect2>
513 <title>Renommages et fusion convergeants</title>
515 <para id="x_1e0">Un autre type de conflit de renommage intervient
516 lorsque deux personne choisissent de renommer différents fichiers
517 <emphasis>source</emphasis> vers la même
518 <emphasis>destination</emphasis>. Dans ce cas, Mercurial exécute la
519 machinerie normale de fusion (merge) et vous guide vers une
520 solution convenable.</para>
521 </sect2>
523 <sect2>
524 <title>Autres cas anguleux relatifs aux noms</title>
526 <para id="x_1e1">Mercurial possède un bug de longue date dans lequel il
527 échoue à traiter une fusion (merge) où un coté a un fichier avec un
528 nom donné, alors que l'autre coté a un répertoire avec le même nom.
529 Ceci est documenté dans l'<ulink role="hg-bug"
530 url="http://www.selenic.com/mercurial/bts/issue29">issue
531 29</ulink>.</para>
533 &interaction.issue29.go;
535 </sect2>
536 </sect1>
538 <sect1>
539 <title>Récupération d'erreurs</title>
541 <para id="x_1e2">Mercurial possède certaines commandes utiles qui vont
542 vous aider à récupérer certaines erreurs communes.</para>
544 <para id="x_1e3">La commande <command role="hg-cmd">hg revert</command>
545 vous permet d'annuler les changements que vous avez fait dans votre
546 répertoire de travail. Par exemple, si vous faites un <command
547 role="hg-cmd">hg add</command> sur un fichier par accident, exécutez
548 juste <command role="hg-cmd">hg revert</command> avec le nom du fichier
549 que vous avez ajouté et tandis que le fichier ne touché d'une
550 quelconque manière, il ne sera plus suivi comme ajouté par Mercurial.
551 Vous pouvez aussi utiliser la commande <command role="hg-cmd">hg
552 revert</command> pour vous débarasser de modifications erronés
553 apportées à un fichier.</para>
555 <para id="x_1e4">Il est utile de se souvenir que la commande <command
556 role="hg-cmd">hg revert</command> est utile pour les modifications
557 qui n'ont pas encore été commitées. Une fois que vous avez committé un
558 changement, si vous décidez qu'il s'agissait d'une erreur, vous pouvez
559 toujours faire quelquechose à ce sujet, bien que vos options seront
560 un peu plus limitées.</para>
562 <para id="x_1e5">Pour plus d'informations au sujet de la commande
563 <command role="hg-cmd">hg revert</command>, et des détails sur comment
564 traiter les modifications que vous avez déjà committées, référez vous à
565 <xref linkend="chap:undo"/>.</para>
566 </sect1>
568 <sect1>
569 <title>Traiter avec les fusions (merge) malicieuses</title>
571 <para id="x_687">Dans des projets compliqués ou conséquents, il n'est pas
572 rare qu'une fusion (merge) de deux changesets finisse par une migraine.
573 Supposez qu'il y a un gros fichier source qui a été largement édité de
574 chaque coté de la fusion (merge) : ceci va inévitablement résulter en
575 conflits, dont certains peuvent prendre quelques essais pour s'en
576 sortir.</para>
578 <para id="x_688">Développons en un cas simple pour voir comment traiter
579 avec. Nous allons commencer avec un dépôt contenant un fichier, et le
580 cloner deux fois.</para>
582 &interaction.ch04-resolve.init;
584 <para id="x_689">Dans un des clones, nous allons modifier le fichier
585 d'une façon.</para>
587 &interaction.ch04-resolve.left;
589 <para id="x_68a">Dans un autre, nous allons modifier le fichier
590 différamment.</para>
592 &interaction.ch04-resolve.right;
594 <para id="x_68b">Ensuite, nous allons récupérer (pull) chaque ensemble de
595 changement dans notre dépôt original.</para>
597 &interaction.ch04-resolve.pull;
599 <para id="x_68c">Nous nous attendons à ce que notre dépôt contienne deux
600 HEADS.</para>
602 &interaction.ch04-resolve.heads;
604 <para id="x_68d">Normalement, si nous lançons <command role="hg-cmd">hg
605 merge</command> à ce point, il nous renverra vers une interface
606 utilisateur qui nous permettra de résoudre manuellement les éditions
607 conflictuelles sur le fichier <filename>myfile.txt</filename>.
608 Cependant, pour simplifier les choses dans la présentation ici, nous
609 aimerions que la fusion (merge) échoue immédiatement plutôt. Voici une
610 façon de le faire.</para>
612 &interaction.ch04-resolve.export;
614 <para id="x_68e">Nous avons dit à la machinerie de fusion de Mercurial
615 d'exécuter la commande <command>false</command> (qui échoue
616 immédiatement, à la demande) s'il détecte une fusion (merge) qu'il ne
617 peut pas arranger automatiquement.</para>
619 <para id="x_68f">Si nous appelons maintenant <command role="hg-cmd">hg
620 merge</command>, il devrait planter et reporter une erreur.</para>
622 &interaction.ch04-resolve.merge;
624 <para id="x_690">Même si nous ne remarquons pas qu'une fusion (merge) a
625 échoué, Mercurial nous empéchera de committer le résultat d'une fusion
626 ratée.</para>
628 &interaction.ch04-resolve.cifail;
630 <para id="x_691">Lorsque <command role="hg-cmd">hg commit</command>
631 échoue dans ce cas, il suggère que nous utilisons la commande peu
632 connue <command role="hg-cmd">hg resolve</command>. Comme d'habitude,
633 <command role="hg-cmd">hg help resolve</command> affichera une aide
634 sommaire.</para>
636 <sect2>
637 <title>File resolution states</title>
639 <para id="x_692">When a merge occurs, most files will usually remain
640 unmodified. For each file where Mercurial has to do
641 something, it tracks the state of the file.</para>
643 <itemizedlist>
644 <listitem>
645 <para id="x_693">A <emphasis>resolved</emphasis> file has been
646 successfully merged, either automatically by Mercurial or
647 manually with human intervention.</para>
648 </listitem>
649 <listitem>
650 <para id="x_694">An <emphasis>unresolved</emphasis> file was not merged
651 successfully, and needs more attention.</para>
652 </listitem>
653 </itemizedlist>
655 <para id="x_695">If Mercurial sees <emphasis>any</emphasis> file in the
656 unresolved state after a merge, it considers the merge to have
657 failed. Fortunately, we do not need to restart the entire
658 merge from scratch.</para>
660 <para id="x_696">The <option role="hg-opt-resolve">--list</option> or
661 <option role="hg-opt-resolve">-l</option> option to <command
662 role="hg-cmd">hg resolve</command> prints out the state of
663 each merged file.</para>
665 &interaction.ch04-resolve.list;
667 <para id="x_697">In the output from <command role="hg-cmd">hg
668 resolve</command>, a resolved file is marked with
669 <literal>R</literal>, while an unresolved file is marked with
670 <literal>U</literal>. If any files are listed with
671 <literal>U</literal>, we know that an attempt to commit the
672 results of the merge will fail.</para>
673 </sect2>
675 <sect2>
676 <title>Resolving a file merge</title>
678 <para id="x_698">We have several options to move a file from the unresolved
679 into the resolved state. By far the most common is to rerun
680 <command role="hg-cmd">hg resolve</command>. If we pass the
681 names of individual files or directories, it will retry the
682 merges of any unresolved files present in those locations. We
683 can also pass the <option role="hg-opt-resolve">--all</option>
684 or <option role="hg-opt-resolve">-a</option> option, which
685 will retry the merges of <emphasis>all</emphasis> unresolved
686 files.</para>
688 <para id="x_699">Mercurial also lets us modify the resolution state of a
689 file directly. We can manually mark a file as resolved using
690 the <option role="hg-opt-resolve">--mark</option> option, or
691 as unresolved using the <option
692 role="hg-opt-resolve">--unmark</option> option. This allows
693 us to clean up a particularly messy merge by hand, and to keep
694 track of our progress with each file as we go.</para>
695 </sect2>
696 </sect1>
698 <sect1>
699 <title>More useful diffs</title>
701 <para id="x_6c7">The default output of the <command role="hg-cmd">hg
702 diff</command> command is backwards compatible with the
703 regular <command>diff</command> command, but this has some
704 drawbacks.</para>
706 <para id="x_6c8">Consider the case where we use <command role="hg-cmd">hg
707 rename</command> to rename a file.</para>
709 &interaction.ch04-diff.rename.basic;
711 <para id="x_6c9">The output of <command role="hg-cmd">hg diff</command> above
712 obscures the fact that we simply renamed a file. The <command
713 role="hg-cmd">hg diff</command> command accepts an option,
714 <option>--git</option> or <option>-g</option>, to use a newer
715 diff format that displays such information in a more readable
716 form.</para>
718 &interaction.ch04-diff.rename.git;
720 <para id="x_6ca">This option also helps with a case that can otherwise be
721 confusing: a file that appears to be modified according to
722 <command role="hg-cmd">hg status</command>, but for which
723 <command role="hg-cmd">hg diff</command> prints nothing. This
724 situation can arise if we change the file's execute
725 permissions.</para>
727 &interaction.ch04-diff.chmod;
729 <para id="x_6cb">The normal <command>diff</command> command pays no attention
730 to file permissions, which is why <command role="hg-cmd">hg
731 diff</command> prints nothing by default. If we supply it
732 with the <option>-g</option> option, it tells us what really
733 happened.</para>
735 &interaction.ch04-diff.chmod.git;
736 </sect1>
738 <sect1>
739 <title>Which files to manage, and which to avoid</title>
741 <para id="x_6cc">Revision control systems are generally best at managing text
742 files that are written by humans, such as source code, where the
743 files do not change much from one revision to the next. Some
744 centralized revision control systems can also deal tolerably
745 well with binary files, such as bitmap images.</para>
747 <para id="x_6cd">For instance, a game development team will typically manage
748 both its source code and all of its binary assets (e.g. geometry
749 data, textures, map layouts) in a revision control
750 system.</para>
752 <para id="x_6ce">Because it is usually impossible to merge two conflicting
753 modifications to a binary file, centralized systems often
754 provide a file locking mechanism that allow a user to say
755 <quote>I am the only person who can edit this
756 file</quote>.</para>
758 <para id="x_6cf">Compared to a centralized system, a distributed revision
759 control system changes some of the factors that guide decisions
760 over which files to manage and how.</para>
762 <para id="x_6d0">For instance, a distributed revision control system cannot,
763 by its nature, offer a file locking facility. There is thus no
764 built-in mechanism to prevent two people from making conflicting
765 changes to a binary file. If you have a team where several
766 people may be editing binary files frequently, it may not be a
767 good idea to use Mercurial&emdash;or any other distributed
768 revision control system&emdash;to manage those files.</para>
770 <para id="x_6d1">When storing modifications to a file, Mercurial usually
771 saves only the differences between the previous and current
772 versions of the file. For most text files, this is extremely
773 efficient. However, some files (particularly binary files) are
774 laid out in such a way that even a small change to a file's
775 logical content results in many or most of the bytes inside the
776 file changing. For instance, compressed files are particularly
777 susceptible to this. If the differences between each successive
778 version of a file are always large, Mercurial will not be able
779 to store the file's revision history very efficiently. This can
780 affect both local storage needs and the amount of time it takes
781 to clone a repository.</para>
783 <para id="x_6d2">To get an idea of how this could affect you in practice,
784 suppose you want to use Mercurial to manage an OpenOffice
785 document. OpenOffice stores documents on disk as compressed zip
786 files. Edit even a single letter of your document in OpenOffice,
787 and almost every byte in the entire file will change when you
788 save it. Now suppose that file is 2MB in size. Because most of
789 the file changes every time you save, Mercurial will have to
790 store all 2MB of the file every time you commit, even though
791 from your perspective, perhaps only a few words are changing
792 each time. A single frequently-edited file that is not friendly
793 to Mercurial's storage assumptions can easily have an outsized
794 effect on the size of the repository.</para>
796 <para id="x_6d3">Even worse, if both you and someone else edit the OpenOffice
797 document you're working on, there is no useful way to merge your
798 work. In fact, there isn't even a good way to tell what the
799 differences are between your respective changes.</para>
801 <para id="x_6d4">There are thus a few clear recommendations about specific
802 kinds of files to be very careful with.</para>
804 <itemizedlist>
805 <listitem>
806 <para id="x_6d5">Files that are very large and incompressible, e.g. ISO
807 CD-ROM images, will by virtue of sheer size make clones over
808 a network very slow.</para>
809 </listitem>
810 <listitem>
811 <para id="x_6d6">Files that change a lot from one revision to the next
812 may be expensive to store if you edit them frequently, and
813 conflicts due to concurrent edits may be difficult to
814 resolve.</para>
815 </listitem>
816 </itemizedlist>
817 </sect1>
819 <sect1>
820 <title>Backups and mirroring</title>
822 <para id="x_6d7">Since Mercurial maintains a complete copy of history in each
823 clone, everyone who uses Mercurial to collaborate on a project
824 can potentially act as a source of backups in the event of a
825 catastrophe. If a central repository becomes unavailable, you
826 can construct a replacement simply by cloning a copy of the
827 repository from one contributor, and pulling any changes they
828 may not have seen from others.</para>
830 <para id="x_6d8">It is simple to use Mercurial to perform off-site backups
831 and remote mirrors. Set up a periodic job (e.g. via the
832 <command>cron</command> command) on a remote server to pull
833 changes from your master repositories every hour. This will
834 only be tricky in the unlikely case that the number of master
835 repositories you maintain changes frequently, in which case
836 you'll need to do a little scripting to refresh the list of
837 repositories to back up.</para>
839 <para id="x_6d9">If you perform traditional backups of your master
840 repositories to tape or disk, and you want to back up a
841 repository named <filename>myrepo</filename>, use <command>hg
842 clone -U myrepo myrepo.bak</command> to create a
843 clone of <filename>myrepo</filename> before you start your
844 backups. The <option>-U</option> option doesn't check out a
845 working directory after the clone completes, since that would be
846 superfluous and make the backup take longer.</para>
848 <para id="x_6da">If you then back up <filename>myrepo.bak</filename> instead
849 of <filename>myrepo</filename>, you will be guaranteed to have a
850 consistent snapshot of your repository that won't be pushed to
851 by an insomniac developer in mid-backup.</para>
852 </sect1>
853 </chapter>
855 <!--
856 local variables:
857 sgml-parent-document: ("00book.xml" "book" "chapter")
858 end:
859 -->