hgbook
changeset 989:a3a9eabfe2a4
French translation : ch05-daily translated
author | Frédéric Bouquet <youshe.jaalon@gmail.com> |
---|---|
date | Thu Sep 10 13:06:34 2009 +0200 (2009-09-10) |
parents | 72de97557f11 |
children | b4ff7b04efdc |
files | fr/ch05-daily.xml |
line diff
1.1 --- a/fr/ch05-daily.xml Thu Sep 10 01:08:16 2009 +0200 1.2 +++ b/fr/ch05-daily.xml Thu Sep 10 13:06:34 2009 +0200 1.3 @@ -634,221 +634,231 @@ 1.4 sommaire.</para> 1.5 1.6 <sect2> 1.7 - <title>File resolution states</title> 1.8 - 1.9 - <para id="x_692">When a merge occurs, most files will usually remain 1.10 - unmodified. For each file where Mercurial has to do 1.11 - something, it tracks the state of the file.</para> 1.12 + <title>Etats de résolution des fichiers</title> 1.13 + <!-- TODO Vérifier traduction : File resolution states --> 1.14 + 1.15 + <para id="x_692">Lorsqu'une fusion intervient, la plupart des fichier 1.16 + vont, la plupart du temps, rester sans modification. Pour chaque 1.17 + fichier sur lequel Mercurial doit faire quelque chose, il suit l'état 1.18 + de celui-ci.</para> 1.19 1.20 <itemizedlist> 1.21 - <listitem> 1.22 - <para id="x_693">A <emphasis>resolved</emphasis> file has been 1.23 - successfully merged, either automatically by Mercurial or 1.24 - manually with human intervention.</para> 1.25 - </listitem> 1.26 - <listitem> 1.27 - <para id="x_694">An <emphasis>unresolved</emphasis> file was not merged 1.28 - successfully, and needs more attention.</para> 1.29 - </listitem> 1.30 + <listitem><para id="x_693">Un fichier 1.31 + <quote><emphasis>resolved</emphasis></quote> a été fusionné 1.32 + (merge) avec succès, que ce soit automatiquement par Mercurial ou 1.33 + manuellement par une intervention humaine.</para></listitem> 1.34 + <listitem><para id="x_694">Un fichier 1.35 + <quote><emphasis>unresolved</emphasis></quote> n'a pas été 1.36 + fusionné (merge) correctement et a besoin de plus 1.37 + d'attention.</para> 1.38 + </listitem> 1.39 </itemizedlist> 1.40 1.41 - <para id="x_695">If Mercurial sees <emphasis>any</emphasis> file in the 1.42 - unresolved state after a merge, it considers the merge to have 1.43 - failed. Fortunately, we do not need to restart the entire 1.44 - merge from scratch.</para> 1.45 - 1.46 - <para id="x_696">The <option role="hg-opt-resolve">--list</option> or 1.47 - <option role="hg-opt-resolve">-l</option> option to <command 1.48 - role="hg-cmd">hg resolve</command> prints out the state of 1.49 - each merged file.</para> 1.50 + <para id="x_695">Si Mercurial voit <emphasis>n'importe quel</emphasis> 1.51 + fichier dans un état <quote>unresolved</quote> après une fusion 1.52 + (merge), il considère que la fusion (merge) a échoué. Heureusement, 1.53 + nous n'avons pas à recommencer la fusion (merge) à partir du 1.54 + début.</para> 1.55 + 1.56 + <para id="x_696">L'option <option role="hg-opt-resolve">--list</option> 1.57 + ou <option role="hg-opt-resolve">-l</option> passée à <command 1.58 + role="hg-cmd">hg resolve</command> liste l'état de chaque fichier 1.59 + fusionné (merge).</para> 1.60 1.61 &interaction.ch04-resolve.list; 1.62 1.63 - <para id="x_697">In the output from <command role="hg-cmd">hg 1.64 - resolve</command>, a resolved file is marked with 1.65 - <literal>R</literal>, while an unresolved file is marked with 1.66 - <literal>U</literal>. If any files are listed with 1.67 - <literal>U</literal>, we know that an attempt to commit the 1.68 - results of the merge will fail.</para> 1.69 - </sect2> 1.70 - 1.71 - <sect2> 1.72 - <title>Resolving a file merge</title> 1.73 - 1.74 - <para id="x_698">We have several options to move a file from the unresolved 1.75 - into the resolved state. By far the most common is to rerun 1.76 - <command role="hg-cmd">hg resolve</command>. If we pass the 1.77 - names of individual files or directories, it will retry the 1.78 - merges of any unresolved files present in those locations. We 1.79 - can also pass the <option role="hg-opt-resolve">--all</option> 1.80 - or <option role="hg-opt-resolve">-a</option> option, which 1.81 - will retry the merges of <emphasis>all</emphasis> unresolved 1.82 - files.</para> 1.83 - 1.84 - <para id="x_699">Mercurial also lets us modify the resolution state of a 1.85 - file directly. We can manually mark a file as resolved using 1.86 - the <option role="hg-opt-resolve">--mark</option> option, or 1.87 - as unresolved using the <option 1.88 - role="hg-opt-resolve">--unmark</option> option. This allows 1.89 - us to clean up a particularly messy merge by hand, and to keep 1.90 - track of our progress with each file as we go.</para> 1.91 + <para id="x_697">En sortie de <command role="hg-cmd">hg 1.92 + resolve</command>, un fichier "resolved" est marqué avec un 1.93 + <literal>R</literal>, alors qu'un fichier "unresolved" est marqué 1.94 + d'un <literal>U</literal>. S'il existe un fichier listé avec un 1.95 + <literal>U</literal>, nous savons qu'essayer de committer le résultat 1.96 + de la fusion (merge) échoura.</para> 1.97 + </sect2> 1.98 + 1.99 + <sect2> 1.100 + <title>Résoudre une fusion de fichier</title> 1.101 + 1.102 + <para id="x_698">Nous avons plusieurs options pour changer l'état d'un 1.103 + fichier de "unresolved" à "resolved". Le plus commun est de relancer 1.104 + <command role="hg-cmd">hg resolve</command>. Si nous passons les noms 1.105 + des fichiers individuels ou des répertoires, ceci retentera la fusion 1.106 + de tous les fichiers présents à cet endroit. Nous pouvons aussi 1.107 + passer l'option <option role="hg-opt-resolve">--all</option> ou 1.108 + <option role="hg-opt-resolve">-a</option> qui tentera de fusionner 1.109 + <emphasis>tous</emphasis> les fichiers "unresolved".</para> 1.110 + 1.111 + <para id="x_699">Mercurial nous laisse aussi modifier la résolution 1.112 + d'un fichier directement. Nous pouvons marquer un fichier "resolved" 1.113 + en utilisant l'option <option role="hg-opt-resolve">--mark</option>, 1.114 + ou "unresolved" en utilisant l'option <option 1.115 + role="hg-opt-resolve">--unmark</option>. Ceci nous autorise à 1.116 + nettoyer une fusion particulièrement compliqué à la main, et de 1.117 + garder un suivi de nos progrès avec chaque fichier pendant que nous 1.118 + procédons.</para> 1.119 </sect2> 1.120 </sect1> 1.121 1.122 <sect1> 1.123 - <title>More useful diffs</title> 1.124 - 1.125 - <para id="x_6c7">The default output of the <command role="hg-cmd">hg 1.126 - diff</command> command is backwards compatible with the 1.127 - regular <command>diff</command> command, but this has some 1.128 - drawbacks.</para> 1.129 - 1.130 - <para id="x_6c8">Consider the case where we use <command role="hg-cmd">hg 1.131 - rename</command> to rename a file.</para> 1.132 + <title>Des diffs plus utiles</title> 1.133 + 1.134 + <para id="x_6c7">La sortie par défaut de la commande <command 1.135 + role="hg-cmd">hg diff</command> est compatible rétrospectivement avec la commande régulière <command>diff</command>, mais ceci a quelques inconvénients.</para> 1.136 + 1.137 + <para id="x_6c8">Considérez le cas où nous utilisons <command role="hg-cmd">hg 1.138 + rename</command> pour renommer un fichier.</para> 1.139 1.140 &interaction.ch04-diff.rename.basic; 1.141 1.142 - <para id="x_6c9">The output of <command role="hg-cmd">hg diff</command> above 1.143 - obscures the fact that we simply renamed a file. The <command 1.144 - role="hg-cmd">hg diff</command> command accepts an option, 1.145 - <option>--git</option> or <option>-g</option>, to use a newer 1.146 - diff format that displays such information in a more readable 1.147 - form.</para> 1.148 + <para id="x_6c9">La sortie de <command role="hg-cmd">hg diff</command> ci 1.149 + dessus cache le fait que nous avons simplement renommé un fichier. La 1.150 + commande <command role="hg-cmd">hg diff</command> accepte l'option 1.151 + <option>--git</option> ou <option>-g</option> pour utiliser un nouveau 1.152 + format de diff qui montre ces informations sous une forme plus 1.153 + expressive.</para> 1.154 1.155 &interaction.ch04-diff.rename.git; 1.156 1.157 - <para id="x_6ca">This option also helps with a case that can otherwise be 1.158 - confusing: a file that appears to be modified according to 1.159 - <command role="hg-cmd">hg status</command>, but for which 1.160 - <command role="hg-cmd">hg diff</command> prints nothing. This 1.161 - situation can arise if we change the file's execute 1.162 - permissions.</para> 1.163 + <para id="x_6ca">Cette option peut aussi aider avec le cas autrement 1.164 + confus : un fichier qui apparaît comme étant modifié en accord avec 1.165 + <command role="hg-cmd">hg status</command>, mais où <command 1.166 + role="hg-cmd">hg diff</command> n'affiche rien. Cette situation peut 1.167 + survenir si nous changeons les permissions d'exécution du 1.168 + fichier.</para> 1.169 1.170 &interaction.ch04-diff.chmod; 1.171 1.172 - <para id="x_6cb">The normal <command>diff</command> command pays no attention 1.173 - to file permissions, which is why <command role="hg-cmd">hg 1.174 - diff</command> prints nothing by default. If we supply it 1.175 - with the <option>-g</option> option, it tells us what really 1.176 - happened.</para> 1.177 + <para id="x_6cb">La commande normale <command>diff</command> ne fait pas 1.178 + attention aux permissions des fichiers, ce qui explique pourquoi 1.179 + <command role="hg-cmd">hg diff</command> n'affiche rien du tout par 1.180 + défaut. Si nous lui passons l'option <option>-g</option>, ceci nous 1.181 + informe de ce qu'il s'est vraiment passé.</para> 1.182 1.183 &interaction.ch04-diff.chmod.git; 1.184 </sect1> 1.185 1.186 <sect1> 1.187 - <title>Which files to manage, and which to avoid</title> 1.188 - 1.189 - <para id="x_6cc">Revision control systems are generally best at managing text 1.190 - files that are written by humans, such as source code, where the 1.191 - files do not change much from one revision to the next. Some 1.192 - centralized revision control systems can also deal tolerably 1.193 - well with binary files, such as bitmap images.</para> 1.194 - 1.195 - <para id="x_6cd">For instance, a game development team will typically manage 1.196 - both its source code and all of its binary assets (e.g. geometry 1.197 - data, textures, map layouts) in a revision control 1.198 - system.</para> 1.199 - 1.200 - <para id="x_6ce">Because it is usually impossible to merge two conflicting 1.201 - modifications to a binary file, centralized systems often 1.202 - provide a file locking mechanism that allow a user to say 1.203 - <quote>I am the only person who can edit this 1.204 - file</quote>.</para> 1.205 - 1.206 - <para id="x_6cf">Compared to a centralized system, a distributed revision 1.207 - control system changes some of the factors that guide decisions 1.208 - over which files to manage and how.</para> 1.209 - 1.210 - <para id="x_6d0">For instance, a distributed revision control system cannot, 1.211 - by its nature, offer a file locking facility. There is thus no 1.212 - built-in mechanism to prevent two people from making conflicting 1.213 - changes to a binary file. If you have a team where several 1.214 - people may be editing binary files frequently, it may not be a 1.215 - good idea to use Mercurial&emdash;or any other distributed 1.216 - revision control system&emdash;to manage those files.</para> 1.217 - 1.218 - <para id="x_6d1">When storing modifications to a file, Mercurial usually 1.219 - saves only the differences between the previous and current 1.220 - versions of the file. For most text files, this is extremely 1.221 - efficient. However, some files (particularly binary files) are 1.222 - laid out in such a way that even a small change to a file's 1.223 - logical content results in many or most of the bytes inside the 1.224 - file changing. For instance, compressed files are particularly 1.225 - susceptible to this. If the differences between each successive 1.226 - version of a file are always large, Mercurial will not be able 1.227 - to store the file's revision history very efficiently. This can 1.228 - affect both local storage needs and the amount of time it takes 1.229 - to clone a repository.</para> 1.230 - 1.231 - <para id="x_6d2">To get an idea of how this could affect you in practice, 1.232 - suppose you want to use Mercurial to manage an OpenOffice 1.233 - document. OpenOffice stores documents on disk as compressed zip 1.234 - files. Edit even a single letter of your document in OpenOffice, 1.235 - and almost every byte in the entire file will change when you 1.236 - save it. Now suppose that file is 2MB in size. Because most of 1.237 - the file changes every time you save, Mercurial will have to 1.238 - store all 2MB of the file every time you commit, even though 1.239 - from your perspective, perhaps only a few words are changing 1.240 - each time. A single frequently-edited file that is not friendly 1.241 - to Mercurial's storage assumptions can easily have an outsized 1.242 - effect on the size of the repository.</para> 1.243 - 1.244 - <para id="x_6d3">Even worse, if both you and someone else edit the OpenOffice 1.245 - document you're working on, there is no useful way to merge your 1.246 - work. In fact, there isn't even a good way to tell what the 1.247 - differences are between your respective changes.</para> 1.248 - 1.249 - <para id="x_6d4">There are thus a few clear recommendations about specific 1.250 - kinds of files to be very careful with.</para> 1.251 + <title>Quels fichiers gérer et lesquels éviter</title> 1.252 + 1.253 + <para id="x_6cc">Les systèmes de gestion de révisions sont en général 1.254 + meilleurs pour gérer les fichiers textes qui sont écrits par les 1.255 + humains, comme le code source, où les fichiers ne changent pas 1.256 + énormément d'une révision à l'autre. Certains systèmes de gestion de 1.257 + révisions centralisés peuvent aussi traiter très correctement les 1.258 + fichiers binaires, comme les images bitmap.</para> 1.259 + 1.260 + <para id="x_6cd">Par exemple, une équipe de développement de jeux va 1.261 + probablement gérer les deux : ses codes source et tous ses binaires 1.262 + (ex. données géométriques, textures, schémas de cartes) dans un système 1.263 + de contrôle de révisions.</para> 1.264 + <!-- Vérifier la traduction de map layouts que j'ai traduit par schémas 1.265 + de cartes --> 1.266 + 1.267 + <para id="x_6ce">Puisqu'il est d'habitude impossible de fusionner (merge) 1.268 + deux modifications conflictuelles sur un fichier binaire, les systèmes 1.269 + de version centralisé offre souvent un mécanisme de verrou (lock) qui 1.270 + permet à un utilisateur de dire <quote>Je suis la seule personne qui 1.271 + peut éditer ce fichier</quote>.</para> 1.272 + 1.273 + <para id="x_6cf">En comparaison d'un système centralisé, un système 1.274 + décentralisé de gestion de révision change certains facteurs qui 1.275 + guident les décisions sur quels fichiers gérer et comment.</para> 1.276 + 1.277 + <para id="x_6d0">Par exemple, un système distribé de gestion de révisions 1.278 + ne peut pas, par sa nature, offrir un système de vérrous (lock) sur les 1.279 + fichiers. Il n'y a donc pas de mécanisme inclu pour empécher deux 1.280 + personnes de faire des modifications conflictuelles sur un fichier 1.281 + binaire. Si vous avez une équipe où plusieurs personnes peuvent souvent 1.282 + éditer un fichier binaire, cela ne serait pas une très bonne idée 1.283 + d'utiliser Mercurial &emdash;ou tout autre système distribé de gestion 1.284 + de révisions&emdash;pour gérer ces fichiers.</para> 1.285 + 1.286 + <para id="x_6d1">Lorsque vous sauvegardez les modifications sur un 1.287 + fichier, Mercurial ne sauvegarde d'habitude que les différences entre 1.288 + la version précédente et la version actuelle d'un fichier. Pour la 1.289 + plupart des fichiers texte, ceci est très efficace. Cependant, certains 1.290 + fichiers (en particulier les fichiers binaires) sont construits d'une 1.291 + façon que même un petit changement sur un contenu logique résulte sur 1.292 + un changement de la plupart des octets du fichier. Par exemple, les 1.293 + fichiers compressés sont particulièrement suceptibles à ce 1.294 + comportement. Si les différences entre deux versions successives d'un 1.295 + fichier sont toujours très grandes, Mercurial ne sera pas capable de 1.296 + sauvegarder l'historique des révisions sur le fichier très 1.297 + efficacement. Ceci peut affecter aussi bien les besoins locaux pour 1.298 + sauvegarder que le temps nécessaire à cloner le dépôt.</para> 1.299 + 1.300 + <para id="x_6d2">Pour avoir une idée de comment ceci pourrait vous 1.301 + affecter en pratique, supposez que nous voulions que Mercurial gère des 1.302 + documents OpenOffice. OpenOffice sauvegarde les documents sur le disque 1.303 + comme des fichiers compressés zip. Même le fait d'éditer ces fichiers 1.304 + d'une seule lettre, changera les bits de la quasi totalité du fichier 1.305 + lorsque vous le sauvegarderez. Maintenant, supposez que ce fichier 1.306 + fasse une taille de 2Mo. Puisque la plupart du fichier change à chaque 1.307 + fois que vous sauvegardez, Mercurial aura à sauvegarder tous les 2Mo du 1.308 + fichier à chaque commit, alors que de votre point de vue, il n'y a 1.309 + seulement que peu de mots qui changent à chaque fois. Un seul fichier 1.310 + souvent édité qui n'est pas bien connu des hypothèses que Mercurial 1.311 + fait sur les sauvegardes peut facilement avoir un effet colossal sur la 1.312 + taille du dépôt.</para> 1.313 + 1.314 + <para id="x_6d3">Même pire, si vous et quelqu'un d'autre éditez le même 1.315 + document OpenOffice sur lequel vous travaillez, il n'y a pas de façon 1.316 + utile pour fusionner votre travail. En fait, il n'y a pas de moyen 1.317 + utile de montrer que les différences sont faites à partir de votre 1.318 + vision des modifications.</para> 1.319 + 1.320 + <para id="x_6d4">Il y a ainsi quelques recommendations claires sur les 1.321 + types de fichiers spécifiques avec lesquels faire très 1.322 + attention.</para> 1.323 1.324 <itemizedlist> 1.325 - <listitem> 1.326 - <para id="x_6d5">Files that are very large and incompressible, e.g. ISO 1.327 - CD-ROM images, will by virtue of sheer size make clones over 1.328 - a network very slow.</para> 1.329 - </listitem> 1.330 - <listitem> 1.331 - <para id="x_6d6">Files that change a lot from one revision to the next 1.332 - may be expensive to store if you edit them frequently, and 1.333 - conflicts due to concurrent edits may be difficult to 1.334 - resolve.</para> 1.335 + <listitem><para id="x_6d5">Les fichier qui sont très gros et 1.336 + imcompressibles, comme les images ISO de CD-ROM, sont, par 1.337 + construction très gros et les cloner à travers un réseau sera très 1.338 + long.</para></listitem> 1.339 + <!-- Trouver une meilleure traduction pour : ISO CD-ROM images, will by 1.340 + virtue of sheer size make clones over a network very slow. --> 1.341 + <listitem><para id="x_6d6">Les fichiers qui changent beaucoup d'une 1.342 + révision à l'autre peuvent être très chers à sauvegarder si vous 1.343 + les éditez fréquement, de même que les conflits entre deux éditions 1.344 + concurrentes peuvent être difficiles à résoudre.</para> 1.345 </listitem> 1.346 </itemizedlist> 1.347 </sect1> 1.348 1.349 <sect1> 1.350 - <title>Backups and mirroring</title> 1.351 - 1.352 - <para id="x_6d7">Since Mercurial maintains a complete copy of history in each 1.353 - clone, everyone who uses Mercurial to collaborate on a project 1.354 - can potentially act as a source of backups in the event of a 1.355 - catastrophe. If a central repository becomes unavailable, you 1.356 - can construct a replacement simply by cloning a copy of the 1.357 - repository from one contributor, and pulling any changes they 1.358 - may not have seen from others.</para> 1.359 - 1.360 - <para id="x_6d8">It is simple to use Mercurial to perform off-site backups 1.361 - and remote mirrors. Set up a periodic job (e.g. via the 1.362 - <command>cron</command> command) on a remote server to pull 1.363 - changes from your master repositories every hour. This will 1.364 - only be tricky in the unlikely case that the number of master 1.365 - repositories you maintain changes frequently, in which case 1.366 - you'll need to do a little scripting to refresh the list of 1.367 - repositories to back up.</para> 1.368 - 1.369 - <para id="x_6d9">If you perform traditional backups of your master 1.370 - repositories to tape or disk, and you want to back up a 1.371 - repository named <filename>myrepo</filename>, use <command>hg 1.372 - clone -U myrepo myrepo.bak</command> to create a 1.373 - clone of <filename>myrepo</filename> before you start your 1.374 - backups. The <option>-U</option> option doesn't check out a 1.375 - working directory after the clone completes, since that would be 1.376 - superfluous and make the backup take longer.</para> 1.377 - 1.378 - <para id="x_6da">If you then back up <filename>myrepo.bak</filename> instead 1.379 - of <filename>myrepo</filename>, you will be guaranteed to have a 1.380 - consistent snapshot of your repository that won't be pushed to 1.381 - by an insomniac developer in mid-backup.</para> 1.382 + <title>Sauvegardes et miroirs</title> 1.383 + 1.384 + <para id="x_6d7">Puisque Mercurial maintient une copie complète de 1.385 + l'historique de chaque clone, toute personne qui utilise Mercurial pour 1.386 + collaborer à un projet peut potentiellement agir comme une source de 1.387 + sauvegarde si une catastrophe avait lieue. Si un dépôt central devient 1.388 + indisponible, vous pouvez construire un remplaçant en clonant une copie 1.389 + du dépôt à partir d'un des contributeurs en récupérant (pull) tous les 1.390 + changements qui n'auraient pas été vus par les autres.</para> 1.391 + 1.392 + <para id="x_6d8">Il est simple d'utiliser Mercurial pour construire des 1.393 + serveurs hors site de sauvegarde et des miroirs distants. Initiez une 1.394 + tâche périodique (ex. via la commande <command>cron</command>) sur un 1.395 + serveur distant pour récupérer (pull) les changements de votre dépôt 1.396 + distant chaque heure. Ceci sera difficile seullement dans le cas 1.397 + improbable où le nombre des dépôts maîtres que vous maintenez change 1.398 + souvent, auquel cas vous aurez besoin de faire un peu de scripting pour 1.399 + raffraichir la liste des dépôt à sauvegarder.</para> 1.400 + 1.401 + <para id="x_6d9">Si vous exécutez des sauvegardes traditionnelles de 1.402 + votre dépôt maître sur des bandes ou disques, et que vous voulez 1.403 + sauvegarder un dépôt nommé <filename>myrepo</filename>, utilisez la 1.404 + commande <command>hg clone -U myrepo myrepo.bak</command> pour créer un 1.405 + clone de <filename>myrepo</filename> avant de commencer vos backups. 1.406 + L'option <option>-U</option> ne crée pas de répertoire de travail après 1.407 + que le clone soit accompli, puisque ceci serait superflu et ferait que 1.408 + la sauvegarde prenne plus de temps.</para> 1.409 + 1.410 + <para id="x_6da">Si vous voulez ensuite sauvegarder 1.411 + <filename>myrepo.bak</filename> au lieu de <filename>myrepo</filename>, 1.412 + vous aurez la garantie d'avoir une image (snapshot) consistente de 1.413 + votre dépôt sur lequel un développeur insomniac n'enverra (push) pas de 1.414 + changements en milieu de sauvegarde.</para> 1.415 </sect1> 1.416 </chapter> 1.417