rev |
line source |
belaran@964
|
1 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
|
belaran@964
|
2
|
belaran@976
|
3 <chapter id="chap:tour-merge">
|
belaran@976
|
4 <?dbhtml filename="a-tour-of-mercurial-merging-work.html"?>
|
belaran@976
|
5 <title>Un rapide tour de Mercurial: fusionner les travaux</title>
|
belaran@976
|
6
|
belaran@976
|
7 <para id="x_338">Nous avons maintenant étudié comment cloner un dépôt, effectuer
|
belaran@976
|
8 des changements dedans, et récupérer ou transférer depuis un
|
belaran@976
|
9 autre dépôt. La prochaine étape est donc de <emphasis>fusionner</emphasis> les
|
belaran@976
|
10 modifications de différents dépôts.</para>
|
belaran@976
|
11
|
belaran@976
|
12 <sect1>
|
belaran@976
|
13 <title>Fusionner différents travaux</title>
|
belaran@976
|
14 <para od="x_339">La fusion est un aspect fondamental lorsqu'on
|
belaran@976
|
15 travaille iavec un gestionnaire de source distribué.</para>
|
belaran@976
|
16
|
belaran@976
|
17 <itemizedlist>
|
belaran@995
|
18 <listitem>
|
belaran@995
|
19 <para id="x_33a">Alice et Bob ont chacun une copie personnelle du dépôt d'un
|
belaran@995
|
20 projet sur lequel ils collaborent. Alice corrige un bug
|
belaran@995
|
21 dans son dépôt, et Bob ajoute une nouvelle fonctionnalité dans le
|
belaran@995
|
22 sien. Ils veulent un dépôt partagé avec à la fois le correctif du
|
belaran@995
|
23 bug et la nouvelle fonctionnalité.</para>
|
belaran@995
|
24 </listitem>
|
belaran@995
|
25 <listitem>
|
belaran@995
|
26 <para id="x_33b">Je travaille régulièrement sur plusieurs tâches différentes sur
|
belaran@995
|
27 un seul projet en même temps, chacun isolé dans son propre dépôt.
|
belaran@995
|
28 Travailler ainsi signifie que je dois régulièrement fusionner une
|
belaran@995
|
29 partie de mon code avec celui des autres.</para>
|
belaran@995
|
30 </listitem>
|
belaran@995
|
31 </itemizedlist>
|
belaran@995
|
32
|
belaran@995
|
33 <para id="x_33c">Parce que la fusion est une opération si commune à réaliser,
|
belaran@995
|
34 Mercurial la rend facile. Étudions ensemble le déroulement des
|
belaran@995
|
35 opérations. Nous commencerons encore par faire un clone d'un autre
|
belaran@995
|
36 dépôt (vous voyez que l'on fait ça tout le temps ?) puis nous ferons
|
belaran@995
|
37 quelques modifications dessus.</para>
|
belaran@995
|
38
|
belaran@995
|
39 &interaction.tour.merge.clone;
|
belaran@995
|
40
|
belaran@995
|
41 <para id="x_33d">Nous devrions avoir maintenant deux copies de
|
belaran@995
|
42 <filename>hello.c</filename> avec des contenus différents. Les
|
belaran@995
|
43 historiques de ces deux dépôts ont aussi divergés, comme illustré dans
|
belaran@995
|
44 la figure <xref linkend="fig:tour-merge:sep-repos"/>.</para>
|
belaran@995
|
45
|
belaran@995
|
46 &interaction.tour.merge.cat1;
|
belaran@995
|
47
|
belaran@995
|
48 <para id="x_722">Et ici est notre légèrement différente version du
|
belaran@995
|
49 dépôt.</para>
|
belaran@995
|
50
|
belaran@995
|
51 &interaction.tour.merge.cat2;
|
belaran@995
|
52
|
belaran@995
|
53 <figure id="fig:tour-merge:sep-repos">
|
belaran@995
|
54 <title>Historique divergent des dépôts <filename
|
belaran@995
|
55 class="directory">my-hello</filename> et <filename
|
belaran@995
|
56 class="directory">my-new-hello</filename>.</title>
|
belaran@995
|
57 <mediaobject>
|
belaran@995
|
58 <imageobject><imagedata fileref="figs/tour-merge-sep-repos.png"/></imageobject>
|
belaran@995
|
59 <textobject><phrase>XXX ajoute un test</phrase></textobject>
|
belaran@995
|
60 </mediaobject>
|
belaran@995
|
61 </figure>
|
belaran@995
|
62
|
belaran@995
|
63 <para id="x_33f">Nous savons déjà que récupérer les modifications depuis
|
belaran@995
|
64 notre dépôt <filename class="directory">my-hello</filename> n'aura
|
belaran@995
|
65 aucun effet sur l'espace de travail.</para>
|
belaran@995
|
66
|
belaran@995
|
67 &interaction.tour.merge.pull;
|
belaran@995
|
68
|
belaran@995
|
69 <para id="x_340">Néanmoins, la commande <command role="hg-cmd">hg
|
belaran@995
|
70 pull</command> nous indique quelque chose au sujet des
|
belaran@995
|
71 <quote>heads</quote>.</para>
|
belaran@995
|
72
|
belaran@995
|
73 <sect2>
|
belaran@995
|
74 <title>Les révisions 'heads'</title>
|
belaran@995
|
75
|
belaran@995
|
76 <para id="x_341">Rappellez vous que Mercurial enregistre quelle révision
|
belaran@995
|
77 est le parent de chaque révision. Si une révision a un parent, nous
|
belaran@995
|
78 l'appelons un enfant(child) ou un descendant de ce parent. Une
|
belaran@995
|
79 "head" est une révision qui n'a donc pas d'enfant. La révision tip
|
belaran@995
|
80 est donc une "head", car c'est la révision la plus récente du dépôt
|
belaran@995
|
81 qui n'a pas d'enfant. Il y a des moments où un dépôt peut contenir
|
belaran@995
|
82 plusieurs "head".</para>
|
belaran@995
|
83
|
belaran@995
|
84 <figure>
|
belaran@995
|
85 <title>Contenu du dépôt après une récupération ("pull") depuis le
|
belaran@995
|
86 dépôt <filename
|
belaran@995
|
87 class="directory">my-hello</filename> vers le dépôt <filename
|
belaran@995
|
88 class="directory">my-new-hello</filename></title>
|
belaran@995
|
89 <mediaobject>
|
belaran@995
|
90 <imageobject>
|
belaran@995
|
91 <imagedata fileref="tour-merge-pull"/>
|
belaran@995
|
92 </imageobject>
|
belaran@995
|
93 <textobject><phrase>XXX ajoute un texte</phrase></textobject>
|
belaran@995
|
94 </mediaobject>
|
belaran@995
|
95 </figure>
|
belaran@995
|
96
|
belaran@995
|
97 <para id="x_343">Dans la figure <xref linkend="fig:tour-merge:pull"/>,
|
belaran@995
|
98 vous pouvez constater l'effet d'un \textit{pull} depuis le dépôt
|
belaran@995
|
99 <filename class="directory">my-hello</filename> dans le dépôt
|
belaran@995
|
100 <filename class="directory">my-new-hello</filename>. L'historique qui
|
belaran@995
|
101 était déjà présent dans le dépôt <filename
|
belaran@995
|
102 class="directory">my-new-hello</filename> reste intact, mais une
|
belaran@995
|
103 nouvelle révision a été ajoutée. En vous reportant à la figure <xref
|
belaran@995
|
104 linkend="fig:tour-merge:sep-repos"/>, vous pouvez voir que le
|
belaran@995
|
105 <emphasis>ID de révision (changeset ID)</emphasis> reste le même dans
|
belaran@995
|
106 le nouveau dépôt, mais que le <emphasis>numéro de
|
belaran@995
|
107 révision</emphasis> reste le même. (Ceci est un parfait exemple de
|
belaran@995
|
108 pourquoi il n'est fiable d'utiliser les numéros de révision lorsque
|
belaran@995
|
109 l'on discute d'un \textit{changeset}.) Vous pouvez voir les "heads"
|
belaran@995
|
110 présentes dans le dépôt en utilisant la commande <command
|
belaran@995
|
111 role="hg-cmd">hg heads</command>.</para>
|
belaran@995
|
112
|
belaran@995
|
113 &interaction.tour.merge.heads;
|
belaran@995
|
114 </sect2>
|
belaran@995
|
115
|
belaran@995
|
116 <sect2>
|
belaran@995
|
117 <title>Effectuer la fusion</title>
|
belaran@995
|
118
|
belaran@995
|
119 <para id="x_344">Que se passe-t-il quand vous essayez d'utiliser la
|
belaran@995
|
120 commande <command role="hg-cmd">hg update</command> pour mettre à
|
belaran@995
|
121 jour votre espace de travail au nouveau "tip"</para>
|
belaran@995
|
122
|
belaran@995
|
123 &interaction.tour.merge.update;
|
belaran@995
|
124
|
belaran@995
|
125
|
belaran@995
|
126 <para id="x_345">Mercurial nous prévient que la commande <command
|
belaran@995
|
127 role="hg-cmd">hg update</command> n'effectuera pas
|
belaran@995
|
128 la fusion, il ne veut pas mettre à jour l'espace de travail quand il
|
belaran@995
|
129 estime que nous pourrions avoir besoin d'une fusion, à moins de lui
|
belaran@995
|
130 forcer la main. À la place, il faut utiliser la commande <command
|
belaran@995
|
131 role="hg-cmd">hg merge</command> pour fusionner les deux
|
belaran@995
|
132 "heads".</para>
|
belaran@995
|
133
|
belaran@995
|
134 <para id="x_723">Pour commencer une fusion (merge) entre deux "heads",
|
belaran@995
|
135 nous utilisons la commande <command role="hg-cmd">hg merge</command>.</para>
|
belaran@995
|
136
|
belaran@995
|
137 &interaction.tour.merge.merge;
|
belaran@995
|
138
|
belaran@995
|
139 <para id="x_347">Nous résolvons les conflits dans le fichier
|
belaran@995
|
140 <filename>hello.c</filename>. Ceci met à jour le répertoire de travail
|
belaran@995
|
141 de sorte qu'il ne contienne les modifications ne provenance des
|
belaran@995
|
142 <emphasis>deux</emphasis> "heads", ce qui est indiqué par la
|
belaran@995
|
143 la sortie de la commande <command role="hg-cmd">hg
|
belaran@995
|
144 parents</command> et le contenu du fichier
|
belaran@995
|
145 <filename>hello.c</filename>.</para>
|
belaran@995
|
146
|
belaran@995
|
147 &interaction.tour.merge.parents;
|
belaran@995
|
148 </sect2>
|
belaran@995
|
149
|
belaran@995
|
150 <sect2>
|
belaran@995
|
151 <title>Effectuer l'ajout (commit) du résultat de la fusion</title>
|
belaran@995
|
152
|
belaran@995
|
153 <para id="x_348">Dès l'instant où vous avez effectué une fusion
|
belaran@995
|
154 (merge), <command role="hg-cmd">hg parents</command> vous
|
belaran@995
|
155 affichera deux parents, avant que vous n'exécutiez la commande
|
belaran@995
|
156 <command role="hg-cmd">hg commit</command> sur le résultat de la
|
belaran@995
|
157 fusion.</para>
|
belaran@995
|
158
|
belaran@995
|
159 &interaction.tour.merge.commit;
|
belaran@995
|
160
|
belaran@995
|
161 <para id="x_349">Nous avons maintenant un nouveau tip, remarquer qu'il
|
belaran@995
|
162 contient <emphasis>à la fois</emphasis> nos anciennes "heads" et leurs
|
belaran@995
|
163 parents. Ce sont les mêmes révisions que nous avions affichées avec
|
belaran@995
|
164 la commande <command role="hg-cmd">hg parents</command>.</para>
|
belaran@995
|
165
|
belaran@995
|
166 &interaction.tour.merge.tip;
|
belaran@995
|
167
|
belaran@995
|
168 <para id="x_34a">Dans la figure <xref linkend="fig:tour-merge:merge"/>,
|
belaran@995
|
169 vous pouvez voir une représentation de ce qui se passe dans l'espace
|
belaran@995
|
170 de travail pendant la fusion, et comment ceci affecte le dépôt lors
|
belaran@995
|
171 du "commit". Pendant la fusion, l'espace de travail, qui a deux
|
belaran@995
|
172 révisions (changesets) comme parents, voit ces derniers devenir le parent
|
belaran@995
|
173 d'une nouvelle révision (changeset).</para>
|
belaran@995
|
174
|
belaran@995
|
175 <figure id="fig:tour-merge:merge">
|
belaran@995
|
176 <title>Working directory and repository during merge, and
|
belaran@995
|
177 following commit</title>
|
belaran@995
|
178 <mediaobject>
|
belaran@995
|
179 <imageobject>
|
belaran@995
|
180 <imagedata fileref="figs/tour-merge-merge.png"/>
|
belaran@995
|
181 </imageobject>
|
belaran@995
|
182 <textobject><phrase>XXX ajoute texte</phrase></textobject>
|
belaran@995
|
183 </mediaobject>
|
belaran@995
|
184 </figure>
|
belaran@995
|
185
|
belaran@995
|
186 </sect2>
|
belaran@995
|
187 </sect1>
|
belaran@995
|
188
|
belaran@995
|
189 <sect1>
|
belaran@995
|
190 <title>Fusionner les modifications en conflit</title>
|
belaran@995
|
191
|
belaran@995
|
192 <para id="x_34b">La plupart des fusions sont assez simple à réaliser, mais
|
belaran@995
|
193 parfois vous vous retrouverez à fusionner des fichiers où la modification
|
belaran@995
|
194 touche la même portion de code, au sein d'un même fichier. À moins
|
belaran@995
|
195 que ces modification ne soient identiques, ceci aboutira à un
|
belaran@995
|
196 <emphasis>conflit</emphasis>, et vous devrez décider comment réconcilier
|
belaran@995
|
197 les différentes modifications dans un tout cohérent.</para>
|
belaran@995
|
198
|
belaran@995
|
199 <figure>
|
belaran@995
|
200 <title>Modifications en conflits dans un document</title>
|
belaran@995
|
201 <mediaobject>
|
belaran@995
|
202 <imageobject><imagedata fileref="tour-merge-conflict"/></imageobject>
|
belaran@995
|
203 <textobject><phrase>XXX ajoute texte</phrase></textobject>
|
belaran@995
|
204 </mediaobject>
|
belaran@995
|
205 </figure>
|
belaran@995
|
206
|
belaran@995
|
207 <para id="x_34d">La figure <xref linkend="fig:tour-merge:conflict"/>
|
belaran@995
|
208 illustre un cas de modifications conflictuelles dans un document. Nous
|
belaran@995
|
209 avons commencé avec une version simple de ce fichier, puis nous avons
|
belaran@995
|
210 ajouté des modifications, pendant que quelqu'un d'autre modifiait le même
|
belaran@995
|
211 texte. Notre tâche dans la résolution du conflit est de décider à quoi le
|
belaran@995
|
212 fichier devrait ressembler.</para>
|
belaran@995
|
213
|
belaran@995
|
214 <para id="x_34e">Mercurial n'a pas de mécanisme interne pour gérer
|
belaran@995
|
215 les conflits. À la place, il exécute un programme externe appelé
|
belaran@995
|
216 <command>hgmerge</command>. Il s'agit d'un script shell qui est
|
belaran@995
|
217 embarqué par Mercurial, vous pouvez le modifier si vous le voulez.
|
belaran@995
|
218 Ce qu'il fait par défaut est d'essayer de trouver un des différents
|
belaran@995
|
219 outils de fusion qui seront probablement installés sur le système.
|
belaran@995
|
220 Il commence par les outils totalement automatiques, et si ils
|
belaran@995
|
221 échouent (parce que la résolution du conflit nécessite une
|
belaran@995
|
222 intervention humaine) ou si ils sont absents, le script tente
|
belaran@995
|
223 d'exécuter certains outils graphiques de fusion.</para>
|
belaran@995
|
224
|
belaran@995
|
225 <para id="x_34f">Il est aussi possible de demander à Mercurial d'exécuter
|
belaran@995
|
226 un autre programme ou un autre script en définissant la variable
|
belaran@995
|
227 d'environnement <envar>HGMERGE</envar> avec le nom
|
belaran@995
|
228 du programme de votre choix.</para>
|
belaran@995
|
229
|
belaran@995
|
230 <sect2>
|
belaran@995
|
231 <title>Utiliser un outil graphique de fusion</title>
|
belaran@995
|
232
|
belaran@995
|
233 <para id="x_350">Mon outil de fusion préféré est
|
belaran@995
|
234 <command>kdiff3</command>, que j'utilise ici pour illustrer les
|
belaran@995
|
235 fonctionnalités classiques des outils graphiques de fusion. Vous pouvez
|
belaran@995
|
236 voir une capture d'écran de l'utilisation de <command>kdiff3</command>
|
belaran@995
|
237 dans la figure <xref linkend="fig:tour-merge:kdiff3"/>. Cet outil
|
belaran@995
|
238 effectue une <emphasis>fusion \textit{three-way</emphasis>}, car il y a
|
belaran@995
|
239 trois différentes versions du fichier qui nous intéresse. Le fichier
|
belaran@995
|
240 découpe la partie supérieure de la fenêtre en trois panneaux:</para>
|
belaran@995
|
241 <itemizedlist>
|
belaran@995
|
242 <listitem><para id="x_351">A gauche on la version de
|
belaran@995
|
243 <emphasis>base</emphasis> du fichier, soit la plus récente version
|
belaran@995
|
244 des deux versions qu'on souhaite fusionner.</para></listitem>
|
belaran@995
|
245 <listitem><para id="x_352">Au centre, il y a <quote>notre</quote>
|
belaran@995
|
246 version du fichier, avec le contenu que nous avons modifié.</para></listitem>
|
belaran@995
|
247 <listitem><para id="x_353">Sur la droite, on trouve
|
belaran@995
|
248 <quote>leur</quote> version du fichier, celui qui contient la
|
belaran@995
|
249 révision que nous souhaitons intégré.</para>
|
belaran@995
|
250 </listitem></itemizedlist>
|
belaran@995
|
251 <para id="x_354">Dans le panneau en dessous, on trouve le
|
belaran@995
|
252 <emphasis>résultat</emphasis> actuel de notre fusion. Notre tâche
|
belaran@995
|
253 consiste donc à remplacement tous les textes en rouges,
|
belaran@995
|
254 qui indiquent des conflits non résolus, avec une fusion manuelle et
|
belaran@995
|
255 pertinente de <quote>notre</quote> version et de la <quote>leur</quote>.
|
belaran@995
|
256 </para>
|
belaran@995
|
257
|
belaran@995
|
258 <para id="">Tous les quatre panneaux sont <emphasis>accrochés ensemble</emphasis>,
|
belaran@995
|
259 si nous déroulons les ascenseurs verticalement ou horizontalement dans chacun
|
belaran@995
|
260 d'entre eux, les autres sont mis à jour avec la section correspondante dans leurs
|
belaran@995
|
261 fichiers respectifs.</para>
|
belaran@995
|
262
|
belaran@995
|
263 <figure id="fig:tour-merge:kdiff3">
|
belaran@995
|
264 <title>Utiliser <command>kdiff3</command> pour fusionner les
|
belaran@995
|
265 différentes version d'un fichier.</title>
|
belaran@995
|
266 <mediaobject>
|
belaran@995
|
267 <imageobject>
|
belaran@995
|
268 <imagedata width="100%" fileref="figs/kdiff3.png"/></imageobject>
|
belaran@995
|
269 <textobject>
|
belaran@995
|
270 <phrase>XXX ajoute texte</phrase>
|
belaran@995
|
271 </textobject>
|
belaran@995
|
272 </mediaobject>
|
belaran@995
|
273 </figure>
|
belaran@995
|
274
|
belaran@995
|
275 <para id="x_357">Pour chaque portion de fichier posant problème, nous
|
belaran@995
|
276 pouvons choisir de résoudre le conflit en utilisant une combinaison de
|
belaran@995
|
277 texte depuis la version de base, la notre, ou la leur. Nous pouvons
|
belaran@995
|
278 aussi éditer manuellement les fichiers à tout moment, si c'est nécessaire.</para>
|
belaran@995
|
279
|
belaran@995
|
280 <para id="x_358">Il y a <emphasis>beaucoup</emphasis> d'outils de
|
belaran@995
|
281 fusion disponibles, bien trop pour en parler de tous ici. Leurs
|
belaran@995
|
282 disponibilités varient selon les plate formes ainsi que leurs
|
belaran@995
|
283 avantages et inconvénients. La plupart sont optimisé pour
|
belaran@995
|
284 la fusion de fichier contenant un texte plat, certains sont spécialisé
|
belaran@995
|
285 dans un format de fichier précis (généralement XML).</para>
|
belaran@995
|
286 </sect2>
|
belaran@995
|
287
|
belaran@995
|
288 <sect2>
|
belaran@995
|
289 <title>Un exemple concret</title>
|
belaran@995
|
290
|
belaran@995
|
291 <para id="x_359">Dans cet exemple, nous allons reproduire la
|
belaran@995
|
292 modification de l'historique du fichier de la figure <xref
|
belaran@995
|
293 linkend="fig:tour-merge:conflict"/> ci dessus. Commençons par créer
|
belaran@995
|
294 un dépôt avec une version de base de notre document.</para>
|
belaran@995
|
295
|
belaran@995
|
296 &interaction.tour-merge-conflict.wife;
|
belaran@995
|
297
|
belaran@995
|
298 <para id="x_35a">Créons un clone de ce dépôt et faisons une
|
belaran@995
|
299 modification dans le fichier.</para>
|
belaran@995
|
300
|
belaran@995
|
301 &interaction.tour-merge-conflict.cousin;
|
belaran@995
|
302
|
belaran@995
|
303 <para id="x_35b">Et un autre clone, pour simuler que quelqu'un d'autre effectue une
|
belaran@995
|
304 modification sur le fichier. (Ceci pour suggérer qu'il n'est pas rare
|
belaran@995
|
305 de devoir effectuer des fusions (merges) avec vos propres travaux quand
|
belaran@995
|
306 vous isolez les tâches dans des dépôts distincts. En effet, vous
|
belaran@995
|
307 aurez alors à trouver et résoudre certains conflits).</para>
|
belaran@995
|
308
|
belaran@995
|
309 &interaction.tour-merge-conflict.son;
|
belaran@995
|
310
|
belaran@995
|
311 <para id="x_35c">Maintenant que ces deux versions différentes du même fichier sont
|
belaran@995
|
312 créées, nous allons configurer l'environnement de manière appropriée pour
|
belaran@995
|
313 exécuter notre fusion (merge).</para>
|
belaran@995
|
314
|
belaran@995
|
315 &interaction.tour-merge-conflict.pull;
|
belaran@995
|
316
|
belaran@995
|
317 <para id="x_35d">Dans cette exemple, je n'utiliserais pas la commande Mercurial
|
belaran@995
|
318 habituelle <command>hgmerge</command> pour effectuer le
|
belaran@995
|
319 fusion (merge), car il me faudrait abandonner ce joli petit exemple automatisé
|
belaran@995
|
320 pour utiliser un outil graphique. À la place, je vais définir la
|
belaran@995
|
321 variable d'environnement <envar>HGMERGE</envar> pour indiquer à
|
belaran@995
|
322 Mercurial d'utiliser la commande non-interactive <command>merge</command>.
|
belaran@995
|
323 Cette dernière est embarquée par de nombreux systèmes <quote>à la Unix</quote>.
|
belaran@995
|
324 Si vous exécutez cet exemple depuis votre ordinateur, ne vous
|
belaran@995
|
325 occupez pas de définir <envar>HGMERGE</envar>.</para>
|
belaran@995
|
326
|
belaran@995
|
327 &interaction.tour-merge-conflict.merge;
|
belaran@995
|
328
|
belaran@995
|
329
|
belaran@995
|
330 <para id="x_35f">Parce que <command>merge</command> ne peut pas résoudre
|
belaran@995
|
331 les modifications conflictuelles, il laisse des <emphasis>marqueurs de
|
belaran@995
|
332 différences</emphasis> à l'intérieur du fichier qui a des conflits,
|
belaran@995
|
333 indiquant clairement quelles lignes sont en conflits, et si elles
|
belaran@995
|
334 viennent de notre fichier ou du fichier externe.
|
belaran@995
|
335 </para>
|
belaran@995
|
336
|
belaran@995
|
337 <para id="x_360">Mercurial peut distinguer, à la manière dont la
|
belaran@995
|
338 commande <command>merge</command> se termine, qu'elle n'a pas été
|
belaran@995
|
339 capable d'effectuer la fusion (merge), alors il nous indique que nous
|
belaran@995
|
340 devons effectuer de nouveau cette opération. Ceci peut être très utile
|
belaran@995
|
341 si, par exemple, nous exécutons un outil graphique de fusion et que
|
belaran@995
|
342 nous le quittons sans nous rendre compte qu'il reste des conflits ou
|
belaran@995
|
343 simplement par erreur.</para>
|
belaran@995
|
344
|
belaran@995
|
345 <para id="x_361">Si la fusion (merge) automatique ou manuelle échoue,
|
belaran@995
|
346 il n'y a rien pour nous empêcher de <quote>corriger le tir</quote> en
|
belaran@995
|
347 modifiant nous même les fichiers, et enfin effectuer le "commit" du
|
belaran@995
|
348 fichier:</para>
|
belaran@995
|
349
|
belaran@995
|
350 &interaction.tour-merge-conflict.commit;
|
belaran@995
|
351
|
belaran@995
|
352 <note>
|
belaran@995
|
353 <title>Où est la <ocmmand>hg resolve</ocmmand> ?</title>
|
belaran@995
|
354
|
belaran@995
|
355 <para id="x_724">La commande <command>hg resolve</command> a été
|
belaran@995
|
356 introduit dans la version 1.1 de Mercurial, qui a été publié en
|
belaran@995
|
357 décembre 2008. Si vous utilisez une version plus anciennne de
|
belaran@995
|
358 Mercurial (exécutez la command <command>hg version</command> pour en
|
belaran@995
|
359 avoir le coeur net), cette commande ne sera pas disponible. Si votre
|
belaran@995
|
360 version de Mercurial est plus ancienne que la 1.1, vous devriez très
|
belaran@995
|
361 fortement considérer une mise à jour à une version plus récente avant
|
belaran@995
|
362 d'essayer de régler des fusions complexes.</para>
|
belaran@995
|
363 </note>
|
belaran@995
|
364 </sect2>
|
belaran@995
|
365 </sect1>
|
belaran@995
|
366
|
belaran@995
|
367 <sect1 id="sec:tour-merge:fetch">
|
belaran@995
|
368 <title>Simplification de la séquence pull-merge-commit</title>
|
belaran@995
|
369
|
belaran@995
|
370 <para id="x_362">La procédure pour effectuer la fusion indiquée
|
belaran@995
|
371 ci-dessus est simple, mais requiert le lancement de trois commandes à la
|
belaran@995
|
372 suite.</para>
|
belaran@995
|
373
|
belaran@995
|
374 <programlisting>hg pull -u
|
belaran@995
|
375 hg merge
|
belaran@995
|
376 hg commit -m 'Merged remote changes'</programlisting>
|
belaran@995
|
377
|
belaran@995
|
378 <para id="x_363">Lors du "commit" final, vous devez également saisir un
|
belaran@995
|
379 message, qui aura vraisemblablement assez peu d'intérêt.</para>
|
belaran@995
|
380
|
belaran@995
|
381 <para id="x_364">Il serait assez sympathique de pouvoir réduire le
|
belaran@995
|
382 nombre d'opérations nécessaire, si possible. De fait Mercurial est
|
belaran@995
|
383 fourni avec une extension appelé <literal role="hg-ext">fetch</literal>
|
belaran@995
|
384 qui fait justement cela.</para>
|
belaran@995
|
385
|
belaran@995
|
386 <para id="x_365">Mercurial fourni un mécanisme d'extension flexible qui permet à chacun
|
belaran@995
|
387 d'étendre ces fonctionnalités, tout en conservant le cœur de Mercurial
|
belaran@995
|
388 léger et facile à utiliser. Certains extensions ajoutent de nouvelles
|
belaran@995
|
389 commandes que vous pouvez utiliser en ligne de commande, alors que
|
belaran@995
|
390 d'autres travaillent <quote>en coulisse,</quote> par exemple en ajoutant des
|
belaran@995
|
391 possibilités au serveur.</para>
|
belaran@995
|
392
|
belaran@995
|
393 <para id="x_366">L'extension <literal role="hg-ext">fetch</literal>
|
belaran@995
|
394 ajoute une nouvelle commande nommée, sans surprise, <command
|
belaran@995
|
395 role="hg-cmd">hg fetch</command>. Cette extension résulte en une
|
belaran@995
|
396 combinaison de <command role="hg-cmd">hg pull</command>, <command
|
belaran@995
|
397 role="hg-cmd">hg update</command> and <command role="hg-cmd">hg
|
belaran@995
|
398 merge</command>. Elle commence par récupérer les modifications d'un
|
belaran@995
|
399 autre dépôt dans le dépôt courant. Si elle trouve que les
|
belaran@995
|
400 modifications ajoutent une nouvelle "head", elle effectue un "merge",
|
belaran@995
|
401 et ensuite "commit" le résultat du "merge" avec un message généré
|
belaran@995
|
402 automatiquement. Si aucune "head" n'ont été ajouté, elle met à jour le
|
belaran@995
|
403 répertoire de travail au niveau de la nouvelle révision tip.</para>
|
belaran@995
|
404
|
belaran@995
|
405 <para id="x_367">Activer l'extension <literal
|
belaran@995
|
406 role="hg-ext">fetch</literal> est facile. Modifiez votre <filename
|
belaran@995
|
407 role="special">.hgrc</filename>, et soit allez à la section <literal
|
belaran@995
|
408 role="rc-extensions">extensions</literal> soit créer une section
|
belaran@995
|
409 <literal role="rc-extensions">extensions</literal>. Ensuite ajoutez
|
belaran@995
|
410 une ligne qui consiste simplement en <quote>\Verb+fetch =</quote>.</para>
|
belaran@995
|
411
|
belaran@995
|
412 <programlisting>[extensions]
|
belaran@995
|
413 fetch =</programlisting>
|
belaran@995
|
414
|
belaran@995
|
415 <para id="x_368">(Normalement, sur la partie droite de
|
belaran@995
|
416 <quote><literal>=</literal></quote> devrait apparaître le chemin de
|
belaran@995
|
417 l'extension, mais étant donné que l'extension <literal
|
belaran@995
|
418 role="hg-ext">fetch</literal> fait partie de la distribution standard,
|
belaran@995
|
419 Mercurial sait où la trouver.) </para>
|
belaran@995
|
420
|
belaran@995
|
421 </sect1>
|
belaran@995
|
422
|
belaran@995
|
423 <sect1>
|
belaran@995
|
424 <title>Renommer, copier, et fusionner (merge)</title>
|
belaran@995
|
425
|
belaran@995
|
426 <para id="x_729">En cours de la vie d'un projet, nous allons souvent
|
belaran@995
|
427 vouloir changer la disposition de ses fichiers et de ses répertoires.
|
belaran@995
|
428 Ceci peut être aussi simple que de changer le nom d'un seul fichier,
|
belaran@995
|
429 et aussi compliqué que de restructurer une hiérarchie entiere de fichier
|
belaran@995
|
430 au sein du projet.</para>
|
belaran@995
|
431
|
belaran@995
|
432 <para id="x_72a">Mercurial permet de faire ce genre de modification de
|
belaran@995
|
433 manière fluide, à condition de l'informer de ce que nous faisons. Si
|
belaran@995
|
434 vous voulez renommenr un ficher, vous devriez utiliser les commande
|
belaran@995
|
435 <command>hg rename</command><footnote>
|
belaran@995
|
436 <para id="x_72b">Si vous un utilisateur de Unix, vous serez content
|
belaran@995
|
437 de savoir que la commande <command>hg rename</command> command
|
belaran@995
|
438 peut être abrégée en <command>hg mv</command>.</para>
|
belaran@995
|
439 </footnote> pour changer son nom, ainsi Mercurial peut ensuite prendre
|
belaran@995
|
440 la bonne décision, plus tard, en cas de fusionv (merge).</para>
|
belaran@995
|
441
|
belaran@995
|
442 <para id="x_72c">Nous étudierojns en détail l'utilisation de ces commandes,
|
belaran@995
|
443 en détail, dans le chapitre <xref linkend="chap:daily.copy"/>.</para>
|
belaran@995
|
444 </sect1>
|
belaran@964
|
445 </chapter>
|
belaran@964
|
446
|
belaran@964
|
447 <!--
|
belaran@964
|
448 local variables:
|
belaran@964
|
449 sgml-parent-document: ("00book.xml" "book" "chapter")
|
belaran@964
|
450 end:
|
belaran@976
|
451 -->
|