hgbook
view fr/ch05-daily.xml @ 1018:75456ed96549
some typo and better french translation
| author | André Sintzoff <andre.sintzoff@gmail.com> |
|---|---|
| date | Mon Nov 30 10:57:15 2009 +0100 (2009-11-30) |
| parents | 6f8c48362758 |
| children |
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>Utilisation quotidienne de Mercurial</title>
7 <sect1>
8 <title>Informer Mercurial des fichiers à suivre</title>
10 <para id="x_1a3">Mercurial ne suit pas les fichiers de votre dépôt tant
11 que vous ne lui avez pas dit de les gérer. La commande <command
12 role="hg-cmd">hg status</command> vous dira quels fichiers 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és avant le commit
27 ne seront plus listés 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 voudriez 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. Au 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, et ce,
42 jusqu'à 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. Ce que Mercurial suppose dans ce cas est que nous savons ce
62 que nous faisons, il n'affiche donc 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 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 mauvaise surprise
69 restée silencieuse. Ce comportement est commun à la plupart des
70 commandes 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épertoires. 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, cela 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 cependant des solutions alternatives et non intrusives que vous
86 pouvez utiliser pour obtenir l'effet approprié. Les développeurs de
87 Mercurial ont ainsi pensé que la complexité requise pour gérer les
88 répertoires n'était pas aussi importante que le bénéfice que cette
89 fonctionnalité 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 ensuite, de faire un <command role="hg-cmd">hg
94 add</command> sur un fichier <quote>caché</quote> dans ce
95 répertoire. Sur les systèmes 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ée 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 d'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 votre 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 supprimer 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é committé alors que le fichier que vous venez de
151 supprimer était encore suivi, ce fichier réapparaîtra dans le
152 répertoire de travail, avec le contenu qu'il avait lorsque vous aviez
153 committé 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>Fichiers 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> reporte 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 côté, 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éapparaitra dans
185 sa forme non modifiée.</para>
187 &interaction.daily.files.recover-missing;
189 </sect2>
191 <sect2>
192 <title>Aparté : Pourquoi dire explicitement à Mercurial de supprimer un
193 fichier ?</title>
194 <!-- TODO Choisir une traduction commune à tous les chapitres pour Aside -->
195 <para id="x_1b9">Vous pourriez vous demander pourquoi il est nécessaire
196 de dire explicitement à 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 souci ; 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>Raccourci 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 fusionnez (merge) votre travail avec quelqu'un
234 d'autre.</para>
236 <sect2>
237 <title>Les résultats 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 cela 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é, 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">Nous avons alors un fichier <filename>file</filename>
279 modifié dans ce dépôt. Lorsque nous récupérons (pull) les changements
280 depuis le premier répertoire et fusionnons (merge) les deux "heads",
281 Mercurial propagera les changements que nous avons faits localement
282 au fichier <filename>file</filename> dans sa copie
283 <filename>new-file</filename>.</para>
285 &interaction.daily.copy.merge;
287 </sect2>
288 <sect2 id="sec:daily:why-copy">
289 <title>Pourquoi les changements devraient-ils suivre les copies ?</title>
291 <para id="x_1c4">Ce comportement&emdash;des changements d'un fichier
292 qui se propagent aux copies de ce fichier&emdash;peut sembler
293 ésotérique, mais, dans la plupart des cas, c'est fortement
294 souhaitable.</para>
296 <para id="x_1c5">Pour commencer, souvenez-vous que cette propagation
297 a lieu <emphasis>seulement</emphasis> lors des fusions (merge).
298 Donc, si vous faites un <command role="hg-cmd">hg copy</command> sur
299 un fichier, et par la suite modifiez le fichier original durant le
300 cours normal de votre travail, rien n'aura lieu.</para>
302 <para id="x_1c6">La deuxième chose à savoir est que les modifications
303 ne se propageront à travers une copie que si le changeset à partir
304 duquel vous faites une fusion (merge) <emphasis>n'a pas encore
305 vu</emphasis> la copie.</para>
307 <para id="x_1c7">La raison pour laquelle Mercurial fait ainsi est une
308 règle. Imaginons que je corrige un important bug dans un fichier source
309 et que je commit mes changements. Pendant ce temps, vous avez décidé de
310 faire un <command role="hg-cmd">hg copy</command> du fichier dans
311 votre dépôt, sans rien savoir au sujet du bug ou à propos de la
312 correction. Vous avez alors commencé à "hacker" sur votre copie du
313 fichier.</para>
315 <para id="x_1c8">Si vous aviez récupéré (pull) et fusionné (merge) mes
316 changements, et que Mercurial <emphasis>n'avait pas</emphasis>
317 propagé les changements à travers les copies, votre nouveau fichier
318 source contiendrait maintenant le bug, et à moins que vous ne sachiez
319 qu'il faille propager la correction du bug à la main, le bug aurait
320 <emphasis>subsisté</emphasis> dans votre copie du fichier.</para>
322 <para id="x_1c9">En propageant automatiquement les changements qui
323 fixent les bugs à partir du fichier original vers les copies,
324 Mercurial prévient ce type de problèmes. À ma connaissance, Mercurial
325 est le <emphasis>seul</emphasis> système de gestion de révisions qui
326 propage les changements à travers les copies comme ceci.</para>
328 <para id="x_1ca">Une fois que votre historique des changements a un
329 enregistrement concernant une copie et qu'une fusion postérieure a
330 eu lieu, il n'y a d'habitude pas d'autre besoin de propager les
331 changements du fichier originel vers le fichier copié. C'est pourquoi
332 Mercurial ne propage les changements à travers les copies qu'à la
333 première fusion, et pas après.</para>
334 </sect2>
336 <sect2>
337 <title>Comment faire des changements qui <emphasis>ne</emphasis>
338 suivent <emphasis>pas</emphasis> une copie</title>
340 <para id="x_1cb">Si pour une raison ou une autre, vous décidez que
341 cette fonctionnalité de propager automatiquement les changements à
342 travers les copies n'est pas pour vous, utilisez simplement la
343 commande normale de copie de votre système (sur les systèmes de type
344 Unix, il s'agit de <command>cp</command>) pour faire une copie d'un
345 fichier. Utilisez ensuite <command role="hg-cmd">hg add</command>
346 pour ajouter les nouveaux fichiers à la main. Cependant, avant d'en
347 faire ainsi, relisez <xref linkend="sec:daily:why-copy"/>, et faites
348 un choix en connaissance de cause comme quoi cette fonctionnalité
349 n'est pas appropriée à votre cas spécifique.</para>
351 </sect2>
352 <sect2>
353 <title>Comportement de la commande <command role="hg-cmd">hg copy</command></title>
355 <para id="x_1cc">Lorsque vous utilisez la commande <command
356 role="hg-cmd">hg copy</command>, Mercurial crée une copie de chaque
357 fichier source tel qu'il est actuellement dans le répertoire de
358 travail. Cela signifie que si vous effectuez des modifications sur un
359 fichier, puis faites un <command role="hg-cmd">hg copy</command> sur
360 celui-ci sans avoir au préalable committé ces changements, la nouvelle
361 copie contiendra aussi les modifications que vous avez fait jusqu'à
362 ce point. (Je trouve ce comportement quelque peu contre intuitif,
363 c'est pourquoi j'en fais mention ici.)</para>
364 <!-- Vérifier que je n'ai pas fait de contre sens en relisant la
365 version anglaise, ce que je comprend ici me paraît un peu bizarre -->
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 essentiellement 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 une copie de tous
419 les fichiers sources, 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 les nouveaux fichiers comme ajoutés et les fichiers originaux
426 comme supprimés.</para>
428 &interaction.daily.rename.status;
430 <para id="x_1d5">À cause du <command role="hg-cmd">hg copy</command>,
431 nous devons utiliser l'option <option role="hg-opt-status">-C</option>
432 pour la commande <command role="hg-cmd">hg status</command> afin
433 d'observer que le fichier ajouté est bien suivi par Mercurial comme
434 étant une copie de 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 d'un renommage après coup en utilisant l'option
441 <option role="hg-opt-rename">--after</option>. Dans la plupart des autres
442 situations, le comportement de la commande <command role="hg-cmd">hg
443 rename</command>, et les options qu'elle accepte sont similaires à la
444 commande <command role="hg-cmd">hg copy</command>.</para>
446 <para id="x_686">Si vous êtes familier 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">Puisque le <quote>rename</quote> de Mercurial est implanté comme un
455 <quote>copy-and-remove</quote>, la même propagation des changements a lieu après
456 un <quote>rename</quote> qu'après un <quote>copy</quote> lorsque vous fusionnez (merge).</para>
458 <para id="x_1d8">Si je modifie un fichier et que vous le renommez, si
459 ensuite nous fusionnons nos changements respectifs, mes modifications
460 sur le fichier sous son nom originel seront propagés vers le même
461 fichier sous son nouveau nom. (C'est quelque chose que vous pourriez
462 espérer voir <quote>fonctionner simplement</quote>, mais tous les
463 systèmes de gestion de version ne le font pas.)</para>
465 <para id="x_1d9">Tandis qu'avoir des changements qui suivent une copie
466 est une fonctionnalité où vous hocheriez sûrement la tête en disant
467 <quote>oui, cela pourrait être utile</quote>, il est clair que les
468 voir suivre un renommage est sans aucun doute important. Sans cette
469 facilité, il serait vraiment trop facile d'avoir des changements
470 qui deviennent orphelins lorsque des fichiers sont renommés.</para>
471 </sect2>
473 <sect2>
474 <title>Renommages divergeants et fusion (merge)</title>
476 <para id="x_1da">Le cas de noms divergeants a lieu lorsque deux
477 développeurs commencent avec un fichier&emdash;appelons le
478 <filename>foo</filename>&emdash;dans leurs dépôts respectifs.</para>
480 &interaction.rename.divergent.clone;
482 <para id="x_1db">Anne renomme le fichier en
483 <filename>bar</filename>.</para>
485 &interaction.rename.divergent.rename.anne;
487 <para id="x_1dc">Pendant ce temps, Bob le renomme en
488 <filename>quux</filename>. (Souvenez-vous que <command
489 role="hg-cmd">hg mv</command> est un alias pour <command
490 role="hg-cmd">hg rename</command>.)</para>
492 &interaction.rename.divergent.rename.bob;
494 <para id="x_1dd">J'aime à penser qu'il s'agit d'un conflit puisque
495 chaque développeur a exprimé différentes intentions au sujet de ce
496 que le nom de ce fichier aurait du être.</para>
498 <para id="x_1de">Que pensez-vous qu'il devrait se produire lorsqu'ils
499 fusionnent (merge) leurs travaux ? Le comportement actuel de
500 Mercurial est qu'il préserve toujours les <emphasis>deux</emphasis>
501 noms lorsqu'il fusionne (merge) des changesets qui contiennent des
502 renommages divergeants.</para>
504 &interaction.rename.divergent.merge;
506 <para id="x_1df">Remarquez que bien que Mercurial vous avertisse au
507 sujet de la divergeance des renommages, il vous laisse faire quelque
508 chose au sujet de la divergence après la fusion (merge).</para>
509 </sect2>
511 <sect2>
512 <title>Renommages et fusion convergeants</title>
514 <para id="x_1e0">Un autre type de conflit de renommage intervient
515 lorsque deux personnes choisissent de renommer différents fichiers
516 <emphasis>source</emphasis> vers la même
517 <emphasis>destination</emphasis>. Dans ce cas, Mercurial exécute la
518 machinerie normale de fusion (merge) et vous guide vers une
519 solution convenable.</para>
520 </sect2>
522 <sect2>
523 <title>Autres cas épineux relatifs aux noms</title>
525 <para id="x_1e1">Mercurial possède un bug de longue date dans lequel il
526 échoue à traiter une fusion (merge) où un côté a un fichier avec un
527 nom donné, alors que l'autre côté possède un répertoire avec le même nom.
528 Ceci est documenté dans l'<ulink role="hg-bug"
529 url="http://www.selenic.com/mercurial/bts/issue29">issue
530 29</ulink>.</para>
532 &interaction.issue29.go;
534 </sect2>
535 </sect1>
536 <sect1>
537 <title>Récupération d'erreurs</title>
539 <para id="x_1e2">Mercurial possède certaines commandes utiles qui vont
540 vous aider à récupérer de certaines erreurs communes.</para>
542 <para id="x_1e3">La commande <command role="hg-cmd">hg revert</command>
543 vous permet d'annuler les changements que vous avez faits dans votre
544 répertoire de travail. Par exemple, si vous faites un <command
545 role="hg-cmd">hg add</command> sur un fichier par accident, exécutez
546 juste <command role="hg-cmd">hg revert</command> avec le nom du fichier
547 que vous avez ajouté et tandis que le fichier ne sera touché d'une
548 quelconque manière, il ne sera plus suivi comme ajouté par Mercurial.
549 Vous pouvez aussi utiliser la commande <command role="hg-cmd">hg
550 revert</command> pour vous débarrasser de modifications erronées
551 apportées à un fichier.</para>
553 <para id="x_1e4">Il est utile de se souvenir que la commande <command
554 role="hg-cmd">hg revert</command> est utile pour les modifications
555 qui n'ont pas encore été committées. Une fois que vous avez committé un
556 changement, si vous décidez qu'il s'agissait d'une erreur, vous pouvez
557 toujours faire quelque chose à ce sujet, bien que vos options soient
558 un peu plus limitées.</para>
560 <para id="x_1e5">Pour plus d'informations au sujet de la commande
561 <command role="hg-cmd">hg revert</command>, et des détails sur comment
562 traiter les modifications que vous avez déjà committées, référez vous à
563 <xref linkend="chap:undo"/>.</para>
564 </sect1>
566 <sect1>
567 <title>Traiter avec les fusions (merge) malicieuses</title>
569 <para id="x_687">Dans des projets compliqués ou conséquents, il n'est pas
570 rare qu'une fusion (merge) de deux changesets finisse par une migraine.
571 Supposez qu'il y ait un gros fichier source qui ait été largement édité de
572 chaque coté de la fusion (merge) : ceci va inévitablement résulter en
573 conflits, dont certains peuvent prendre plusieurs essais pour s'en
574 sortir.</para>
576 <para id="x_688">Développons en un cas simple pour voir comment le gérer.
577 Nous allons commencer avec un dépôt contenant un fichier, et le
578 cloner deux fois.</para>
580 &interaction.ch04-resolve.init;
582 <para id="x_689">Dans un des clones, nous allons modifier le fichier
583 d'une façon.</para>
585 &interaction.ch04-resolve.left;
587 <para id="x_68a">Dans un autre, nous allons modifier le fichier
588 différemment.</para>
590 &interaction.ch04-resolve.right;
592 <para id="x_68b">Ensuite, nous allons récupérer (pull) chaque ensemble de
593 changement dans notre dépôt original.</para>
595 &interaction.ch04-resolve.pull;
597 <para id="x_68c">Nous nous attendons à ce que notre dépôt contienne deux
598 "heads".</para>
600 &interaction.ch04-resolve.heads;
602 <para id="x_68d">Normalement, si nous lançons <command role="hg-cmd">hg
603 merge</command> à ce point, il nous renverra vers une interface
604 utilisateur qui nous permettra de résoudre manuellement les éditions
605 conflictuelles sur le fichier <filename>myfile.txt</filename>.
606 Cependant, pour simplifier ici les choses dans la présentation, nous
607 aimerions plutôt que la fusion (merge) échoue immédiatement. Voici une
608 façon de le faire.</para>
610 &interaction.ch04-resolve.export;
612 <para id="x_68e">Nous avons dit au processus de fusion de Mercurial
613 d'exécuter la commande <command>false</command> (qui échoue
614 immédiatement, à la demande) s'il détecte une fusion (merge) qu'il ne
615 peut pas arranger automatiquement.</para>
617 <para id="x_68f">Si nous appelons maintenant <command role="hg-cmd">hg
618 merge</command>, il devrait échouer et reporter une erreur.</para>
620 &interaction.ch04-resolve.merge;
622 <para id="x_690">Même si nous ne remarquons pas qu'une fusion (merge) a
623 échoué, Mercurial nous empêchera de committer le résultat d'une fusion
624 ratée.</para>
626 &interaction.ch04-resolve.cifail;
628 <para id="x_691">Lorsque <command role="hg-cmd">hg commit</command>
629 échoue dans ce cas, il suggère que nous utilisons la commande peu
630 connue <command role="hg-cmd">hg resolve</command>. Comme d'habitude,
631 <command role="hg-cmd">hg help resolve</command> affichera une aide
632 sommaire.</para>
634 <sect2>
635 <title>États de résolution des fichiers</title>
636 <!-- TODO Vérifier traduction : File resolution states -->
638 <para id="x_692">Lorsqu'une fusion intervient, la plupart des fichiers
639 vont, la plupart du temps, rester sans modification. Pour chaque
640 fichier sur lequel Mercurial doit faire quelque chose, il suit l'état
641 de celui-ci.</para>
643 <itemizedlist>
644 <listitem><para id="x_693">Un fichier
645 <quote><emphasis>resolved</emphasis></quote> a été fusionné
646 (merge) avec succès, que ce soit automatiquement par Mercurial ou
647 manuellement par une intervention humaine.</para></listitem>
648 <listitem><para id="x_694">Un fichier
649 <quote><emphasis>unresolved</emphasis></quote> n'a pas été
650 fusionné (merge) correctement et a besoin de plus
651 d'attention.</para>
652 </listitem>
653 </itemizedlist>
655 <para id="x_695">Si Mercurial voit un fichier
656 <emphasis>quelconque</emphasis> dans un état
657 <quote>unresolved</quote> après une fusion (merge), il considère que
658 la fusion (merge) a échoué. Heureusement, nous n'avons pas à
659 recommencer la procédure à partir du début.</para>
661 <para id="x_696">L'option <option role="hg-opt-resolve">--list</option>
662 ou <option role="hg-opt-resolve">-l</option> passée à <command
663 role="hg-cmd">hg resolve</command> liste l'état de chaque fichier
664 fusionné (merge).</para>
666 &interaction.ch04-resolve.list;
668 <para id="x_697">En sortie de <command role="hg-cmd">hg
669 resolve</command>, un fichier <quote>resolved</quote> est marqué avec un
670 <literal>R</literal>, alors qu'un fichier <quote>unresolved</quote> est marqué
671 d'un <literal>U</literal>. S'il existe un fichier listé avec un
672 <literal>U</literal>, nous savons qu'essayer de committer le résultat
673 de la fusion (merge) échouera.</para>
674 </sect2>
676 <sect2>
677 <title>Résoudre une fusion de fichier</title>
679 <para id="x_698">Nous avons plusieurs options pour changer l'état d'un
680 fichier de <quote>unresolved</quote> à <quote>resolved</quote>.
681 Le plus habituel est de relancer
682 <command role="hg-cmd">hg resolve</command>. Si nous passons les noms
683 des fichiers individuels ou des répertoires, ceci retentera la fusion
684 de tous les fichiers présents à cet endroit. Nous pouvons aussi
685 passer l'option <option role="hg-opt-resolve">--all</option> ou
686 <option role="hg-opt-resolve">-a</option> qui tentera de fusionner
687 <emphasis>tous</emphasis> les fichiers <quote>unresolved</quote>.</para>
689 <para id="x_699">Mercurial nous laisse aussi modifier la résolution
690 d'un fichier directement. Nous pouvons marquer un fichier <quote>resolved</quote>
691 en utilisant l'option <option role="hg-opt-resolve">--mark</option>,
692 ou <quote>unresolved</quote> en utilisant l'option <option
693 role="hg-opt-resolve">--unmark</option>. Ceci nous autorise à
694 nettoyer une fusion particulièrement compliquée à la main, et de
695 garder un suivi de nos progrès avec chaque fichier pendant que nous
696 avançons.</para>
697 </sect2>
698 </sect1>
700 <sect1>
701 <title>Des <quote>diffs</quote> plus utiles</title>
703 <para id="x_6c7">La sortie par défaut de la commande <command
704 role="hg-cmd">hg diff</command> est compatible rétrospectivement avec
705 la commande régulière <command>diff</command>, mais ceci a quelques
706 inconvénients.</para>
708 <para id="x_6c8">Considérez le cas où nous utilisons <command role="hg-cmd">hg
709 rename</command> pour renommer un fichier.</para>
711 &interaction.ch04-diff.rename.basic;
713 <para id="x_6c9">La sortie de <command role="hg-cmd">hg diff</command>
714 ci-dessus cache le fait que nous avons simplement renommé un fichier.
715 La commande <command role="hg-cmd">hg diff</command> accepte l'option
716 <option>--git</option> ou <option>-g</option> pour utiliser un nouveau
717 format de diff qui montre ces informations sous une forme plus
718 expressive.</para>
720 &interaction.ch04-diff.rename.git;
722 <para id="x_6ca">Cette option peut aussi aider avec le cas qui peut être autrement
723 perturbant : un fichier qui apparaît comme étant modifié en accord avec
724 <command role="hg-cmd">hg status</command>, mais où <command
725 role="hg-cmd">hg diff</command> n'affiche rien. Cette situation peut
726 survenir si nous changeons les permissions d'exécution du
727 fichier.</para>
729 &interaction.ch04-diff.chmod;
731 <para id="x_6cb">La commande normale <command>diff</command> ne fait pas
732 attention aux permissions des fichiers, ce qui explique pourquoi
733 <command role="hg-cmd">hg diff</command> n'affiche rien du tout par
734 défaut. Si nous lui passons l'option <option>-g</option>, ceci nous
735 informe de ce qui s'est vraiment passé.</para>
737 &interaction.ch04-diff.chmod.git;
738 </sect1>
740 <sect1>
741 <title>Quels fichiers suivre et lesquels éviter</title>
743 <para id="x_6cc">Les systèmes de gestion de révisions sont en général
744 meilleurs pour gérer les fichiers textes qui sont écrits par les
745 humains, comme le code source, où les fichiers ne changent pas
746 énormément d'une révision à l'autre. Certains systèmes de gestion de
747 révisions centralisés peuvent aussi traiter très convenablement les
748 fichiers binaires, tels que les images bitmap.</para>
750 <para id="x_6cd">Par exemple, une équipe de développement de jeux va
751 probablement gérer les deux types : ses codes source et tous ses binaires
752 (ex. données géométriques, textures, schémas de cartes) dans un système
753 de contrôle de révisions.</para>
754 <!-- Vérifier la traduction de map layouts que j'ai traduit par schémas
755 de cartes -->
757 <para id="x_6ce">Puisqu'il est d'habitude impossible de fusionner (merge)
758 deux modifications conflictuelles sur un fichier binaire, les systèmes
759 de version centralisés offrent souvent un mécanisme de verrou (lock) qui
760 permet à un utilisateur de dire <quote>Je suis la seule personne qui
761 peut éditer ce fichier</quote>.</para>
763 <para id="x_6cf">En comparaison avec un système centralisé, un système
764 décentralisé de gestion de révision change certains facteurs qui
765 guident les décisions sur quels fichiers gérer et comment.</para>
767 <para id="x_6d0">Par exemple, un système distribué de gestion de révisions
768 ne peut pas, par sa nature, offrir un système de verrou (lock) sur les
769 fichiers. Il n'y a donc pas de mécanisme inclus pour empêcher deux
770 personnes de faire des modifications conflictuelles sur un fichier
771 binaire. Si vous avez une équipe où plusieurs personnes peuvent souvent
772 éditer un fichier binaire, cela ne serait pas une très bonne idée
773 d'utiliser Mercurial &emdash;ou tout autre système distribué de gestion
774 de révisions&emdash;pour gérer ces fichiers.</para>
776 <para id="x_6d1">Lorsque vous sauvegardez les modifications sur un
777 fichier, Mercurial ne sauvegarde d'habitude que les différences entre
778 la version précédente et la version actuelle d'un fichier. Pour la
779 plupart des fichiers texte, ceci est très efficace. Cependant, certains
780 fichiers (en particulier les fichiers binaires) sont construits d'une
781 façon que même un petit changement sur un contenu logique résulte sur
782 un changement de la plupart des octets du fichier. Par exemple, les
783 fichiers compressés sont particulièrement sujets à ce comportement. Si
784 les différences entre deux versions successives d'un fichier sont
785 toujours très grandes, Mercurial ne sera pas capable de sauvegarder
786 l'historique des révisions sur le fichier très efficacement. Ceci peut
787 affecter aussi bien les besoins pour la sauvegarde locale que le temps
788 nécessaire à cloner le dépôt.</para>
790 <para id="x_6d2">Pour avoir une idée de comment ceci pourrait vous
791 affecter en pratique, supposez que nous voulions que Mercurial gère des
792 documents OpenOffice. OpenOffice sauvegarde les documents sur le disque
793 comme des fichiers compressés zip. Même le fait d'éditer ces fichiers
794 d'une seule lettre, changera les bits de la quasi totalité du fichier
795 lorsque vous le sauvegarderez. Maintenant, supposez que ce fichier
796 fasse une taille de 2 Mo. Puisque la plupart du fichier change à chaque
797 fois que vous sauvegardez, Mercurial aura à sauvegarder tous les 2 Mo du
798 fichier à chaque commit, alors que de votre point de vue, il n'y a
799 que peu de mots qui changent à chaque fois. Un seul fichier
800 souvent édité qui n'est pas bien traité par les hypothèses que Mercurial
801 fait sur les sauvegardes peut facilement avoir un effet colossal sur la
802 taille du dépôt.</para>
804 <para id="x_6d3">Même pire, si vous et quelqu'un d'autre éditez le même
805 document OpenOffice sur lequel vous travaillez, il n'y a pas de façon
806 utile pour fusionner votre travail. En fait, il n'y a pas de moyen
807 utile de montrer que les différences sont faites à partir de votre
808 vision des modifications.</para>
810 <para id="x_6d4">Il y a ainsi quelques recommandations claires sur les
811 types de fichiers spécifiques avec lesquels faire très
812 attention.</para>
814 <itemizedlist>
815 <listitem><para id="x_6d5">Les fichier qui sont très gros et
816 incompressibles, comme les images ISO de CD-ROM, sont, par
817 construction très gros et les cloner à travers un réseau sera très
818 long.</para></listitem>
819 <!-- TODO : Trouver une meilleure traduction pour : ISO CD-ROM images, will by
820 virtue of sheer size make clones over a network very slow. -->
821 <listitem><para id="x_6d6">Les fichiers qui changent beaucoup d'une
822 révision à l'autre peuvent être très coûteux à sauvegarder si vous
823 les éditez fréquemment, de même que les conflits entre deux éditions
824 concurrentes peuvent être difficiles à résoudre.</para>
825 </listitem>
826 </itemizedlist>
827 </sect1>
829 <sect1>
830 <title>Sauvegardes et miroirs</title>
832 <para id="x_6d7">Puisque Mercurial maintient une copie complète de
833 l'historique de chaque clone, toute personne qui utilise Mercurial pour
834 collaborer à un projet peut potentiellement agir comme une source de
835 sauvegarde si une catastrophe survenait. Si un dépôt central devient
836 indisponible, vous pouvez construire un remplaçant en clonant une copie
837 du dépôt à partir d'un des contributeurs en récupérant (pull) tous les
838 changements qui n'auraient pas été vus par les autres.</para>
840 <para id="x_6d8">Il est simple d'utiliser Mercurial pour construire des
841 serveurs hors site de sauvegarde et des miroirs distants. Initiez une
842 tâche périodique (ex. via la commande <command>cron</command>) sur un
843 serveur distant pour récupérer (pull) les changements de votre dépôt
844 distant chaque heure. Ceci sera difficile seulement dans le cas
845 improbable où le nombre des dépôts maîtres que vous maintenez change
846 souvent, auquel cas vous aurez besoin de faire un peu de scripting pour
847 rafraichir la liste des dépôts à sauvegarder.</para>
849 <para id="x_6d9">Si vous exécutez des sauvegardes traditionnelles de
850 votre dépôt maître sur bande ou disque, et que vous voulez sauvegarder
851 un dépôt nommé <filename>myrepo</filename>, utilisez la commande
852 <command>hg clone -U myrepo myrepo.bak</command> pour créer un clone de
853 <filename>myrepo</filename> avant de commencer vos backups.
854 L'option <option>-U</option> ne crée pas de répertoire de travail après
855 que le clone soit accompli, puisque ceci serait superflu et ferait que
856 la sauvegarde prenne plus de temps.</para>
858 <para id="x_6da">Si vous voulez ensuite sauvegarder
859 <filename>myrepo.bak</filename> au lieu de <filename>myrepo</filename>,
860 vous aurez la garantie d'avoir une image (snapshot) cohérente de
861 votre dépôt sur lequel un développeur insomniaque n'enverra (push) pas de
862 changements en milieu de sauvegarde.</para>
863 </sect1>
864 </chapter>
866 <!--
867 local variables:
868 sgml-parent-document: ("00book.xml" "book" "chapter")
869 end:
870 -->