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