File resolution states

# HG changeset patch # User Frédéric Bouquet # Date 1252580794 -7200 # Node ID a3a9eabfe2a4ffb5c857f2f690fa4962de919b53 # Parent 72de97557f111e49c07ce3d4cbc45430fac0c536 French translation : ch05-daily translated diff -r 72de97557f11 -r a3a9eabfe2a4 fr/ch05-daily.xml --- a/fr/ch05-daily.xml Thu Sep 10 01:08:16 2009 +0200 +++ b/fr/ch05-daily.xml Thu Sep 10 13:06:34 2009 +0200 @@ -634,221 +634,231 @@ sommaire. - File resolution states - - When a merge occurs, most files will usually remain - unmodified. For each file where Mercurial has to do - something, it tracks the state of the file. + Etats de résolution des fichiers + + + Lorsqu'une fusion intervient, la plupart des fichier + vont, la plupart du temps, rester sans modification. Pour chaque + fichier sur lequel Mercurial doit faire quelque chose, il suit l'état + de celui-ci. - - A resolved file has been - successfully merged, either automatically by Mercurial or - manually with human intervention. - - - An unresolved file was not merged - successfully, and needs more attention. - + Un fichier + resolved a été fusionné + (merge) avec succès, que ce soit automatiquement par Mercurial ou + manuellement par une intervention humaine. + Un fichier + unresolved n'a pas été + fusionné (merge) correctement et a besoin de plus + d'attention. + - If Mercurial sees any file in the - unresolved state after a merge, it considers the merge to have - failed. Fortunately, we do not need to restart the entire - merge from scratch. - - The or - option to hg resolve prints out the state of - each merged file. + Si Mercurial voit n'importe quel + fichier dans un état unresolved après une fusion + (merge), il considère que la fusion (merge) a échoué. Heureusement, + nous n'avons pas à recommencer la fusion (merge) à partir du + début. + + L'option + ou passée à hg resolve liste l'état de chaque fichier + fusionné (merge). &interaction.ch04-resolve.list; - In the output from hg - resolve, a resolved file is marked with - R, while an unresolved file is marked with - U. If any files are listed with - U, we know that an attempt to commit the - results of the merge will fail. - - - - Resolving a file merge - - We have several options to move a file from the unresolved - into the resolved state. By far the most common is to rerun - hg resolve. If we pass the - names of individual files or directories, it will retry the - merges of any unresolved files present in those locations. We - can also pass the - or option, which - will retry the merges of all unresolved - files. - - Mercurial also lets us modify the resolution state of a - file directly. We can manually mark a file as resolved using - the option, or - as unresolved using the option. This allows - us to clean up a particularly messy merge by hand, and to keep - track of our progress with each file as we go. + En sortie de hg + resolve, un fichier "resolved" est marqué avec un + R, alors qu'un fichier "unresolved" est marqué + d'un U. S'il existe un fichier listé avec un + U, nous savons qu'essayer de committer le résultat + de la fusion (merge) échoura. + + + + Résoudre une fusion de fichier + + Nous avons plusieurs options pour changer l'état d'un + fichier de "unresolved" à "resolved". Le plus commun est de relancer + hg resolve. Si nous passons les noms + des fichiers individuels ou des répertoires, ceci retentera la fusion + de tous les fichiers présents à cet endroit. Nous pouvons aussi + passer l'option ou + qui tentera de fusionner + tous les fichiers "unresolved". + + Mercurial nous laisse aussi modifier la résolution + d'un fichier directement. Nous pouvons marquer un fichier "resolved" + en utilisant l'option , + ou "unresolved" en utilisant l'option . Ceci nous autorise à + nettoyer une fusion particulièrement compliqué à la main, et de + garder un suivi de nos progrès avec chaque fichier pendant que nous + procédons. - More useful diffs - - The default output of the hg - diff command is backwards compatible with the - regular diff command, but this has some - drawbacks. - - Consider the case where we use hg - rename to rename a file. + Des diffs plus utiles + + La sortie par défaut de la commande hg diff est compatible rétrospectivement avec la commande régulière diff, mais ceci a quelques inconvénients. + + Considérez le cas où nous utilisons hg + rename pour renommer un fichier. &interaction.ch04-diff.rename.basic; - The output of hg diff above - obscures the fact that we simply renamed a file. The hg diff command accepts an option, - or , to use a newer - diff format that displays such information in a more readable - form. + La sortie de hg diff ci + dessus cache le fait que nous avons simplement renommé un fichier. La + commande hg diff accepte l'option + ou pour utiliser un nouveau + format de diff qui montre ces informations sous une forme plus + expressive. &interaction.ch04-diff.rename.git; - This option also helps with a case that can otherwise be - confusing: a file that appears to be modified according to - hg status, but for which - hg diff prints nothing. This - situation can arise if we change the file's execute - permissions. + Cette option peut aussi aider avec le cas autrement + confus : un fichier qui apparaît comme étant modifié en accord avec + hg status, mais où hg diff n'affiche rien. Cette situation peut + survenir si nous changeons les permissions d'exécution du + fichier. &interaction.ch04-diff.chmod; - The normal diff command pays no attention - to file permissions, which is why hg - diff prints nothing by default. If we supply it - with the option, it tells us what really - happened. + La commande normale diff ne fait pas + attention aux permissions des fichiers, ce qui explique pourquoi + hg diff n'affiche rien du tout par + défaut. Si nous lui passons l'option , ceci nous + informe de ce qu'il s'est vraiment passé. &interaction.ch04-diff.chmod.git; - Which files to manage, and which to avoid - - Revision control systems are generally best at managing text - files that are written by humans, such as source code, where the - files do not change much from one revision to the next. Some - centralized revision control systems can also deal tolerably - well with binary files, such as bitmap images. - - For instance, a game development team will typically manage - both its source code and all of its binary assets (e.g. geometry - data, textures, map layouts) in a revision control - system. - - Because it is usually impossible to merge two conflicting - modifications to a binary file, centralized systems often - provide a file locking mechanism that allow a user to say - I am the only person who can edit this - file. - - Compared to a centralized system, a distributed revision - control system changes some of the factors that guide decisions - over which files to manage and how. - - For instance, a distributed revision control system cannot, - by its nature, offer a file locking facility. There is thus no - built-in mechanism to prevent two people from making conflicting - changes to a binary file. If you have a team where several - people may be editing binary files frequently, it may not be a - good idea to use Mercurial&emdash;or any other distributed - revision control system&emdash;to manage those files. - - When storing modifications to a file, Mercurial usually - saves only the differences between the previous and current - versions of the file. For most text files, this is extremely - efficient. However, some files (particularly binary files) are - laid out in such a way that even a small change to a file's - logical content results in many or most of the bytes inside the - file changing. For instance, compressed files are particularly - susceptible to this. If the differences between each successive - version of a file are always large, Mercurial will not be able - to store the file's revision history very efficiently. This can - affect both local storage needs and the amount of time it takes - to clone a repository. - - To get an idea of how this could affect you in practice, - suppose you want to use Mercurial to manage an OpenOffice - document. OpenOffice stores documents on disk as compressed zip - files. Edit even a single letter of your document in OpenOffice, - and almost every byte in the entire file will change when you - save it. Now suppose that file is 2MB in size. Because most of - the file changes every time you save, Mercurial will have to - store all 2MB of the file every time you commit, even though - from your perspective, perhaps only a few words are changing - each time. A single frequently-edited file that is not friendly - to Mercurial's storage assumptions can easily have an outsized - effect on the size of the repository. - - Even worse, if both you and someone else edit the OpenOffice - document you're working on, there is no useful way to merge your - work. In fact, there isn't even a good way to tell what the - differences are between your respective changes. - - There are thus a few clear recommendations about specific - kinds of files to be very careful with. + Quels fichiers gérer et lesquels éviter + + Les systèmes de gestion de révisions sont en général + meilleurs pour gérer les fichiers textes qui sont écrits par les + humains, comme le code source, où les fichiers ne changent pas + énormément d'une révision à l'autre. Certains systèmes de gestion de + révisions centralisés peuvent aussi traiter très correctement les + fichiers binaires, comme les images bitmap. + + Par exemple, une équipe de développement de jeux va + probablement gérer les deux : ses codes source et tous ses binaires + (ex. données géométriques, textures, schémas de cartes) dans un système + de contrôle de révisions. + + + Puisqu'il est d'habitude impossible de fusionner (merge) + deux modifications conflictuelles sur un fichier binaire, les systèmes + de version centralisé offre souvent un mécanisme de verrou (lock) qui + permet à un utilisateur de dire Je suis la seule personne qui + peut éditer ce fichier. + + En comparaison d'un système centralisé, un système + décentralisé de gestion de révision change certains facteurs qui + guident les décisions sur quels fichiers gérer et comment. + + Par exemple, un système distribé de gestion de révisions + ne peut pas, par sa nature, offrir un système de vérrous (lock) sur les + fichiers. Il n'y a donc pas de mécanisme inclu pour empécher deux + personnes de faire des modifications conflictuelles sur un fichier + binaire. Si vous avez une équipe où plusieurs personnes peuvent souvent + éditer un fichier binaire, cela ne serait pas une très bonne idée + d'utiliser Mercurial &emdash;ou tout autre système distribé de gestion + de révisions&emdash;pour gérer ces fichiers. + + Lorsque vous sauvegardez les modifications sur un + fichier, Mercurial ne sauvegarde d'habitude que les différences entre + la version précédente et la version actuelle d'un fichier. Pour la + plupart des fichiers texte, ceci est très efficace. Cependant, certains + fichiers (en particulier les fichiers binaires) sont construits d'une + façon que même un petit changement sur un contenu logique résulte sur + un changement de la plupart des octets du fichier. Par exemple, les + fichiers compressés sont particulièrement suceptibles à ce + comportement. Si les différences entre deux versions successives d'un + fichier sont toujours très grandes, Mercurial ne sera pas capable de + sauvegarder l'historique des révisions sur le fichier très + efficacement. Ceci peut affecter aussi bien les besoins locaux pour + sauvegarder que le temps nécessaire à cloner le dépôt. + + Pour avoir une idée de comment ceci pourrait vous + affecter en pratique, supposez que nous voulions que Mercurial gère des + documents OpenOffice. OpenOffice sauvegarde les documents sur le disque + comme des fichiers compressés zip. Même le fait d'éditer ces fichiers + d'une seule lettre, changera les bits de la quasi totalité du fichier + lorsque vous le sauvegarderez. Maintenant, supposez que ce fichier + fasse une taille de 2Mo. Puisque la plupart du fichier change à chaque + fois que vous sauvegardez, Mercurial aura à sauvegarder tous les 2Mo du + fichier à chaque commit, alors que de votre point de vue, il n'y a + seulement que peu de mots qui changent à chaque fois. Un seul fichier + souvent édité qui n'est pas bien connu des hypothèses que Mercurial + fait sur les sauvegardes peut facilement avoir un effet colossal sur la + taille du dépôt. + + Même pire, si vous et quelqu'un d'autre éditez le même + document OpenOffice sur lequel vous travaillez, il n'y a pas de façon + utile pour fusionner votre travail. En fait, il n'y a pas de moyen + utile de montrer que les différences sont faites à partir de votre + vision des modifications. + + Il y a ainsi quelques recommendations claires sur les + types de fichiers spécifiques avec lesquels faire très + attention. - - Files that are very large and incompressible, e.g. ISO - CD-ROM images, will by virtue of sheer size make clones over - a network very slow. - - - Files that change a lot from one revision to the next - may be expensive to store if you edit them frequently, and - conflicts due to concurrent edits may be difficult to - resolve. + Les fichier qui sont très gros et + imcompressibles, comme les images ISO de CD-ROM, sont, par + construction très gros et les cloner à travers un réseau sera très + long. + + Les fichiers qui changent beaucoup d'une + révision à l'autre peuvent être très chers à sauvegarder si vous + les éditez fréquement, de même que les conflits entre deux éditions + concurrentes peuvent être difficiles à résoudre. - Backups and mirroring - - Since Mercurial maintains a complete copy of history in each - clone, everyone who uses Mercurial to collaborate on a project - can potentially act as a source of backups in the event of a - catastrophe. If a central repository becomes unavailable, you - can construct a replacement simply by cloning a copy of the - repository from one contributor, and pulling any changes they - may not have seen from others. - - It is simple to use Mercurial to perform off-site backups - and remote mirrors. Set up a periodic job (e.g. via the - cron command) on a remote server to pull - changes from your master repositories every hour. This will - only be tricky in the unlikely case that the number of master - repositories you maintain changes frequently, in which case - you'll need to do a little scripting to refresh the list of - repositories to back up. - - If you perform traditional backups of your master - repositories to tape or disk, and you want to back up a - repository named myrepo, use hg - clone -U myrepo myrepo.bak to create a - clone of myrepo before you start your - backups. The option doesn't check out a - working directory after the clone completes, since that would be - superfluous and make the backup take longer. - - If you then back up myrepo.bak instead - of myrepo, you will be guaranteed to have a - consistent snapshot of your repository that won't be pushed to - by an insomniac developer in mid-backup. + Sauvegardes et miroirs + + Puisque Mercurial maintient une copie complète de + l'historique de chaque clone, toute personne qui utilise Mercurial pour + collaborer à un projet peut potentiellement agir comme une source de + sauvegarde si une catastrophe avait lieue. Si un dépôt central devient + indisponible, vous pouvez construire un remplaçant en clonant une copie + du dépôt à partir d'un des contributeurs en récupérant (pull) tous les + changements qui n'auraient pas été vus par les autres. + + Il est simple d'utiliser Mercurial pour construire des + serveurs hors site de sauvegarde et des miroirs distants. Initiez une + tâche périodique (ex. via la commande cron) sur un + serveur distant pour récupérer (pull) les changements de votre dépôt + distant chaque heure. Ceci sera difficile seullement dans le cas + improbable où le nombre des dépôts maîtres que vous maintenez change + souvent, auquel cas vous aurez besoin de faire un peu de scripting pour + raffraichir la liste des dépôt à sauvegarder. + + Si vous exécutez des sauvegardes traditionnelles de + votre dépôt maître sur des bandes ou disques, et que vous voulez + sauvegarder un dépôt nommé myrepo, utilisez la + commande hg clone -U myrepo myrepo.bak pour créer un + clone de myrepo avant de commencer vos backups. + L'option ne crée pas de répertoire de travail après + que le clone soit accompli, puisque ceci serait superflu et ferait que + la sauvegarde prenne plus de temps. + + Si vous voulez ensuite sauvegarder + myrepo.bak au lieu de myrepo, + vous aurez la garantie d'avoir une image (snapshot) consistente de + votre dépôt sur lequel un développeur insomniac n'enverra (push) pas de + changements en milieu de sauvegarde.