| rev |
line source |
|
bos@559
|
1 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
|
|
bos@559
|
2
|
|
bos@685
|
3 <chapter id="chap:daily">
|
|
bos@572
|
4 <?dbhtml filename="mercurial-in-daily-use.html"?>
|
|
youshe@990
|
5 <title>Mercurial pour une utilisation de tous les jours</title>
|
|
bos@559
|
6
|
|
bos@559
|
7 <sect1>
|
|
youshe@990
|
8 <title>Informer Mercurial des fichier à suivre</title>
|
|
youshe@990
|
9
|
|
youshe@990
|
10 <para id="x_1a3">Mercurial ne suit pas les fichiers de votre dépôt tant
|
|
youshe@990
|
11 que vous ne lui avez pas dit de les gérer. La commande <command
|
|
youshe@990
|
12 role="hg-cmd">hg status</command> vous dira quels fichiers sont
|
|
youshe@988
|
13 inconnus de Mercurial. Il utilise un
|
|
youshe@988
|
14 <quote><literal>?</literal></quote> pour montrer ces fichiers.</para>
|
|
youshe@988
|
15
|
|
youshe@988
|
16 <para id="x_1a4">Pour informer Mercurial de suivre un fichier, utilisez
|
|
youshe@988
|
17 la commande <command role="hg-cmd">hg add</command>. Une fois que vous
|
|
youshe@988
|
18 avez ajouté un fichier, la ligne correspondante à ce fichier dans la
|
|
youshe@988
|
19 sortie de <command role="hg-cmd">hg status</command> change de
|
|
youshe@988
|
20 <quote><literal>?</literal></quote> à
|
|
bos@567
|
21 <quote><literal>A</literal></quote>.</para>
|
|
bos@567
|
22
|
|
youshe@988
|
23 &interaction.daily.files.add;
|
|
youshe@988
|
24
|
|
youshe@988
|
25 <para id="x_1a5">Après avoir exécuté un <command role="hg-cmd">hg
|
|
youshe@990
|
26 commit</command>, les fichiers que vous avez ajoutés avant le commit
|
|
youshe@990
|
27 ne seront plus listés dans la sortie de <command role="hg-cmd">hg
|
|
youshe@990
|
28 status</command>. La raison de ceci est que, par défaut, <command
|
|
youshe@988
|
29 role="hg-cmd">hg status</command> ne vous montre que les fichiers
|
|
youshe@988
|
30 <quote>intéressants</quote> &emdash;ceux que vous avez (par exemple)
|
|
youshe@990
|
31 modifiés, supprimés ou renommés. Si vous aviez un dépôt qui contient un
|
|
youshe@990
|
32 millier de fichiers, vous ne voudriez certainement que rarement entendre
|
|
youshe@988
|
33 parler des fichiers que Mercurial suit, mais qui n'ont pas changés.
|
|
youshe@988
|
34 (Vous pouvez quand même avoir cette information, nous y reviendrons
|
|
youshe@988
|
35 plus tard.)</para>
|
|
youshe@988
|
36
|
|
youshe@988
|
37 <para id="x_1a6">Une fois que vous ajoutez un fichier, Mercurial ne fait
|
|
youshe@990
|
38 rien du tout avec celui-ci immédiatement. Au lieu de ça, il va prendre
|
|
youshe@988
|
39 un "snapshot" de l'état du fichier la prochaine fois que vous
|
|
youshe@988
|
40 exécuterez un commit. Il continuera ensuite à suivre les changements
|
|
youshe@990
|
41 que vous avez fait au fichier chaque fois que vous committerez, et ce,
|
|
youshe@990
|
42 jusqu'à ce que vous supprimiez le fichier.</para>
|
|
youshe@988
|
43
|
|
youshe@988
|
44 <sect2>
|
|
youshe@988
|
45 <title>Nommage des fichiers explicite versus implicite</title>
|
|
youshe@988
|
46
|
|
youshe@988
|
47 <para id="x_1a7">Un comportement utile que Mercurial possède est que si
|
|
youshe@988
|
48 vous passez le nom d'un répertoire à une commande, toute commande
|
|
youshe@990
|
49 Mercurial la traitera comme : <quote>Je veux opérer sur chaque fichier
|
|
youshe@988
|
50 dans ce répertoire et ses sous-répertoires</quote>.</para>
|
|
bos@567
|
51
|
|
bos@567
|
52 &interaction.daily.files.add-dir;
|
|
bos@567
|
53
|
|
youshe@988
|
54 <para id="x_1a8">Remarquez que dans cet exemple, Mercurial affiche le
|
|
youshe@988
|
55 nom des fichiers qu'il a ajouté, alors qu'il ne l'a pas fait lorsque
|
|
youshe@988
|
56 nous avons ajouté le fichier nommé <filename>myfile.txt</filename>
|
|
youshe@988
|
57 dans l'exemple précédent.</para>
|
|
youshe@988
|
58
|
|
youshe@988
|
59 <para id="x_1a9">Ce qu'il se passe est que dans le premier cas, nous
|
|
youshe@988
|
60 avons nommé explicitement le fichier à ajouter sur la ligne de
|
|
youshe@990
|
61 commande. Ce que Mercurial suppose dans ce cas est que nous savons ce
|
|
youshe@990
|
62 que nous faisons, il n'affiche donc rien en sortie.</para>
|
|
youshe@988
|
63
|
|
youshe@988
|
64 <para id="x_1aa">Cependant, lorsque nous avons
|
|
youshe@988
|
65 <emphasis>implicitement</emphasis> donné les fichiers à l'aide du nom
|
|
youshe@990
|
66 d'un répertoire, Mercurial prend l'initiative d'afficher le nom de
|
|
youshe@988
|
67 chaque fichier avec lequel il fait quelque chose. Ceci clarifie ce
|
|
youshe@990
|
68 qu'il se passe et réduit la probabilité d'une mauvaise surprise
|
|
youshe@990
|
69 restée silencieuse. Ce comportement est commun à la plupart des
|
|
youshe@990
|
70 commandes Mercurial.</para>
|
|
youshe@988
|
71 </sect2>
|
|
youshe@988
|
72 <sect2>
|
|
youshe@988
|
73 <title>Mercurial suit les fichiers, pas les répertoires</title>
|
|
youshe@988
|
74
|
|
youshe@988
|
75 <para id="x_1ab">Mercurial ne suit pas les informations sur les
|
|
youshe@990
|
76 répertoires. En contrepartie, il suit le chemin vers un fichier. Avant
|
|
youshe@988
|
77 de créer un fichier, il crée au préalable les répertoires manquants
|
|
youshe@988
|
78 dans le chemin. Après avoir supprimé un fichier, il supprime chaque
|
|
youshe@988
|
79 répertoire vide qui apparaît dans le chemin du fichier. Ceci apparaît
|
|
youshe@990
|
80 comme une distinction triviale, cependant, cela a une conséquence
|
|
youshe@988
|
81 pratique mineure : il n'est pas possible de représenter un répertoire
|
|
youshe@988
|
82 totalement vide dans Mercurial.</para>
|
|
youshe@988
|
83
|
|
youshe@988
|
84 <para id="x_1ac">Les répertoires vides sont rarement utiles. Il existe
|
|
youshe@990
|
85 cependant des solutions alternatives et non intrusives que vous
|
|
youshe@990
|
86 pouvez utiliser pour obtenir l'effet approprié. Les développeurs de
|
|
youshe@990
|
87 Mercurial ont ainsi pensé que la complexité requise pour gérer les
|
|
youshe@990
|
88 répertoires n'était pas aussi importante que le bénéfice que cette
|
|
youshe@990
|
89 fonctionnalité apporterait.</para>
|
|
youshe@988
|
90
|
|
youshe@988
|
91 <para id="x_1ad">Si vous avez besoin d'un répertoire vide dans votre
|
|
youshe@988
|
92 dépôt, il existe quelques façons d'y arriver. L'une d'elles est de
|
|
youshe@990
|
93 créer un répertoire et ensuite, de faire un <command role="hg-cmd">hg
|
|
youshe@990
|
94 add</command> sur un fichier <quote>caché</quote> dans ce
|
|
youshe@990
|
95 répertoire. Sur les systèmes de type Unix, tout fichier dont le nom
|
|
youshe@988
|
96 commence avec un point (<quote><literal>.</literal></quote>) est
|
|
youshe@988
|
97 considéré comme caché par la plupart des commandes et outils
|
|
youshe@990
|
98 graphiques. Cette approche est illustrée ci-après.</para>
|
|
youshe@988
|
99
|
|
youshe@988
|
100 &interaction.daily.files.hidden;
|
|
youshe@988
|
101
|
|
youshe@988
|
102 <para id="x_1ae">Une autre façon de s'attaquer au besoin d'un
|
|
youshe@990
|
103 répertoire vide est de simplement d'en créer un dans vos scripts
|
|
youshe@988
|
104 de construction avant qu'ils n'en aient le besoin.</para>
|
|
bos@559
|
105 </sect2>
|
|
bos@559
|
106 </sect1>
|
|
bos@674
|
107
|
|
bos@559
|
108 <sect1>
|
|
youshe@988
|
109 <title>Comment arrêter de suivre un fichier</title>
|
|
youshe@988
|
110
|
|
youshe@988
|
111 <para id="x_1af">Une fois que vous décidez qu'un fichier n'appartient
|
|
youshe@988
|
112 plus à votre dépôt, utilisez la commande <command role="hg-cmd">hg
|
|
youshe@988
|
113 remove</command>. Ceci supprime le fichier et informe Mercurial
|
|
youshe@988
|
114 d'arrêter de le suivre (ce qui prendra effet lors du prochain commit).
|
|
youshe@988
|
115 Un fichier supprimé est représenté dans la sortie de la commande
|
|
youshe@988
|
116 <command role="hg-cmd">hg status</command> par un
|
|
bos@567
|
117 <quote><literal>R</literal></quote>.</para>
|
|
bos@567
|
118
|
|
bos@567
|
119 &interaction.daily.files.remove;
|
|
bos@559
|
120
|
|
youshe@988
|
121 <para id="x_1b0">Après avoir fait un <command role="hg-cmd">hg
|
|
youshe@988
|
122 remove</command> sur un fichier, Mercurial ne suivra plus aucun
|
|
youshe@988
|
123 changement sur ce fichier, même si vous recréez un fichier avec le même
|
|
youshe@990
|
124 nom dans votre répertoire de travail. Si vous recréez un fichier avec le
|
|
youshe@988
|
125 même nom et que vous désirez que Mercurial suive ce dernier, faite
|
|
youshe@988
|
126 simplement un <command role="hg-cmd">hg add</command> sur celui-ci.
|
|
youshe@988
|
127 Mercurial saura alors que le nouveau fichier ne fait pas référence à
|
|
youshe@988
|
128 l'ancien fichier qui portait le même nom.</para>
|
|
youshe@988
|
129
|
|
youshe@988
|
130 <sect2>
|
|
youshe@988
|
131 <title>Supprimer un fichier n'affecte pas son historique</title>
|
|
youshe@988
|
132
|
|
youshe@990
|
133 <para id="x_1b1">Il est important de comprendre que supprimer un fichier
|
|
youshe@988
|
134 n'a que deux effets.</para>
|
|
youshe@988
|
135
|
|
bos@559
|
136 <itemizedlist>
|
|
youshe@988
|
137 <listitem><para id="x_1b2">Il supprime la version actuelle de ce
|
|
youshe@988
|
138 fichier du répertoire de travail.</para>
|
|
youshe@988
|
139 </listitem>
|
|
youshe@988
|
140 <listitem><para id="x_1b3">Il arrête, à partir du prochain commit, le
|
|
youshe@988
|
141 suivi de Mercurial sur les changements qui ont lieu sur ce
|
|
youshe@988
|
142 fichier.</para>
|
|
youshe@988
|
143 </listitem></itemizedlist>
|
|
youshe@988
|
144
|
|
youshe@988
|
145 <para id="x_1b4">Supprimer un fichier <emphasis>n'</emphasis>affecte en
|
|
youshe@988
|
146 <emphasis>aucun</emphasis> cas l'<emphasis>historique</emphasis> du
|
|
youshe@988
|
147 fichier.</para>
|
|
youshe@988
|
148
|
|
youshe@988
|
149 <para id="x_1b5">Si vous mettez à jour le répertoire de travail à un
|
|
youshe@990
|
150 changeset qui a été committé alors que le fichier que vous venez de
|
|
youshe@990
|
151 supprimer était encore suivi, ce fichier réapparaîtra dans le
|
|
youshe@988
|
152 répertoire de travail, avec le contenu qu'il avait lorsque vous aviez
|
|
youshe@990
|
153 committé ce changeset. Si vous mettez à jour (update) le répertoire de
|
|
youshe@990
|
154 travail à un changeset ultérieur dans lequel le fichier a été
|
|
youshe@988
|
155 supprimé, Mercurial supprimera une nouvelle fois le fichier du
|
|
youshe@988
|
156 répertoire de travail.</para>
|
|
youshe@988
|
157 </sect2>
|
|
youshe@988
|
158
|
|
youshe@988
|
159 <sect2>
|
|
youshe@990
|
160 <title>Fichiers manquants</title>
|
|
youshe@988
|
161
|
|
youshe@988
|
162 <para id="x_1b6">Mercurial considère qu'un fichier que vous avez
|
|
youshe@988
|
163 supprimé sans utiliser<command role="hg-cmd">hg remove</command>
|
|
youshe@988
|
164 comme étant <emphasis>manquant</emphasis>. Un fichier manquant est
|
|
youshe@988
|
165 représenté avec un <quote><literal>!</literal></quote> en sortie de
|
|
youshe@988
|
166 <command role="hg-cmd">hg status</command>.
|
|
youshe@988
|
167 Les commandes Mercurial ne feront rien avec les fichiers
|
|
youshe@988
|
168 manquants.</para>
|
|
bos@567
|
169
|
|
bos@567
|
170 &interaction.daily.files.missing;
|
|
bos@559
|
171
|
|
youshe@988
|
172 <para id="x_1b7">Si votre dépôt contient un fichier que <command
|
|
youshe@990
|
173 role="hg-cmd">hg status</command> reporte comme manquant, et que
|
|
youshe@988
|
174 vous voulez que ce fichier reste supprimé, vous pouvez exécuter
|
|
youshe@988
|
175 <command role="hg-cmd">hg remove <option
|
|
youshe@988
|
176 role="hg-opt-remove">--after</option></command> à tout moment
|
|
youshe@988
|
177 pour dire à Mercurial que vous aviez bien voulu supprimer ce
|
|
youshe@988
|
178 fichier.</para>
|
|
bos@567
|
179
|
|
bos@567
|
180 &interaction.daily.files.remove-after;
|
|
bos@559
|
181
|
|
youshe@988
|
182 <para id="x_1b8">D'un autre coté, si vous avez supprimé le fichier
|
|
youshe@988
|
183 manquant par accident, donnez à la commande <command role="hg-cmd">hg
|
|
youshe@990
|
184 revert</command> le nom du fichier à retrouver. Il réapparaitra dans
|
|
youshe@988
|
185 sa forme non modifiée.</para>
|
|
bos@559
|
186
|
|
bos@674
|
187 &interaction.daily.files.recover-missing;
|
|
youshe@988
|
188
|
|
youshe@988
|
189 </sect2>
|
|
youshe@988
|
190
|
|
youshe@988
|
191 <sect2>
|
|
youshe@988
|
192 <title>Entre nous : Pourquoi dire explicitement à Mercurial de supprimer un
|
|
youshe@988
|
193 fichier ?</title>
|
|
youshe@988
|
194
|
|
youshe@988
|
195 <para id="x_1b9">Vous pourriez vous demander pourquoi il est nécessaire
|
|
youshe@990
|
196 de dire explicitement à Mercurial que vous souhaitez supprimer un
|
|
youshe@988
|
197 fichier. Au début du développement de Mercurial, celui ci vous
|
|
youshe@988
|
198 laissait pourtant supprimer un fichier sans soucis ; Mercurial vous
|
|
youshe@988
|
199 aurait automatiquement informé de l'absence du fichier lorsque vous
|
|
youshe@988
|
200 auriez lancé un <command role="hg-cmd">hg commit</command> et arrêté
|
|
youshe@988
|
201 de le suivre. En pratique, ceci a montré qu'il était trop facile de
|
|
youshe@988
|
202 supprimer accidentellement un fichier sans le remarquer.</para>
|
|
youshe@988
|
203 </sect2>
|
|
youshe@988
|
204
|
|
youshe@988
|
205 <sect2>
|
|
youshe@990
|
206 <title>Raccourci utile&emdash;ajouter et supprimer des fichiers en une
|
|
youshe@988
|
207 seule étape.</title>
|
|
youshe@988
|
208
|
|
youshe@988
|
209 <para id="x_1ba">Mercurial offre une commande combinée, <command
|
|
youshe@988
|
210 role="hg-cmd">hg addremove</command>, qui ajoute les fichiers non
|
|
youshe@988
|
211 suivis et marque les fichiers manquants comme supprimés.</para>
|
|
bos@567
|
212
|
|
bos@567
|
213 &interaction.daily.files.addremove;
|
|
bos@567
|
214
|
|
youshe@988
|
215 <para id="x_1bb">La commande <command role="hg-cmd">hg commit</command>
|
|
youshe@988
|
216 fournit aussi une option <option role="hg-opt-commit">-A</option> qui
|
|
youshe@988
|
217 exécute le même ajouter-et-supprimer, immédiatement suivi d'un
|
|
youshe@988
|
218 commit.</para>
|
|
bos@567
|
219
|
|
bos@567
|
220 &interaction.daily.files.commit-addremove;
|
|
youshe@988
|
221
|
|
bos@559
|
222 </sect2>
|
|
bos@559
|
223 </sect1>
|
|
bos@674
|
224
|
|
bos@701
|
225 <sect1 id="chap:daily.copy">
|
|
youshe@988
|
226 <title>Copier des fichiers</title>
|
|
youshe@988
|
227
|
|
youshe@988
|
228 <para id="x_1bc">Mercurial fournit une commande <command role="hg-cmd">hg
|
|
youshe@988
|
229 copy</command> qui vous permet de faire une nouvelle copie d'un
|
|
youshe@988
|
230 fichier. Lorsque vous copiez un fichier en utilisant cette commande,
|
|
youshe@988
|
231 Mercurial crée un enregistrement du fait que ce nouveau fichier est une
|
|
youshe@988
|
232 copie du fichier originel. Il traite ces fichiers copiés spécialement
|
|
youshe@990
|
233 lorsque vous fusionnez (merge) votre travail avec quelqu'un
|
|
youshe@988
|
234 d'autre.</para>
|
|
youshe@988
|
235
|
|
youshe@988
|
236 <sect2>
|
|
youshe@990
|
237 <title>Les résultats d'une copie durant une fusion (merge)</title>
|
|
youshe@988
|
238
|
|
youshe@988
|
239 <para id="x_1bd">Ce qu'il se passe durant une fusion (merge) est que
|
|
youshe@988
|
240 les changements <quote>suivent</quote> une copie. Pour illustrer ce
|
|
youshe@990
|
241 que cela veut dire de la meilleure façon, créons un exemple. Nous
|
|
youshe@988
|
242 allons commencer avec le mini dépôt usuel qui contient un simple
|
|
youshe@988
|
243 fichier.</para>
|
|
bos@567
|
244
|
|
bos@567
|
245 &interaction.daily.copy.init;
|
|
bos@567
|
246
|
|
youshe@988
|
247 <para id="x_1be">Nous devons faire du travail en parallèle, ainsi,
|
|
youshe@988
|
248 nous aurons quelque chose à fusionner (merge). Donc clonons notre
|
|
youshe@988
|
249 dépôt.</para>
|
|
bos@567
|
250
|
|
bos@567
|
251 &interaction.daily.copy.clone;
|
|
bos@567
|
252
|
|
youshe@988
|
253 <para id="x_1bf">De retour dans notre dépôt initial, utilisons la
|
|
youshe@988
|
254 commande <command role="hg-cmd">hg copy</command> pour faire une
|
|
youshe@988
|
255 copie du premier fichier que nous avons créé.</para>
|
|
bos@567
|
256
|
|
bos@567
|
257 &interaction.daily.copy.copy;
|
|
bos@559
|
258
|
|
youshe@988
|
259 <para id="x_1c0">Si nous regardons ensuite à la sortie de la commande
|
|
youshe@988
|
260 <command role="hg-cmd">hg status</command>, les fichiers copiés
|
|
youshe@988
|
261 ont l'air de fichiers normalement ajoutés.</para>
|
|
bos@567
|
262
|
|
bos@567
|
263 &interaction.daily.copy.status;
|
|
bos@567
|
264
|
|
youshe@988
|
265 <para id="x_1c1">Mais si nous passons l'option <option
|
|
youshe@988
|
266 role="hg-opt-status">-C</option> à <command role="hg-cmd">hg
|
|
youshe@988
|
267 status</command>, il affiche une autre ligne de sortie : il s'agit
|
|
youshe@988
|
268 du fichier <emphasis>source</emphasis> pour notre copie.</para>
|
|
bos@567
|
269
|
|
bos@567
|
270 &interaction.daily.copy.status-copy;
|
|
bos@559
|
271
|
|
youshe@988
|
272 <para id="x_1c2">Maintenant, de retour dans le dépôt que nous avons
|
|
youshe@990
|
273 cloné, créons un changement en parallèle. Nous allons ajouter une
|
|
youshe@988
|
274 ligne de contenu au fichier original qui a été créé.</para>
|
|
bos@567
|
275
|
|
bos@567
|
276 &interaction.daily.copy.other;
|
|
bos@567
|
277
|
|
youshe@990
|
278 <para id="x_1c3">Nous avons alors un fichier <filename>file</filename>
|
|
youshe@990
|
279 modifié dans ce dépôt. Lorsque nous récupérons (pull) les changements
|
|
youshe@990
|
280 depuis le premier répertoire et fusionnons (merge) les deux "heads",
|
|
youshe@990
|
281 Mercurial propagera les changements que nous avons faits localement
|
|
youshe@990
|
282 au fichier <filename>file</filename> dans sa copie
|
|
youshe@988
|
283 <filename>new-file</filename>.</para>
|
|
bos@567
|
284
|
|
bos@567
|
285 &interaction.daily.copy.merge;
|
|
youshe@988
|
286
|
|
youshe@988
|
287 </sect2>
|
|
bos@559
|
288 <sect2 id="sec:daily:why-copy">
|
|
youshe@990
|
289 <title>Pourquoi est-ce que les changements devraient suivre les copies
|
|
youshe@990
|
290 ?</title>
|
|
youshe@988
|
291
|
|
youshe@988
|
292 <para id="x_1c4">Ce comportement&emdash;des changements d'un fichiers
|
|
youshe@988
|
293 qui se propagent aux copies de ce fichier&emdash;peut sembler
|
|
youshe@988
|
294 ésotérique, mais, dans la plupart des cas, c'est hautement
|
|
youshe@988
|
295 désirable.</para>
|
|
youshe@988
|
296
|
|
youshe@988
|
297 <para id="x_1c5">Pour commencer, souvenez vous que cette propagation
|
|
youshe@988
|
298 a lieue <emphasis>seulement</emphasis> lors des fusions (merge).
|
|
youshe@988
|
299 Donc, si vous faites un <command role="hg-cmd">hg copy</command> sur
|
|
youshe@988
|
300 un fichier, et par la suite modifiez le fichier original durant le
|
|
youshe@988
|
301 cours normal de votre travail, rien n'a lieu.</para>
|
|
youshe@988
|
302
|
|
youshe@988
|
303 <para id="x_1c6">La deuxième chose à savoir c'est que les modifications
|
|
youshe@988
|
304 ne se propageront à travers une copie que si le changeset à partir
|
|
youshe@988
|
305 duquel vous faites une fusion (merge) <emphasis>n'a pas encore
|
|
youshe@988
|
306 vu</emphasis> la copie.</para>
|
|
youshe@988
|
307
|
|
youshe@988
|
308 <para id="x_1c7">La raison pour laquelle Mercurial fait ainsi est une
|
|
youshe@990
|
309 règle. Imaginons que je corrige un important bug dans un fichier source
|
|
youshe@990
|
310 et que je commit mes changements. Pendant ce temps, vous avez décidé de
|
|
youshe@988
|
311 faire un <command role="hg-cmd">hg copy</command> du fichier dans
|
|
youshe@990
|
312 votre dépôt, sans rien savoir au sujet du bug ou à propos de la
|
|
youshe@990
|
313 correction. Vous avez alors commencé à "hacker" sur votre copie du
|
|
youshe@990
|
314 fichier.</para>
|
|
youshe@988
|
315
|
|
youshe@988
|
316 <para id="x_1c8">Si vous aviez récupéré (pull) et fusionné (merge) mes
|
|
youshe@988
|
317 changements, et que Mercurial <emphasis>n'avait pas</emphasis>
|
|
youshe@988
|
318 propagé les changements à travers les copies, votre nouveau fichier
|
|
youshe@990
|
319 source contiendrait maintenant le bug, et à moins que vous ne sachiez
|
|
youshe@988
|
320 qu'il faille propager la correction du bug à la main, le bug aurait
|
|
youshe@988
|
321 <emphasis>subsisté</emphasis> dans votre copie du fichier.</para>
|
|
youshe@988
|
322
|
|
youshe@988
|
323 <para id="x_1c9">En propageant automatiquement les changements qui
|
|
youshe@988
|
324 fixent les bugs à partir du fichier original vers les copies,
|
|
youshe@988
|
325 Mercurial prévient ce type de problèmes. A ma connaissance, Mercurial
|
|
youshe@988
|
326 est le <emphasis>seul</emphasis> système de gestion de révisions qui
|
|
youshe@988
|
327 propage les changements à travers les copies comme ceci.</para>
|
|
youshe@988
|
328
|
|
youshe@988
|
329 <para id="x_1ca">Une fois que votre historique des changements a un
|
|
youshe@990
|
330 enregistrement concernant une copie et qu'une fusion postérieure a
|
|
youshe@988
|
331 eu lieue, il n'y a d'habitude pas d'autre besoin de propager les
|
|
youshe@990
|
332 changements du fichier originel vers le fichier copié. C'est pourquoi
|
|
youshe@990
|
333 Mercurial ne propage les changements à travers les copies qu'à la
|
|
youshe@990
|
334 première fusion, et pas d'avantage.</para>
|
|
youshe@988
|
335 </sect2>
|
|
youshe@988
|
336
|
|
youshe@988
|
337 <sect2>
|
|
youshe@988
|
338 <title>Comment faire des changements qui <emphasis>ne</emphasis>
|
|
youshe@988
|
339 suivent <emphasis>pas</emphasis> une copie</title>
|
|
youshe@988
|
340
|
|
youshe@988
|
341 <para id="x_1cb">Si pour une raison ou une autre, vous décidez que
|
|
youshe@988
|
342 cette fonctionnalité de propager automatiquement les changements à
|
|
youshe@988
|
343 travers les copies n'est pas pour vous, utilisez simplement la
|
|
youshe@988
|
344 commande normale de copie de votre système (sur les systèmes de type
|
|
youshe@988
|
345 Unix, il s'agit de <command>cp</command>) pour faire une copie d'un
|
|
youshe@988
|
346 fichier. Utilisez ensuite <command role="hg-cmd">hg add</command>
|
|
youshe@988
|
347 pour ajouter les nouveaux fichiers à la main. Cependant, avant d'en
|
|
youshe@988
|
348 faire ainsi, relisez <xref linkend="sec:daily:why-copy"/>, et faites
|
|
youshe@990
|
349 un choix en connaissance de cause comme quoi cette fonctionnalité
|
|
youshe@990
|
350 n'est pas appropriée à votre cas spécifique.</para>
|
|
youshe@988
|
351
|
|
youshe@988
|
352 </sect2>
|
|
youshe@988
|
353 <sect2>
|
|
youshe@988
|
354 <title>Comportement de la commande <command role="hg-cmd">hg copy</command></title>
|
|
youshe@988
|
355
|
|
youshe@988
|
356 <para id="x_1cc">Lorsque vous utilisez la commande <command
|
|
youshe@988
|
357 role="hg-cmd">hg copy</command>, Mercurial crée une copie de chaque
|
|
youshe@988
|
358 fichier source tel qu'il est actuellement dans le répertoire de
|
|
youshe@990
|
359 travail. Cela signifie que si vous effectuez des modifications sur un
|
|
youshe@988
|
360 fichier, puis faites un <command role="hg-cmd">hg copy</command> sur
|
|
youshe@990
|
361 celui-ci sans avoir au préalable committé ces changements, la nouvelle
|
|
youshe@988
|
362 copie contiendra aussi les modifications que vous avez fait jusqu'à
|
|
youshe@990
|
363 ce point. (Je trouve ce comportement quelque peu contre intuitif,
|
|
youshe@990
|
364 c'est pourquoi j'en fais mention ici.)</para>
|
|
youshe@990
|
365 <!-- Vérifier que je n'ai pas fait de contre sens en relisant la
|
|
youshe@990
|
366 version anglaise, ce que je comprend ici me paraît un peu bizarre -->
|
|
youshe@988
|
367
|
|
youshe@988
|
368 <para id="x_1cd">La commande <command role="hg-cmd">hg copy</command>
|
|
youshe@988
|
369 agit comme la commande Unix <command>cp</command> (vous pouvez
|
|
youshe@988
|
370 utilisez l'alias <command role="hg-cmd">hg cp</command> si vous
|
|
youshe@988
|
371 préférez). Nous devons lui donner deux ou plus arguments où le
|
|
youshe@988
|
372 dernier est considéré comme la <emphasis>destination</emphasis>, et
|
|
youshe@988
|
373 les autres comme les <emphasis>sources</emphasis>.</para>
|
|
youshe@988
|
374
|
|
youshe@988
|
375 <para id="x_685">Si vous passez à <command role="hg-cmd">hg
|
|
youshe@988
|
376 copy</command> un seul fichier source, et que la destination
|
|
youshe@988
|
377 n'existe pas, ceci créera un nouveau fichier avec ce nom.</para>
|
|
bos@567
|
378
|
|
bos@567
|
379 &interaction.daily.copy.simple;
|
|
youshe@988
|
380
|
|
youshe@988
|
381 <para id="x_1ce">Si la destination est un répertoire, Mercurial copie
|
|
youshe@988
|
382 les sources dans ce répertoire.</para>
|
|
bos@567
|
383
|
|
bos@567
|
384 &interaction.daily.copy.dir-dest;
|
|
bos@567
|
385
|
|
youshe@988
|
386 <para id="x_1cf">La copie de répertoire est récursive et préserve la
|
|
youshe@988
|
387 structure du répertoire source.</para>
|
|
bos@567
|
388
|
|
bos@567
|
389 &interaction.daily.copy.dir-src;
|
|
bos@567
|
390
|
|
youshe@988
|
391 <para id="x_1d0">Si la source et la destination sont tous deux des
|
|
youshe@990
|
392 répertoires, l'arborescence de la source est recréée dans le
|
|
youshe@988
|
393 répertoire destination.</para>
|
|
youshe@988
|
394
|
|
youshe@988
|
395 &interaction.daily.copy.dir-src-dest;
|
|
youshe@988
|
396
|
|
youshe@988
|
397 <para id="x_1d1">Comme avec la commande <command role="hg-cmd">hg
|
|
youshe@988
|
398 remove</command>, si vous copiez un fichier manuellement et voulez
|
|
youshe@988
|
399 que Mercurial sache qu'il s'agit d'une copie, utilisez simplement
|
|
youshe@988
|
400 l'option <option role="hg-opt-copy">--after</option> avec <command
|
|
youshe@988
|
401 role="hg-cmd">hg copy</command>.</para>
|
|
bos@567
|
402
|
|
bos@567
|
403 &interaction.daily.copy.after;
|
|
bos@559
|
404 </sect2>
|
|
bos@559
|
405 </sect1>
|
|
bos@674
|
406
|
|
bos@559
|
407 <sect1>
|
|
youshe@988
|
408 <title>Renommer les fichiers</title>
|
|
youshe@988
|
409
|
|
youshe@988
|
410 <para id="x_1d2">Il est plus commun d'avoir besoin de renommer un
|
|
youshe@988
|
411 fichier que d'en faire une copie. La raison pour laquelle j'ai discuté
|
|
youshe@988
|
412 de la commande <command role="hg-cmd">hg copy</command> avant de parler
|
|
youshe@988
|
413 de renommage des fichiers est que Mercurial traite les renommages
|
|
youshe@990
|
414 essentiellement comme une copie. Ainsi, savoir comment Mercurial traite
|
|
youshe@988
|
415 les copies de fichiers vous informe sur ce que vous êtes en droit
|
|
youshe@988
|
416 d'attendre lorsque vous renommez un fichier.</para>
|
|
youshe@988
|
417
|
|
youshe@988
|
418 <para id="x_1d3">Lorsque vous utilisez la commande <command
|
|
youshe@990
|
419 role="hg-cmd">hg rename</command>, Mercurial crée une copie de tous
|
|
youshe@990
|
420 les fichiers sources, les supprime et marque ces fichiers comme étant
|
|
youshe@988
|
421 supprimés.</para>
|
|
youshe@988
|
422
|
|
youshe@988
|
423 &interaction.daily.rename.rename;
|
|
youshe@988
|
424
|
|
youshe@988
|
425 <para id="x_1d4">La commande <command role="hg-cmd">hg status</command>
|
|
youshe@990
|
426 montre les nouveaux fichiers comme ajoutés et les fichiers originaux
|
|
youshe@990
|
427 comme supprimés.</para>
|
|
bos@567
|
428
|
|
bos@567
|
429 &interaction.daily.rename.status;
|
|
bos@567
|
430
|
|
youshe@988
|
431 <para id="x_1d5">A cause du <command role="hg-cmd">hg copy</command>,
|
|
youshe@988
|
432 nous devons utiliser l'option <option role="hg-opt-status">-C</option>
|
|
youshe@990
|
433 pour la commande <command role="hg-cmd">hg status</command> afin
|
|
youshe@990
|
434 d'observer que le fichier ajouté est bien suivi par Mercurial comme
|
|
youshe@990
|
435 étant une copie de l'original maintenant supprimé.</para>
|
|
bos@567
|
436
|
|
bos@567
|
437 &interaction.daily.rename.status-copy;
|
|
bos@559
|
438
|
|
youshe@988
|
439 <para id="x_1d6">Comme avec <command role="hg-cmd">hg remove</command> et
|
|
youshe@988
|
440 <command role="hg-cmd">hg copy</command>, vous pouvez informer
|
|
youshe@990
|
441 Mercurial au sujet d'un renommage après coup en utilisant l'option
|
|
youshe@988
|
442 <option role="hg-opt-rename">--after</option>. Dans le plus grand
|
|
youshe@990
|
443 respect, le comportement de la commande <command role="hg-cmd">hg
|
|
youshe@988
|
444 rename</command>, et les options qu'il accepte sont similaires à la
|
|
youshe@988
|
445 commande <command role="hg-cmd">hg copy</command>.</para>
|
|
youshe@988
|
446
|
|
youshe@990
|
447 <para id="x_686">Si vous êtes familier avec la ligne de commande Unix,
|
|
youshe@988
|
448 vous serez heureux d'apprendre que la commande <command
|
|
youshe@988
|
449 role="hg-cmd">hg rename</command> peut être invoquée par <command
|
|
youshe@988
|
450 role="hg-cmd">hg mv</command>.</para>
|
|
youshe@988
|
451
|
|
youshe@988
|
452 <sect2>
|
|
youshe@988
|
453 <title>Renommer les fichiers et fusionner (merge) les changements</title>
|
|
youshe@988
|
454
|
|
youshe@990
|
455 <para id="x_1d7">Puise que le "rename" de Mercurial est implanté comme un
|
|
youshe@990
|
456 "copy-and-remove", la même propagation des changements a lieue après
|
|
youshe@990
|
457 un "rename" qu'après un "copy" lorsque vous fusionnez (merge).</para>
|
|
youshe@988
|
458
|
|
youshe@988
|
459 <para id="x_1d8">Si je modifie un fichier et que vous le renommez, si
|
|
youshe@988
|
460 ensuite nous fusionnons nos changements respectifs, mes modifications
|
|
youshe@988
|
461 sur le fichier sous son nom originel seront propagés vers le même
|
|
youshe@988
|
462 fichier sous son nouveau nom. (C'est quelque chose que vous pourriez
|
|
youshe@988
|
463 espérer voir <quote>fonctionner simplement</quote>, mais tous les
|
|
youshe@988
|
464 systèmes de gestion de version ne le font pas.)</para>
|
|
youshe@988
|
465
|
|
youshe@988
|
466 <para id="x_1d9">Tandis qu'avoir des changements qui suivent une copie
|
|
youshe@988
|
467 est une fonctionnalité où vous hocheriez sûrement la tête en disant
|
|
youshe@988
|
468 <quote>oui, cela pourrait être utile</quote>, il est clair que les
|
|
youshe@988
|
469 voir suivre un renommage est définitivement important. Sans cette
|
|
youshe@990
|
470 aptitude, il serait vraiment trop facile d'avoir des changements
|
|
youshe@988
|
471 qui deviennent orphelins lorsque des fichiers sont renommés.</para>
|
|
youshe@988
|
472 </sect2>
|
|
youshe@988
|
473
|
|
youshe@988
|
474 <sect2>
|
|
youshe@988
|
475 <title>Renommages divergeants et fusion (merge)</title>
|
|
youshe@988
|
476
|
|
youshe@988
|
477 <para id="x_1da">Le cas de noms divergeants a lieu lorsque deux
|
|
youshe@990
|
478 développeurs commencent avec un fichier&emdash;appelons le
|
|
youshe@988
|
479 <filename>foo</filename>&emdash;dans leurs dépôts respectifs.</para>
|
|
bos@559
|
480
|
|
bos@567
|
481 &interaction.rename.divergent.clone;
|
|
bos@567
|
482
|
|
youshe@988
|
483 <para id="x_1db">Anne renomme le fichier en
|
|
youshe@988
|
484 <filename>bar</filename>.</para>
|
|
bos@567
|
485
|
|
bos@567
|
486 &interaction.rename.divergent.rename.anne;
|
|
bos@567
|
487
|
|
youshe@988
|
488 <para id="x_1dc">Pendant ce temps, Bob le renomme en
|
|
youshe@988
|
489 <filename>quux</filename>. (Souvenez vous que <command
|
|
youshe@988
|
490 role="hg-cmd">hg mv</command> est un alias pour <command
|
|
youshe@988
|
491 role="hg-cmd">hg rename</command>.)</para>
|
|
youshe@988
|
492
|
|
youshe@988
|
493 &interaction.rename.divergent.rename.bob;
|
|
youshe@988
|
494
|
|
youshe@988
|
495 <para id="x_1dd">J'aime à penser qu'il s'agit d'un conflit puisque
|
|
youshe@988
|
496 chaque développeur a exprimé différentes intentions au sujet de ce
|
|
youshe@988
|
497 que le nom de ce fichier aurait du être.</para>
|
|
youshe@988
|
498
|
|
youshe@988
|
499 <para id="x_1de">Que pensez vous qu'il devrait se produire lorsqu'ils
|
|
youshe@988
|
500 fusionnent (merge) leurs travaux ? Le comportement actuel de
|
|
youshe@988
|
501 Mercurial est qu'il préserve toujours les <emphasis>deux</emphasis>
|
|
youshe@988
|
502 noms lorsqu'il fusionne (merge) des changesets qui contiennent des
|
|
youshe@988
|
503 renommages divergeants.</para>
|
|
bos@567
|
504
|
|
bos@567
|
505 &interaction.rename.divergent.merge;
|
|
bos@559
|
506
|
|
youshe@988
|
507 <para id="x_1df">Remarquez que bien que Mercurial vous avertisse au
|
|
youshe@988
|
508 sujet de la divergeance des renommages, il vous laisse faire quelque
|
|
youshe@988
|
509 chose au sujet de la divergeance après la fusion (merge).</para>
|
|
youshe@988
|
510 </sect2>
|
|
youshe@988
|
511
|
|
youshe@988
|
512 <sect2>
|
|
youshe@988
|
513 <title>Renommages et fusion convergeants</title>
|
|
youshe@988
|
514
|
|
youshe@988
|
515 <para id="x_1e0">Un autre type de conflit de renommage intervient
|
|
youshe@988
|
516 lorsque deux personne choisissent de renommer différents fichiers
|
|
youshe@988
|
517 <emphasis>source</emphasis> vers la même
|
|
youshe@988
|
518 <emphasis>destination</emphasis>. Dans ce cas, Mercurial exécute la
|
|
youshe@988
|
519 machinerie normale de fusion (merge) et vous guide vers une
|
|
youshe@988
|
520 solution convenable.</para>
|
|
youshe@988
|
521 </sect2>
|
|
youshe@988
|
522
|
|
youshe@988
|
523 <sect2>
|
|
youshe@988
|
524 <title>Autres cas anguleux relatifs aux noms</title>
|
|
youshe@988
|
525
|
|
youshe@988
|
526 <para id="x_1e1">Mercurial possède un bug de longue date dans lequel il
|
|
youshe@988
|
527 échoue à traiter une fusion (merge) où un coté a un fichier avec un
|
|
youshe@990
|
528 nom donné, alors que l'autre coté possède un répertoire avec le même nom.
|
|
youshe@988
|
529 Ceci est documenté dans l'<ulink role="hg-bug"
|
|
youshe@988
|
530 url="http://www.selenic.com/mercurial/bts/issue29">issue
|
|
youshe@988
|
531 29</ulink>.</para>
|
|
bos@567
|
532
|
|
bos@567
|
533 &interaction.issue29.go;
|
|
bos@559
|
534
|
|
bos@559
|
535 </sect2>
|
|
bos@559
|
536 </sect1>
|
|
bos@674
|
537
|
|
bos@559
|
538 <sect1>
|
|
youshe@988
|
539 <title>Récupération d'erreurs</title>
|
|
youshe@988
|
540
|
|
youshe@988
|
541 <para id="x_1e2">Mercurial possède certaines commandes utiles qui vont
|
|
youshe@990
|
542 vous aider à récupérer de certaines erreurs communes.</para>
|
|
youshe@988
|
543
|
|
youshe@988
|
544 <para id="x_1e3">La commande <command role="hg-cmd">hg revert</command>
|
|
youshe@990
|
545 vous permet d'annuler les changements que vous avez faits dans votre
|
|
youshe@988
|
546 répertoire de travail. Par exemple, si vous faites un <command
|
|
youshe@988
|
547 role="hg-cmd">hg add</command> sur un fichier par accident, exécutez
|
|
youshe@988
|
548 juste <command role="hg-cmd">hg revert</command> avec le nom du fichier
|
|
youshe@990
|
549 que vous avez ajouté et tandis que le fichier ne sera touché d'une
|
|
youshe@988
|
550 quelconque manière, il ne sera plus suivi comme ajouté par Mercurial.
|
|
youshe@988
|
551 Vous pouvez aussi utiliser la commande <command role="hg-cmd">hg
|
|
youshe@990
|
552 revert</command> pour vous débarrasser de modifications erronés
|
|
youshe@988
|
553 apportées à un fichier.</para>
|
|
youshe@988
|
554
|
|
youshe@988
|
555 <para id="x_1e4">Il est utile de se souvenir que la commande <command
|
|
youshe@988
|
556 role="hg-cmd">hg revert</command> est utile pour les modifications
|
|
youshe@990
|
557 qui n'ont pas encore été committées. Une fois que vous avez committé un
|
|
youshe@988
|
558 changement, si vous décidez qu'il s'agissait d'une erreur, vous pouvez
|
|
youshe@990
|
559 toujours faire quelque chose à ce sujet, bien que vos options soient
|
|
youshe@988
|
560 un peu plus limitées.</para>
|
|
youshe@988
|
561
|
|
youshe@988
|
562 <para id="x_1e5">Pour plus d'informations au sujet de la commande
|
|
youshe@988
|
563 <command role="hg-cmd">hg revert</command>, et des détails sur comment
|
|
youshe@988
|
564 traiter les modifications que vous avez déjà committées, référez vous à
|
|
youshe@988
|
565 <xref linkend="chap:undo"/>.</para>
|
|
bos@674
|
566 </sect1>
|
|
bos@674
|
567
|
|
bos@674
|
568 <sect1>
|
|
youshe@988
|
569 <title>Traiter avec les fusions (merge) malicieuses</title>
|
|
youshe@988
|
570
|
|
youshe@988
|
571 <para id="x_687">Dans des projets compliqués ou conséquents, il n'est pas
|
|
youshe@988
|
572 rare qu'une fusion (merge) de deux changesets finisse par une migraine.
|
|
youshe@990
|
573 Supposez qu'il y ait un gros fichier source qui ait été largement édité de
|
|
youshe@988
|
574 chaque coté de la fusion (merge) : ceci va inévitablement résulter en
|
|
youshe@990
|
575 conflits, dont certains peuvent prendre plusieurs essais pour s'en
|
|
youshe@988
|
576 sortir.</para>
|
|
youshe@988
|
577
|
|
youshe@990
|
578 <para id="x_688">Développons en un cas simple pour voir comment le gérer.
|
|
youshe@990
|
579 Nous allons commencer avec un dépôt contenant un fichier, et le
|
|
youshe@988
|
580 cloner deux fois.</para>
|
|
bos@674
|
581
|
|
bos@674
|
582 &interaction.ch04-resolve.init;
|
|
bos@674
|
583
|
|
youshe@988
|
584 <para id="x_689">Dans un des clones, nous allons modifier le fichier
|
|
youshe@988
|
585 d'une façon.</para>
|
|
bos@674
|
586
|
|
bos@674
|
587 &interaction.ch04-resolve.left;
|
|
bos@674
|
588
|
|
youshe@988
|
589 <para id="x_68a">Dans un autre, nous allons modifier le fichier
|
|
youshe@990
|
590 différemment.</para>
|
|
bos@674
|
591
|
|
bos@674
|
592 &interaction.ch04-resolve.right;
|
|
bos@674
|
593
|
|
youshe@988
|
594 <para id="x_68b">Ensuite, nous allons récupérer (pull) chaque ensemble de
|
|
youshe@988
|
595 changement dans notre dépôt original.</para>
|
|
bos@674
|
596
|
|
bos@674
|
597 &interaction.ch04-resolve.pull;
|
|
bos@674
|
598
|
|
youshe@988
|
599 <para id="x_68c">Nous nous attendons à ce que notre dépôt contienne deux
|
|
youshe@990
|
600 "heads".</para>
|
|
bos@674
|
601
|
|
bos@674
|
602 &interaction.ch04-resolve.heads;
|
|
bos@674
|
603
|
|
youshe@988
|
604 <para id="x_68d">Normalement, si nous lançons <command role="hg-cmd">hg
|
|
youshe@988
|
605 merge</command> à ce point, il nous renverra vers une interface
|
|
youshe@988
|
606 utilisateur qui nous permettra de résoudre manuellement les éditions
|
|
youshe@988
|
607 conflictuelles sur le fichier <filename>myfile.txt</filename>.
|
|
youshe@990
|
608 Cependant, pour simplifier ici les choses dans la présentation, nous
|
|
youshe@990
|
609 aimerions plutôt que la fusion (merge) échoue immédiatement. Voici une
|
|
youshe@988
|
610 façon de le faire.</para>
|
|
bos@674
|
611
|
|
bos@674
|
612 &interaction.ch04-resolve.export;
|
|
bos@674
|
613
|
|
youshe@990
|
614 <para id="x_68e">Nous avons dit au processus de fusion de Mercurial
|
|
youshe@988
|
615 d'exécuter la commande <command>false</command> (qui échoue
|
|
youshe@988
|
616 immédiatement, à la demande) s'il détecte une fusion (merge) qu'il ne
|
|
youshe@988
|
617 peut pas arranger automatiquement.</para>
|
|
youshe@988
|
618
|
|
youshe@988
|
619 <para id="x_68f">Si nous appelons maintenant <command role="hg-cmd">hg
|
|
youshe@990
|
620 merge</command>, il devrait échouer et reporter une erreur.</para>
|
|
bos@674
|
621
|
|
bos@674
|
622 &interaction.ch04-resolve.merge;
|
|
bos@674
|
623
|
|
youshe@988
|
624 <para id="x_690">Même si nous ne remarquons pas qu'une fusion (merge) a
|
|
youshe@990
|
625 échoué, Mercurial nous empêchera de committer le résultat d'une fusion
|
|
youshe@988
|
626 ratée.</para>
|
|
bos@674
|
627
|
|
bos@674
|
628 &interaction.ch04-resolve.cifail;
|
|
bos@674
|
629
|
|
youshe@988
|
630 <para id="x_691">Lorsque <command role="hg-cmd">hg commit</command>
|
|
youshe@988
|
631 échoue dans ce cas, il suggère que nous utilisons la commande peu
|
|
youshe@988
|
632 connue <command role="hg-cmd">hg resolve</command>. Comme d'habitude,
|
|
youshe@988
|
633 <command role="hg-cmd">hg help resolve</command> affichera une aide
|
|
youshe@988
|
634 sommaire.</para>
|
|
bos@674
|
635
|
|
bos@674
|
636 <sect2>
|
|
youshe@990
|
637 <title>États de résolution des fichiers</title>
|
|
youshe@989
|
638 <!-- TODO Vérifier traduction : File resolution states -->
|
|
youshe@989
|
639
|
|
youshe@990
|
640 <para id="x_692">Lorsqu'une fusion intervient, la plupart des fichiers
|
|
youshe@989
|
641 vont, la plupart du temps, rester sans modification. Pour chaque
|
|
youshe@989
|
642 fichier sur lequel Mercurial doit faire quelque chose, il suit l'état
|
|
youshe@989
|
643 de celui-ci.</para>
|
|
bos@674
|
644
|
|
bos@674
|
645 <itemizedlist>
|
|
youshe@989
|
646 <listitem><para id="x_693">Un fichier
|
|
youshe@989
|
647 <quote><emphasis>resolved</emphasis></quote> a été fusionné
|
|
youshe@989
|
648 (merge) avec succès, que ce soit automatiquement par Mercurial ou
|
|
youshe@989
|
649 manuellement par une intervention humaine.</para></listitem>
|
|
youshe@989
|
650 <listitem><para id="x_694">Un fichier
|
|
youshe@989
|
651 <quote><emphasis>unresolved</emphasis></quote> n'a pas été
|
|
youshe@989
|
652 fusionné (merge) correctement et a besoin de plus
|
|
youshe@989
|
653 d'attention.</para>
|
|
youshe@989
|
654 </listitem>
|
|
bos@674
|
655 </itemizedlist>
|
|
bos@674
|
656
|
|
youshe@990
|
657 <para id="x_695">Si Mercurial voit un fichier
|
|
youshe@990
|
658 <emphasis>quelconque</emphasis> dans un état
|
|
youshe@990
|
659 <quote>unresolved</quote> après une fusion (merge), il considère que
|
|
youshe@990
|
660 la fusion (merge) a échoué. Heureusement, nous n'avons pas à
|
|
youshe@990
|
661 recommencer la procédure à partir du début.</para>
|
|
youshe@989
|
662
|
|
youshe@989
|
663 <para id="x_696">L'option <option role="hg-opt-resolve">--list</option>
|
|
youshe@989
|
664 ou <option role="hg-opt-resolve">-l</option> passée à <command
|
|
youshe@989
|
665 role="hg-cmd">hg resolve</command> liste l'état de chaque fichier
|
|
youshe@989
|
666 fusionné (merge).</para>
|
|
bos@674
|
667
|
|
bos@674
|
668 &interaction.ch04-resolve.list;
|
|
bos@674
|
669
|
|
youshe@989
|
670 <para id="x_697">En sortie de <command role="hg-cmd">hg
|
|
youshe@989
|
671 resolve</command>, un fichier "resolved" est marqué avec un
|
|
youshe@989
|
672 <literal>R</literal>, alors qu'un fichier "unresolved" est marqué
|
|
youshe@989
|
673 d'un <literal>U</literal>. S'il existe un fichier listé avec un
|
|
youshe@989
|
674 <literal>U</literal>, nous savons qu'essayer de committer le résultat
|
|
youshe@990
|
675 de la fusion (merge) échouera.</para>
|
|
youshe@989
|
676 </sect2>
|
|
youshe@989
|
677
|
|
youshe@989
|
678 <sect2>
|
|
youshe@989
|
679 <title>Résoudre une fusion de fichier</title>
|
|
youshe@989
|
680
|
|
youshe@989
|
681 <para id="x_698">Nous avons plusieurs options pour changer l'état d'un
|
|
youshe@989
|
682 fichier de "unresolved" à "resolved". Le plus commun est de relancer
|
|
youshe@989
|
683 <command role="hg-cmd">hg resolve</command>. Si nous passons les noms
|
|
youshe@989
|
684 des fichiers individuels ou des répertoires, ceci retentera la fusion
|
|
youshe@989
|
685 de tous les fichiers présents à cet endroit. Nous pouvons aussi
|
|
youshe@989
|
686 passer l'option <option role="hg-opt-resolve">--all</option> ou
|
|
youshe@989
|
687 <option role="hg-opt-resolve">-a</option> qui tentera de fusionner
|
|
youshe@989
|
688 <emphasis>tous</emphasis> les fichiers "unresolved".</para>
|
|
youshe@989
|
689
|
|
youshe@989
|
690 <para id="x_699">Mercurial nous laisse aussi modifier la résolution
|
|
youshe@989
|
691 d'un fichier directement. Nous pouvons marquer un fichier "resolved"
|
|
youshe@989
|
692 en utilisant l'option <option role="hg-opt-resolve">--mark</option>,
|
|
youshe@989
|
693 ou "unresolved" en utilisant l'option <option
|
|
youshe@989
|
694 role="hg-opt-resolve">--unmark</option>. Ceci nous autorise à
|
|
youshe@990
|
695 nettoyer une fusion particulièrement compliquée à la main, et de
|
|
youshe@989
|
696 garder un suivi de nos progrès avec chaque fichier pendant que nous
|
|
youshe@989
|
697 procédons.</para>
|
|
bos@674
|
698 </sect2>
|
|
bos@559
|
699 </sect1>
|
|
bos@683
|
700
|
|
bos@683
|
701 <sect1>
|
|
youshe@990
|
702 <title>Des "diffs" plus utiles</title>
|
|
youshe@989
|
703
|
|
youshe@989
|
704 <para id="x_6c7">La sortie par défaut de la commande <command
|
|
youshe@990
|
705 role="hg-cmd">hg diff</command> est compatible rétrospectivement avec
|
|
youshe@990
|
706 la commande régulière <command>diff</command>, mais ceci a quelques
|
|
youshe@990
|
707 inconvénients.</para>
|
|
youshe@989
|
708
|
|
youshe@989
|
709 <para id="x_6c8">Considérez le cas où nous utilisons <command role="hg-cmd">hg
|
|
youshe@989
|
710 rename</command> pour renommer un fichier.</para>
|
|
bos@683
|
711
|
|
bos@683
|
712 &interaction.ch04-diff.rename.basic;
|
|
bos@683
|
713
|
|
youshe@990
|
714 <para id="x_6c9">La sortie de <command role="hg-cmd">hg diff</command>
|
|
youshe@990
|
715 ci-dessus cache le fait que nous avons simplement renommé un fichier.
|
|
youshe@990
|
716 La commande <command role="hg-cmd">hg diff</command> accepte l'option
|
|
youshe@989
|
717 <option>--git</option> ou <option>-g</option> pour utiliser un nouveau
|
|
youshe@989
|
718 format de diff qui montre ces informations sous une forme plus
|
|
youshe@989
|
719 expressive.</para>
|
|
bos@683
|
720
|
|
bos@683
|
721 &interaction.ch04-diff.rename.git;
|
|
bos@683
|
722
|
|
youshe@989
|
723 <para id="x_6ca">Cette option peut aussi aider avec le cas autrement
|
|
youshe@989
|
724 confus : un fichier qui apparaît comme étant modifié en accord avec
|
|
youshe@989
|
725 <command role="hg-cmd">hg status</command>, mais où <command
|
|
youshe@989
|
726 role="hg-cmd">hg diff</command> n'affiche rien. Cette situation peut
|
|
youshe@989
|
727 survenir si nous changeons les permissions d'exécution du
|
|
youshe@989
|
728 fichier.</para>
|
|
bos@683
|
729
|
|
bos@683
|
730 &interaction.ch04-diff.chmod;
|
|
bos@683
|
731
|
|
youshe@989
|
732 <para id="x_6cb">La commande normale <command>diff</command> ne fait pas
|
|
youshe@989
|
733 attention aux permissions des fichiers, ce qui explique pourquoi
|
|
youshe@989
|
734 <command role="hg-cmd">hg diff</command> n'affiche rien du tout par
|
|
youshe@989
|
735 défaut. Si nous lui passons l'option <option>-g</option>, ceci nous
|
|
youshe@989
|
736 informe de ce qu'il s'est vraiment passé.</para>
|
|
bos@683
|
737
|
|
bos@683
|
738 &interaction.ch04-diff.chmod.git;
|
|
bos@683
|
739 </sect1>
|
|
bos@683
|
740
|
|
bos@683
|
741 <sect1>
|
|
youshe@990
|
742 <title>Quels fichiers suivre et lesquels éviter</title>
|
|
youshe@989
|
743
|
|
youshe@989
|
744 <para id="x_6cc">Les systèmes de gestion de révisions sont en général
|
|
youshe@989
|
745 meilleurs pour gérer les fichiers textes qui sont écrits par les
|
|
youshe@989
|
746 humains, comme le code source, où les fichiers ne changent pas
|
|
youshe@989
|
747 énormément d'une révision à l'autre. Certains systèmes de gestion de
|
|
youshe@990
|
748 révisions centralisés peuvent aussi traiter très convenablement les
|
|
youshe@990
|
749 fichiers binaires, tels que les images bitmap.</para>
|
|
youshe@989
|
750
|
|
youshe@989
|
751 <para id="x_6cd">Par exemple, une équipe de développement de jeux va
|
|
youshe@990
|
752 probablement gérer les deux types : ses codes source et tous ses binaires
|
|
youshe@989
|
753 (ex. données géométriques, textures, schémas de cartes) dans un système
|
|
youshe@989
|
754 de contrôle de révisions.</para>
|
|
youshe@989
|
755 <!-- Vérifier la traduction de map layouts que j'ai traduit par schémas
|
|
youshe@989
|
756 de cartes -->
|
|
youshe@989
|
757
|
|
youshe@989
|
758 <para id="x_6ce">Puisqu'il est d'habitude impossible de fusionner (merge)
|
|
youshe@989
|
759 deux modifications conflictuelles sur un fichier binaire, les systèmes
|
|
youshe@990
|
760 de version centralisés offrent souvent un mécanisme de verrou (lock) qui
|
|
youshe@989
|
761 permet à un utilisateur de dire <quote>Je suis la seule personne qui
|
|
youshe@989
|
762 peut éditer ce fichier</quote>.</para>
|
|
youshe@989
|
763
|
|
youshe@990
|
764 <para id="x_6cf">En comparaison avec un système centralisé, un système
|
|
youshe@989
|
765 décentralisé de gestion de révision change certains facteurs qui
|
|
youshe@989
|
766 guident les décisions sur quels fichiers gérer et comment.</para>
|
|
youshe@989
|
767
|
|
youshe@990
|
768 <para id="x_6d0">Par exemple, un système distribué de gestion de révisions
|
|
youshe@990
|
769 ne peut pas, par sa nature, offrir un système de véroux (lock) sur les
|
|
youshe@990
|
770 fichiers. Il n'y a donc pas de mécanisme inclus pour empêcher deux
|
|
youshe@989
|
771 personnes de faire des modifications conflictuelles sur un fichier
|
|
youshe@989
|
772 binaire. Si vous avez une équipe où plusieurs personnes peuvent souvent
|
|
youshe@989
|
773 éditer un fichier binaire, cela ne serait pas une très bonne idée
|
|
youshe@990
|
774 d'utiliser Mercurial &emdash;ou tout autre système distribué de gestion
|
|
youshe@989
|
775 de révisions&emdash;pour gérer ces fichiers.</para>
|
|
youshe@989
|
776
|
|
youshe@989
|
777 <para id="x_6d1">Lorsque vous sauvegardez les modifications sur un
|
|
youshe@989
|
778 fichier, Mercurial ne sauvegarde d'habitude que les différences entre
|
|
youshe@989
|
779 la version précédente et la version actuelle d'un fichier. Pour la
|
|
youshe@989
|
780 plupart des fichiers texte, ceci est très efficace. Cependant, certains
|
|
youshe@989
|
781 fichiers (en particulier les fichiers binaires) sont construits d'une
|
|
youshe@989
|
782 façon que même un petit changement sur un contenu logique résulte sur
|
|
youshe@989
|
783 un changement de la plupart des octets du fichier. Par exemple, les
|
|
youshe@990
|
784 fichiers compressés sont particulièrement sujets à ce comportement. Si
|
|
youshe@990
|
785 les différences entre deux versions successives d'un fichier sont
|
|
youshe@990
|
786 toujours très grandes, Mercurial ne sera pas capable de sauvegarder
|
|
youshe@990
|
787 l'historique des révisions sur le fichier très efficacement. Ceci peut
|
|
youshe@990
|
788 affecter aussi bien les besoins pour la sauvegarde locale que le temps
|
|
youshe@990
|
789 nécessaire à cloner le dépôt.</para>
|
|
youshe@989
|
790
|
|
youshe@989
|
791 <para id="x_6d2">Pour avoir une idée de comment ceci pourrait vous
|
|
youshe@989
|
792 affecter en pratique, supposez que nous voulions que Mercurial gère des
|
|
youshe@989
|
793 documents OpenOffice. OpenOffice sauvegarde les documents sur le disque
|
|
youshe@989
|
794 comme des fichiers compressés zip. Même le fait d'éditer ces fichiers
|
|
youshe@989
|
795 d'une seule lettre, changera les bits de la quasi totalité du fichier
|
|
youshe@989
|
796 lorsque vous le sauvegarderez. Maintenant, supposez que ce fichier
|
|
youshe@989
|
797 fasse une taille de 2Mo. Puisque la plupart du fichier change à chaque
|
|
youshe@989
|
798 fois que vous sauvegardez, Mercurial aura à sauvegarder tous les 2Mo du
|
|
youshe@989
|
799 fichier à chaque commit, alors que de votre point de vue, il n'y a
|
|
youshe@990
|
800 que peu de mots qui changent à chaque fois. Un seul fichier
|
|
youshe@990
|
801 souvent édité qui n'est pas bien traité par les hypothèses que Mercurial
|
|
youshe@989
|
802 fait sur les sauvegardes peut facilement avoir un effet colossal sur la
|
|
youshe@989
|
803 taille du dépôt.</para>
|
|
youshe@989
|
804
|
|
youshe@989
|
805 <para id="x_6d3">Même pire, si vous et quelqu'un d'autre éditez le même
|
|
youshe@989
|
806 document OpenOffice sur lequel vous travaillez, il n'y a pas de façon
|
|
youshe@989
|
807 utile pour fusionner votre travail. En fait, il n'y a pas de moyen
|
|
youshe@989
|
808 utile de montrer que les différences sont faites à partir de votre
|
|
youshe@989
|
809 vision des modifications.</para>
|
|
youshe@989
|
810
|
|
youshe@990
|
811 <para id="x_6d4">Il y a ainsi quelques recommandations claires sur les
|
|
youshe@989
|
812 types de fichiers spécifiques avec lesquels faire très
|
|
youshe@989
|
813 attention.</para>
|
|
bos@683
|
814
|
|
bos@683
|
815 <itemizedlist>
|
|
youshe@989
|
816 <listitem><para id="x_6d5">Les fichier qui sont très gros et
|
|
youshe@990
|
817 incompressibles, comme les images ISO de CD-ROM, sont, par
|
|
youshe@989
|
818 construction très gros et les cloner à travers un réseau sera très
|
|
youshe@989
|
819 long.</para></listitem>
|
|
youshe@990
|
820 <!-- TODO : Trouver une meilleure traduction pour : ISO CD-ROM images, will by
|
|
youshe@989
|
821 virtue of sheer size make clones over a network very slow. -->
|
|
youshe@989
|
822 <listitem><para id="x_6d6">Les fichiers qui changent beaucoup d'une
|
|
youshe@989
|
823 révision à l'autre peuvent être très chers à sauvegarder si vous
|
|
youshe@990
|
824 les éditez fréquemment, de même que les conflits entre deux éditions
|
|
youshe@989
|
825 concurrentes peuvent être difficiles à résoudre.</para>
|
|
bos@683
|
826 </listitem>
|
|
bos@683
|
827 </itemizedlist>
|
|
bos@683
|
828 </sect1>
|
|
bos@683
|
829
|
|
bos@683
|
830 <sect1>
|
|
youshe@989
|
831 <title>Sauvegardes et miroirs</title>
|
|
youshe@989
|
832
|
|
youshe@989
|
833 <para id="x_6d7">Puisque Mercurial maintient une copie complète de
|
|
youshe@989
|
834 l'historique de chaque clone, toute personne qui utilise Mercurial pour
|
|
youshe@989
|
835 collaborer à un projet peut potentiellement agir comme une source de
|
|
youshe@990
|
836 sauvegarde si une catastrophe survenait. Si un dépôt central devient
|
|
youshe@989
|
837 indisponible, vous pouvez construire un remplaçant en clonant une copie
|
|
youshe@989
|
838 du dépôt à partir d'un des contributeurs en récupérant (pull) tous les
|
|
youshe@989
|
839 changements qui n'auraient pas été vus par les autres.</para>
|
|
youshe@989
|
840
|
|
youshe@989
|
841 <para id="x_6d8">Il est simple d'utiliser Mercurial pour construire des
|
|
youshe@989
|
842 serveurs hors site de sauvegarde et des miroirs distants. Initiez une
|
|
youshe@989
|
843 tâche périodique (ex. via la commande <command>cron</command>) sur un
|
|
youshe@989
|
844 serveur distant pour récupérer (pull) les changements de votre dépôt
|
|
youshe@990
|
845 distant chaque heure. Ceci sera difficile seulement dans le cas
|
|
youshe@989
|
846 improbable où le nombre des dépôts maîtres que vous maintenez change
|
|
youshe@989
|
847 souvent, auquel cas vous aurez besoin de faire un peu de scripting pour
|
|
youshe@990
|
848 rafraichir la liste des dépôt à sauvegarder.</para>
|
|
youshe@989
|
849
|
|
youshe@989
|
850 <para id="x_6d9">Si vous exécutez des sauvegardes traditionnelles de
|
|
youshe@990
|
851 votre dépôt maître sur bande ou disque, et que vous voulez sauvegarder
|
|
youshe@990
|
852 un dépôt nommé <filename>myrepo</filename>, utilisez la commande
|
|
youshe@990
|
853 <command>hg clone -U myrepo myrepo.bak</command> pour créer un clone de
|
|
youshe@990
|
854 <filename>myrepo</filename> avant de commencer vos backups.
|
|
youshe@989
|
855 L'option <option>-U</option> ne crée pas de répertoire de travail après
|
|
youshe@989
|
856 que le clone soit accompli, puisque ceci serait superflu et ferait que
|
|
youshe@989
|
857 la sauvegarde prenne plus de temps.</para>
|
|
youshe@989
|
858
|
|
youshe@989
|
859 <para id="x_6da">Si vous voulez ensuite sauvegarder
|
|
youshe@989
|
860 <filename>myrepo.bak</filename> au lieu de <filename>myrepo</filename>,
|
|
youshe@990
|
861 vous aurez la garantie d'avoir une image (snapshot) consistante de
|
|
youshe@990
|
862 votre dépôt sur lequel un développeur insomniaque n'enverra (push) pas de
|
|
youshe@989
|
863 changements en milieu de sauvegarde.</para>
|
|
bos@683
|
864 </sect1>
|
|
bos@559
|
865 </chapter>
|
|
bos@559
|
866
|
|
bos@559
|
867 <!--
|
|
bos@559
|
868 local variables:
|
|
bos@559
|
869 sgml-parent-document: ("00book.xml" "book" "chapter")
|
|
bos@559
|
870 end:
|
|
bos@559
|
871 -->
|
