hgbook
view fr/ch05-daily.xml @ 989:a3a9eabfe2a4
French translation : ch05-daily translated
| author | Frédéric Bouquet <youshe.jaalon@gmail.com> |
|---|---|
| date | Thu Sep 10 13:06:34 2009 +0200 (2009-09-10) |
| parents | 72de97557f11 |
| children | b4ff7b04efdc |
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>Etats de résolution des fichiers</title>
638 <!-- TODO Vérifier traduction : File resolution states -->
640 <para id="x_692">Lorsqu'une fusion intervient, la plupart des fichier
641 vont, la plupart du temps, rester sans modification. Pour chaque
642 fichier sur lequel Mercurial doit faire quelque chose, il suit l'état
643 de celui-ci.</para>
645 <itemizedlist>
646 <listitem><para id="x_693">Un fichier
647 <quote><emphasis>resolved</emphasis></quote> a été fusionné
648 (merge) avec succès, que ce soit automatiquement par Mercurial ou
649 manuellement par une intervention humaine.</para></listitem>
650 <listitem><para id="x_694">Un fichier
651 <quote><emphasis>unresolved</emphasis></quote> n'a pas été
652 fusionné (merge) correctement et a besoin de plus
653 d'attention.</para>
654 </listitem>
655 </itemizedlist>
657 <para id="x_695">Si Mercurial voit <emphasis>n'importe quel</emphasis>
658 fichier dans un état <quote>unresolved</quote> après une fusion
659 (merge), il considère que la fusion (merge) a échoué. Heureusement,
660 nous n'avons pas à recommencer la fusion (merge) à partir du
661 début.</para>
663 <para id="x_696">L'option <option role="hg-opt-resolve">--list</option>
664 ou <option role="hg-opt-resolve">-l</option> passée à <command
665 role="hg-cmd">hg resolve</command> liste l'état de chaque fichier
666 fusionné (merge).</para>
668 &interaction.ch04-resolve.list;
670 <para id="x_697">En sortie de <command role="hg-cmd">hg
671 resolve</command>, un fichier "resolved" est marqué avec un
672 <literal>R</literal>, alors qu'un fichier "unresolved" est marqué
673 d'un <literal>U</literal>. S'il existe un fichier listé avec un
674 <literal>U</literal>, nous savons qu'essayer de committer le résultat
675 de la fusion (merge) échoura.</para>
676 </sect2>
678 <sect2>
679 <title>Résoudre une fusion de fichier</title>
681 <para id="x_698">Nous avons plusieurs options pour changer l'état d'un
682 fichier de "unresolved" à "resolved". Le plus commun est de relancer
683 <command role="hg-cmd">hg resolve</command>. Si nous passons les noms
684 des fichiers individuels ou des répertoires, ceci retentera la fusion
685 de tous les fichiers présents à cet endroit. Nous pouvons aussi
686 passer l'option <option role="hg-opt-resolve">--all</option> ou
687 <option role="hg-opt-resolve">-a</option> qui tentera de fusionner
688 <emphasis>tous</emphasis> les fichiers "unresolved".</para>
690 <para id="x_699">Mercurial nous laisse aussi modifier la résolution
691 d'un fichier directement. Nous pouvons marquer un fichier "resolved"
692 en utilisant l'option <option role="hg-opt-resolve">--mark</option>,
693 ou "unresolved" en utilisant l'option <option
694 role="hg-opt-resolve">--unmark</option>. Ceci nous autorise à
695 nettoyer une fusion particulièrement compliqué à la main, et de
696 garder un suivi de nos progrès avec chaque fichier pendant que nous
697 procédons.</para>
698 </sect2>
699 </sect1>
701 <sect1>
702 <title>Des diffs plus utiles</title>
704 <para id="x_6c7">La sortie par défaut de la commande <command
705 role="hg-cmd">hg diff</command> est compatible rétrospectivement avec la commande régulière <command>diff</command>, mais ceci a quelques inconvénients.</para>
707 <para id="x_6c8">Considérez le cas où nous utilisons <command role="hg-cmd">hg
708 rename</command> pour renommer un fichier.</para>
710 &interaction.ch04-diff.rename.basic;
712 <para id="x_6c9">La sortie de <command role="hg-cmd">hg diff</command> ci
713 dessus cache le fait que nous avons simplement renommé un fichier. La
714 commande <command role="hg-cmd">hg diff</command> accepte l'option
715 <option>--git</option> ou <option>-g</option> pour utiliser un nouveau
716 format de diff qui montre ces informations sous une forme plus
717 expressive.</para>
719 &interaction.ch04-diff.rename.git;
721 <para id="x_6ca">Cette option peut aussi aider avec le cas autrement
722 confus : un fichier qui apparaît comme étant modifié en accord avec
723 <command role="hg-cmd">hg status</command>, mais où <command
724 role="hg-cmd">hg diff</command> n'affiche rien. Cette situation peut
725 survenir si nous changeons les permissions d'exécution du
726 fichier.</para>
728 &interaction.ch04-diff.chmod;
730 <para id="x_6cb">La commande normale <command>diff</command> ne fait pas
731 attention aux permissions des fichiers, ce qui explique pourquoi
732 <command role="hg-cmd">hg diff</command> n'affiche rien du tout par
733 défaut. Si nous lui passons l'option <option>-g</option>, ceci nous
734 informe de ce qu'il s'est vraiment passé.</para>
736 &interaction.ch04-diff.chmod.git;
737 </sect1>
739 <sect1>
740 <title>Quels fichiers gérer et lesquels éviter</title>
742 <para id="x_6cc">Les systèmes de gestion de révisions sont en général
743 meilleurs pour gérer les fichiers textes qui sont écrits par les
744 humains, comme le code source, où les fichiers ne changent pas
745 énormément d'une révision à l'autre. Certains systèmes de gestion de
746 révisions centralisés peuvent aussi traiter très correctement les
747 fichiers binaires, comme les images bitmap.</para>
749 <para id="x_6cd">Par exemple, une équipe de développement de jeux va
750 probablement gérer les deux : ses codes source et tous ses binaires
751 (ex. données géométriques, textures, schémas de cartes) dans un système
752 de contrôle de révisions.</para>
753 <!-- Vérifier la traduction de map layouts que j'ai traduit par schémas
754 de cartes -->
756 <para id="x_6ce">Puisqu'il est d'habitude impossible de fusionner (merge)
757 deux modifications conflictuelles sur un fichier binaire, les systèmes
758 de version centralisé offre souvent un mécanisme de verrou (lock) qui
759 permet à un utilisateur de dire <quote>Je suis la seule personne qui
760 peut éditer ce fichier</quote>.</para>
762 <para id="x_6cf">En comparaison d'un système centralisé, un système
763 décentralisé de gestion de révision change certains facteurs qui
764 guident les décisions sur quels fichiers gérer et comment.</para>
766 <para id="x_6d0">Par exemple, un système distribé de gestion de révisions
767 ne peut pas, par sa nature, offrir un système de vérrous (lock) sur les
768 fichiers. Il n'y a donc pas de mécanisme inclu pour empécher deux
769 personnes de faire des modifications conflictuelles sur un fichier
770 binaire. Si vous avez une équipe où plusieurs personnes peuvent souvent
771 éditer un fichier binaire, cela ne serait pas une très bonne idée
772 d'utiliser Mercurial &emdash;ou tout autre système distribé de gestion
773 de révisions&emdash;pour gérer ces fichiers.</para>
775 <para id="x_6d1">Lorsque vous sauvegardez les modifications sur un
776 fichier, Mercurial ne sauvegarde d'habitude que les différences entre
777 la version précédente et la version actuelle d'un fichier. Pour la
778 plupart des fichiers texte, ceci est très efficace. Cependant, certains
779 fichiers (en particulier les fichiers binaires) sont construits d'une
780 façon que même un petit changement sur un contenu logique résulte sur
781 un changement de la plupart des octets du fichier. Par exemple, les
782 fichiers compressés sont particulièrement suceptibles à ce
783 comportement. Si les différences entre deux versions successives d'un
784 fichier sont toujours très grandes, Mercurial ne sera pas capable de
785 sauvegarder l'historique des révisions sur le fichier très
786 efficacement. Ceci peut affecter aussi bien les besoins locaux pour
787 sauvegarder que le temps nécessaire à cloner le dépôt.</para>
789 <para id="x_6d2">Pour avoir une idée de comment ceci pourrait vous
790 affecter en pratique, supposez que nous voulions que Mercurial gère des
791 documents OpenOffice. OpenOffice sauvegarde les documents sur le disque
792 comme des fichiers compressés zip. Même le fait d'éditer ces fichiers
793 d'une seule lettre, changera les bits de la quasi totalité du fichier
794 lorsque vous le sauvegarderez. Maintenant, supposez que ce fichier
795 fasse une taille de 2Mo. Puisque la plupart du fichier change à chaque
796 fois que vous sauvegardez, Mercurial aura à sauvegarder tous les 2Mo du
797 fichier à chaque commit, alors que de votre point de vue, il n'y a
798 seulement que peu de mots qui changent à chaque fois. Un seul fichier
799 souvent édité qui n'est pas bien connu des hypothèses que Mercurial
800 fait sur les sauvegardes peut facilement avoir un effet colossal sur la
801 taille du dépôt.</para>
803 <para id="x_6d3">Même pire, si vous et quelqu'un d'autre éditez le même
804 document OpenOffice sur lequel vous travaillez, il n'y a pas de façon
805 utile pour fusionner votre travail. En fait, il n'y a pas de moyen
806 utile de montrer que les différences sont faites à partir de votre
807 vision des modifications.</para>
809 <para id="x_6d4">Il y a ainsi quelques recommendations claires sur les
810 types de fichiers spécifiques avec lesquels faire très
811 attention.</para>
813 <itemizedlist>
814 <listitem><para id="x_6d5">Les fichier qui sont très gros et
815 imcompressibles, comme les images ISO de CD-ROM, sont, par
816 construction très gros et les cloner à travers un réseau sera très
817 long.</para></listitem>
818 <!-- Trouver une meilleure traduction pour : ISO CD-ROM images, will by
819 virtue of sheer size make clones over a network very slow. -->
820 <listitem><para id="x_6d6">Les fichiers qui changent beaucoup d'une
821 révision à l'autre peuvent être très chers à sauvegarder si vous
822 les éditez fréquement, de même que les conflits entre deux éditions
823 concurrentes peuvent être difficiles à résoudre.</para>
824 </listitem>
825 </itemizedlist>
826 </sect1>
828 <sect1>
829 <title>Sauvegardes et miroirs</title>
831 <para id="x_6d7">Puisque Mercurial maintient une copie complète de
832 l'historique de chaque clone, toute personne qui utilise Mercurial pour
833 collaborer à un projet peut potentiellement agir comme une source de
834 sauvegarde si une catastrophe avait lieue. Si un dépôt central devient
835 indisponible, vous pouvez construire un remplaçant en clonant une copie
836 du dépôt à partir d'un des contributeurs en récupérant (pull) tous les
837 changements qui n'auraient pas été vus par les autres.</para>
839 <para id="x_6d8">Il est simple d'utiliser Mercurial pour construire des
840 serveurs hors site de sauvegarde et des miroirs distants. Initiez une
841 tâche périodique (ex. via la commande <command>cron</command>) sur un
842 serveur distant pour récupérer (pull) les changements de votre dépôt
843 distant chaque heure. Ceci sera difficile seullement dans le cas
844 improbable où le nombre des dépôts maîtres que vous maintenez change
845 souvent, auquel cas vous aurez besoin de faire un peu de scripting pour
846 raffraichir la liste des dépôt à sauvegarder.</para>
848 <para id="x_6d9">Si vous exécutez des sauvegardes traditionnelles de
849 votre dépôt maître sur des bandes ou disques, et que vous voulez
850 sauvegarder un dépôt nommé <filename>myrepo</filename>, utilisez la
851 commande <command>hg clone -U myrepo myrepo.bak</command> pour créer un
852 clone de <filename>myrepo</filename> avant de commencer vos backups.
853 L'option <option>-U</option> ne crée pas de répertoire de travail après
854 que le clone soit accompli, puisque ceci serait superflu et ferait que
855 la sauvegarde prenne plus de temps.</para>
857 <para id="x_6da">Si vous voulez ensuite sauvegarder
858 <filename>myrepo.bak</filename> au lieu de <filename>myrepo</filename>,
859 vous aurez la garantie d'avoir une image (snapshot) consistente de
860 votre dépôt sur lequel un développeur insomniac n'enverra (push) pas de
861 changements en milieu de sauvegarde.</para>
862 </sect1>
863 </chapter>
865 <!--
866 local variables:
867 sgml-parent-document: ("00book.xml" "book" "chapter")
868 end:
869 -->