# HG changeset patch # User Frédéric Bouquet # Date 1252537696 -7200 # Node ID 72de97557f111e49c07ce3d4cbc45430fac0c536 # Parent f0110009e9469d8b188347354267d7633695a31c French translation : 75% of ch05-daily translated diff -r f0110009e946 -r 72de97557f11 fr/ch05-daily.xml --- a/fr/ch05-daily.xml Wed Sep 09 16:07:36 2009 +0200 +++ b/fr/ch05-daily.xml Thu Sep 10 01:08:16 2009 +0200 @@ -7,513 +7,528 @@ Telling Mercurial which files to track - Mercurial does not work with files in your repository unless - you tell it to manage them. The hg - status command will tell you which files Mercurial - doesn't know about; it uses a - ? to display such - files. - - To tell Mercurial to track a file, use the hg add command. Once you have added a - file, the entry in the output of hg - status for that file changes from - ? to + Mercurial ne fonctionne pas avec les fichiers de votre + dépôt tant que vous ne lui avez pas dit de les gérer. La commande + hg status vous dira quels fichier sont + inconnus de Mercurial. Il utilise un + ? pour montrer ces fichiers. + + Pour informer Mercurial de suivre un fichier, utilisez + la commande hg add. Une fois que vous + avez ajouté un fichier, la ligne correspondante à ce fichier dans la + sortie de hg status change de + ? à A. - &interaction.daily.files.add; - - After you run a hg commit, - the files that you added before the commit will no longer be - listed in the output of hg - status. The reason for this is that by default, hg status only tells you about - interesting files&emdash;those that you have (for - example) modified, removed, or renamed. If you have a repository - that contains thousands of files, you will rarely want to know - about files that Mercurial is tracking, but that have not - changed. (You can still get this information; we'll return to - this later.) - - Once you add a file, Mercurial doesn't do anything with it - immediately. Instead, it will take a snapshot of the file's - state the next time you perform a commit. It will then continue - to track the changes you make to the file every time you commit, - until you remove the file. - - - Explicit versus implicit file naming - - A useful behavior that Mercurial has is that if you pass - the name of a directory to a command, every Mercurial command - will treat this as I want to operate on every file in - this directory and its subdirectories. + &interaction.daily.files.add; + + Après avoir exécuté un hg + commit, les fichiers que vous avez ajouté avant le commit + ne seront plus listé dans la sortie de hg + status. La raison de ceci est que par défaut, hg status ne vous montre que les fichiers + intéressants &emdash;ceux que vous avez (par exemple) + modifiés, supprimés ou renommés. Si vous avez un dépôt qui contient un + millier de fichiers, vous ne voudrez certainement que rarement entendre + parler des fichiers que Mercurial suit, mais qui n'ont pas changés. + (Vous pouvez quand même avoir cette information, nous y reviendrons + plus tard.) + + Une fois que vous ajoutez un fichier, Mercurial ne fait + rien du tout avec celui-ci immédiatement. A lieu de ça, il va prendre + un "snapshot" de l'état du fichier la prochaine fois que vous + exécuterez un commit. Il continuera ensuite à suivre les changements + que vous avez fait au fichier chaque fois que vous committerez, jusqu'à + ce que vous supprimiez le fichier. + + + Nommage des fichiers explicite versus implicite + + Un comportement utile que Mercurial possède est que si + vous passez le nom d'un répertoire à une commande, toute commande + Mercurial la traitera comme Je veux opérer sur chaque fichier + dans ce répertoire et ses sous-répertoires. &interaction.daily.files.add-dir; - Notice in this example that Mercurial printed - the names of the files it added, whereas it didn't do so when - we added the file named myfile.txt in the - earlier example. - - What's going on is that in the former case, we explicitly - named the file to add on the command line. The assumption - that Mercurial makes in such cases is that we know what we - are doing, and it doesn't print any output. - - However, when we imply the names of - files by giving the name of a directory, Mercurial takes the - extra step of printing the name of each file that it does - something with. This makes it more clear what is happening, - and reduces the likelihood of a silent and nasty surprise. - This behavior is common to most Mercurial commands. - - - - Mercurial tracks files, not directories - - Mercurial does not track directory information. Instead, - it tracks the path to a file. Before creating a file, it - first creates any missing directory components of the path. - After it deletes a file, it then deletes any empty directories - that were in the deleted file's path. This sounds like a - trivial distinction, but it has one minor practical - consequence: it is not possible to represent a completely - empty directory in Mercurial. - - Empty directories are rarely useful, and there are - unintrusive workarounds that you can use to achieve an - appropriate effect. The developers of Mercurial thus felt - that the complexity that would be required to manage empty - directories was not worth the limited benefit this feature - would bring. - - If you need an empty directory in your repository, there - are a few ways to achieve this. One is to create a directory, - then hg add a - hidden file to that directory. On Unix-like - systems, any file name that begins with a period - (.) is treated as hidden by - most commands and GUI tools. This approach is illustrated - below. - -&interaction.daily.files.hidden; - - Another way to tackle a need for an empty directory is to - simply create one in your automated build scripts before they - will need it. + Remarquez que dans cet exemple, Mercurial affiche le + nom des fichiers qu'il a ajouté, alors qu'il ne l'a pas fait lorsque + nous avons ajouté le fichier nommé myfile.txt + dans l'exemple précédent. + + Ce qu'il se passe est que dans le premier cas, nous + avons nommé explicitement le fichier à ajouter sur la ligne de + commande. La supposition que Mercurial fait dans ces cas est que nous + savons ce que nous faisons, il n'affiche dont rien en sortie. + + Cependant, lorsque nous avons + implicitement donné les fichiers à l'aide du nom + d'un répertoire, Mercurial prend le l'initiative d'afficher le nom de + chaque fichier avec lequel il fait quelque chose. Ceci clarifie ce + qu'il se passe, et réduit la probabilité d'une surprise silencieuse + et désagréable. Ce comportement est commun à la plupart des commandes + Mercurial. + + + Mercurial suit les fichiers, pas les répertoires + + Mercurial ne suit pas les informations sur les + répertoire. En contrepartie, il suit le chemin vers un fichier. Avant + de créer un fichier, il crée au préalable les répertoires manquants + dans le chemin. Après avoir supprimé un fichier, il supprime chaque + répertoire vide qui apparaît dans le chemin du fichier. Ceci apparaît + comme une distinction triviale, cependant, ceci a une conséquence + pratique mineure : il n'est pas possible de représenter un répertoire + totalement vide dans Mercurial. + + Les répertoires vides sont rarement utiles. Il existe + des solutions alternatives et non intrusives que vous pouvez utiliser + pour obtenir l'effet approprié. Les développeurs de Mercurial ont + ainsi pensé que la complexité requise pour gérer les répertoires + n'était pas aussi importante que le bénéfice que cette fonctionnalité + apporterait. + + Si vous avez besoin d'un répertoire vide dans votre + dépôt, il existe quelques façons d'y arriver. L'une d'elles est de + créer un répertoire et d'ensuite, faire un hg + add sur un fichier hidden file dans ce + répertoire. Sur les fichiers de type Unix, tout fichier dont le nom + commence avec un point (.) est + considéré comme caché par la plupart des commandes et outils + graphiques. Cette approche est illustré ci-après. + + &interaction.daily.files.hidden; + + Une autre façon de s'attaquer au besoin d'un + répertoire vide est de simplement en créer un dans vos scripts + de construction avant qu'ils n'en aient le besoin. - How to stop tracking a file - - Once you decide that a file no longer belongs in - your repository, use the hg - remove command. This deletes the file, and tells - Mercurial to stop tracking it (which will occur at the next - commit). A removed file is represented in the output of - hg status with a + Comment arrêter de suivre un fichier + + Une fois que vous décidez qu'un fichier n'appartient + plus à votre dépôt, utilisez la commande hg + remove. Ceci supprime le fichier et informe Mercurial + d'arrêter de le suivre (ce qui prendra effet lors du prochain commit). + Un fichier supprimé est représenté dans la sortie de la commande + hg status par un R. &interaction.daily.files.remove; - After you hg remove a file, - Mercurial will no longer track changes to that file, even if you - recreate a file with the same name in your working directory. - If you do recreate a file with the same name and want Mercurial - to track the new file, simply hg - add it. Mercurial will know that the newly added - file is not related to the old file of the same name. - - - Removing a file does not affect its history - - It is important to understand that removing a file has - only two effects. + Après avoir fait un hg + remove sur un fichier, Mercurial ne suivra plus aucun + changement sur ce fichier, même si vous recréez un fichier avec le même + nom dans le répertoire de travail. Si vous recréez un fichier avec le + même nom et que vous désirez que Mercurial suive ce dernier, faite + simplement un hg add sur celui-ci. + Mercurial saura alors que le nouveau fichier ne fait pas référence à + l'ancien fichier qui portait le même nom. + + + Supprimer un fichier n'affecte pas son historique + + Il est important de comprendre que supprmer un fichier + n'a que deux effets. + - It removes the current version of the file - from the working directory. - - It stops Mercurial from tracking changes to - the file, from the time of the next commit. - - Removing a file does not in any way - alter the history of the file. - - If you update the working directory to a - changeset that was committed when it was still tracking a file - that you later removed, the file will reappear in the working - directory, with the contents it had when you committed that - changeset. If you then update the working directory to a - later changeset, in which the file had been removed, Mercurial - will once again remove the file from the working - directory. - - - - Missing files - - Mercurial considers a file that you have deleted, but not - used hg remove to delete, to - be missing. A missing file is - represented with ! in the - output of hg status. - Mercurial commands will not generally do anything with missing - files. + Il supprime la version actuelle de ce + fichier du répertoire de travail. + + Il arrête, à partir du prochain commit, le + suivi de Mercurial sur les changements qui ont lieu sur ce + fichier. + + + Supprimer un fichier n'affecte en + aucun cas l'historique du + fichier. + + Si vous mettez à jour le répertoire de travail à un + changeset qui a été commité alors que le fichier que vous venez de + supprimer était encore suivi, ce fichier réaparaittra dans le + répertoire de travail, avec le contenu qu'il avait lorsque vous aviez + commité ce changeset. Si vous mettez à jour (update) le répertoire de + travail à un changeset ultérieur, dans lequel le fichier a été + supprimé, Mercurial supprimera une nouvelle fois le fichier du + répertoire de travail. + + + + Fichier manquants + + Mercurial considère qu'un fichier que vous avez + supprimé sans utiliserhg remove + comme étant manquant. Un fichier manquant est + représenté avec un ! en sortie de + hg status. + Les commandes Mercurial ne feront rien avec les fichiers + manquants. &interaction.daily.files.missing; - If your repository contains a file that hg status reports as missing, and - you want the file to stay gone, you can run hg remove at any - time later on, to tell Mercurial that you really did mean to - remove the file. + Si votre dépôt contient un fichier que hg status repporte comme manquant, et que + vous voulez que ce fichier reste supprimé, vous pouvez exécuter + hg remove à tout moment + pour dire à Mercurial que vous aviez bien voulu supprimer ce + fichier. &interaction.daily.files.remove-after; - On the other hand, if you deleted the missing file by - accident, give hg revert the - name of the file to recover. It will reappear, in unmodified - form. + D'un autre coté, si vous avez supprimé le fichier + manquant par accident, donnez à la commande hg + revert le nom du fichier à retrouver. Il réaparaitra dans + sa forme non modifiée. &interaction.daily.files.recover-missing; - - - - Aside: why tell Mercurial explicitly to remove a - file? - - You might wonder why Mercurial requires you to explicitly - tell it that you are deleting a file. Early during the - development of Mercurial, it let you delete a file however you - pleased; Mercurial would notice the absence of the file - automatically when you next ran a hg - commit, and stop tracking the file. In practice, - this made it too easy to accidentally remove a file without - noticing. - - - - Useful shorthand&emdash;adding and removing files in one - step - - Mercurial offers a combination command, hg addremove, that adds untracked - files and marks missing files as removed. + + + + + Entre nous : Pourquoi dire explicitement à Mercurial de supprimer un + fichier ? + + Vous pourriez vous demander pourquoi il est nécessaire + de dire exprécement à Mercurial que vous souhaitez supprimer un + fichier. Au début du développement de Mercurial, celui ci vous + laissait pourtant supprimer un fichier sans soucis ; Mercurial vous + aurait automatiquement informé de l'absence du fichier lorsque vous + auriez lancé un hg commit et arrêté + de le suivre. En pratique, ceci a montré qu'il était trop facile de + supprimer accidentellement un fichier sans le remarquer. + + + + Racourcis utile&emdash;ajouter et supprimer des fichiers en une + seule étape. + + Mercurial offre une commande combinée, hg addremove, qui ajoute les fichiers non + suivis et marque les fichiers manquants comme supprimés. &interaction.daily.files.addremove; - The hg commit command - also provides a - option that performs this same add-and-remove, immediately - followed by a commit. + La commande hg commit + fournit aussi une option qui + exécute le même ajouter-et-supprimer, immédiatement suivi d'un + commit. &interaction.daily.files.commit-addremove; + - Copying files - - Mercurial provides a hg - copy command that lets you make a new copy of a - file. When you copy a file using this command, Mercurial makes - a record of the fact that the new file is a copy of the original - file. It treats these copied files specially when you merge - your work with someone else's. - - - The results of copying during a merge - - What happens during a merge is that changes - follow a copy. To best illustrate what this - means, let's create an example. We'll start with the usual - tiny repository that contains a single file. + Copier des fichiers + + Mercurial fournit une commande hg + copy qui vous permet de faire une nouvelle copie d'un + fichier. Lorsque vous copiez un fichier en utilisant cette commande, + Mercurial crée un enregistrement du fait que ce nouveau fichier est une + copie du fichier originel. Il traite ces fichiers copiés spécialement + lorsque vous faites une fusion (merge) de votre travail avec quelqu'un + d'autre. + + + Les résultat d'une copie durant une fusion (merge) + + Ce qu'il se passe durant une fusion (merge) est que + les changements suivent une copie. Pour illustrer ce + que ça veut dire de la meilleure façon, créons un exemple. Nous + allons commencer avec le mini dépôt usuel qui contient un simple + fichier. &interaction.daily.copy.init; - We need to do some work in - parallel, so that we'll have something to merge. So let's - clone our repository. + Nous devons faire du travail en parallèle, ainsi, + nous aurons quelque chose à fusionner (merge). Donc clonons notre + dépôt. &interaction.daily.copy.clone; - Back in our initial repository, let's use the hg copy command to make a copy of - the first file we created. + De retour dans notre dépôt initial, utilisons la + commande hg copy pour faire une + copie du premier fichier que nous avons créé. &interaction.daily.copy.copy; - If we look at the output of the hg - status command afterwards, the copied file looks - just like a normal added file. + Si nous regardons ensuite à la sortie de la commande + hg status, les fichiers copiés + ont l'air de fichiers normalement ajoutés. &interaction.daily.copy.status; - But if we pass the option to hg status, it prints another line of - output: this is the file that our newly-added file was copied - from. + Mais si nous passons l'option à hg + status, il affiche une autre ligne de sortie : il s'agit + du fichier source pour notre copie. &interaction.daily.copy.status-copy; - Now, back in the repository we cloned, let's make a change - in parallel. We'll add a line of content to the original file - that we created. + Maintenant, de retour dans le dépôt que nous avons + cloné, et créons un changement en parallèle. Nous allons ajouter une + ligne de contenu au fichier original qui a été créé. &interaction.daily.copy.other; - Now we have a modified file in this - repository. When we pull the changes from the first - repository, and merge the two heads, Mercurial will propagate - the changes that we made locally to file - into its copy, new-file. + Maintenant, nous avons un fichier + file modifié dans ce dépôt. Lorsque nous + récupérons (pull) les changements depuis le premier répertoire et + fusionnons (merge) les deux HEADS, Mercurial propagera les + changements que nous avons fait localement au fichier + file dans sa copie + new-file. &interaction.daily.copy.merge; - - + + - Why should changes follow copies? - - This behavior&emdash;of changes to a file - propagating out to copies of the file&emdash;might seem - esoteric, but in most cases it's highly desirable. - - First of all, remember that this propagation - only happens when you merge. So if you - hg copy a file, and - subsequently modify the original file during the normal course - of your work, nothing will happen. - - The second thing to know is that modifications will only - propagate across a copy as long as the changeset that you're - merging changes from hasn't yet seen - the copy. - - The reason that Mercurial does this is as follows. Let's - say I make an important bug fix in a source file, and commit - my changes. Meanwhile, you've decided to hg copy the file in your repository, - without knowing about the bug or having seen the fix, and you - have started hacking on your copy of the file. - - If you pulled and merged my changes, and Mercurial - didn't propagate changes across copies, - your new source file would now contain the bug, and unless you - knew to propagate the bug fix by hand, the bug would - remain in your copy of the file. - - By automatically propagating the change that fixed the bug - from the original file to the copy, Mercurial prevents this - class of problem. To my knowledge, Mercurial is the - only revision control system that - propagates changes across copies like this. - - Once your change history has a record that the copy and - subsequent merge occurred, there's usually no further need to - propagate changes from the original file to the copied file, - and that's why Mercurial only propagates changes across copies - at the first merge, and not afterwards. - - - - How to make changes <emphasis>not</emphasis> follow a - copy - - If, for some reason, you decide that this business of - automatically propagating changes across copies is not for - you, simply use your system's normal file copy command (on - Unix-like systems, that's cp) to make a - copy of a file, then hg add - the new copy by hand. Before you do so, though, please do - reread , and make - an informed - decision that this behavior is not appropriate to your - specific case. - - - - Behavior of the <command role="hg-cmd">hg copy</command> - command - - When you use the hg copy - command, Mercurial makes a copy of each source file as it - currently stands in the working directory. This means that if - you make some modifications to a file, then hg copy it without first having - committed those changes, the new copy will also contain the - modifications you have made up until that point. (I find this - behavior a little counterintuitive, which is why I mention it - here.) - - The hg copy - command acts similarly to the Unix cp - command (you can use the hg - cp alias if you prefer). We must supply two or - more arguments, of which the last is treated as the - destination, and all others are - sources. - - If you pass hg copy a - single file as the source, and the destination does not exist, - it creates a new file with that name. + Pourquoi les changements devraient suivre les copies ? + + Ce comportement&emdash;des changements d'un fichiers + qui se propagent aux copies de ce fichier&emdash;peut sembler + ésotérique, mais, dans la plupart des cas, c'est hautement + désirable. + + Pour commencer, souvenez vous que cette propagation + a lieue seulement lors des fusions (merge). + Donc, si vous faites un hg copy sur + un fichier, et par la suite modifiez le fichier original durant le + cours normal de votre travail, rien n'a lieu. + + La deuxième chose à savoir c'est que les modifications + ne se propageront à travers une copie que si le changeset à partir + duquel vous faites une fusion (merge) n'a pas encore + vu la copie. + + La raison pour laquelle Mercurial fait ainsi est une + règle. Disons que je corrige un important bug dans un fichier source + et commit mes changements. Pendant ce temps, vous avez décidé de + faire un hg copy du fichier dans + votre dépôt, sans rien savoir au sujet du bug ou sans avoir rien vu à + propos de la correction, et vous avez commencé à "hacker" sur votre + copie du fichier. + + Si vous aviez récupéré (pull) et fusionné (merge) mes + changements, et que Mercurial n'avait pas + propagé les changements à travers les copies, votre nouveau fichier + source contiendrait maintenant le bug, et à moins que vous sachiez + qu'il faille propager la correction du bug à la main, le bug aurait + subsisté dans votre copie du fichier. + + En propageant automatiquement les changements qui + fixent les bugs à partir du fichier original vers les copies, + Mercurial prévient ce type de problèmes. A ma connaissance, Mercurial + est le seul système de gestion de révisions qui + propage les changements à travers les copies comme ceci. + + Une fois que votre historique des changements a un + enregistrement concernant une copie et une fusion postérieure qui a + eu lieue, il n'y a d'habitude pas d'autre besoin de propager les + changements du fichier originel vers le fichier copié, et c'est + pourquoi Mercurial ne propage les changements à travers les copies + seulement à la première fusion, et pas d'avantage. + + + + Comment faire des changements qui <emphasis>ne</emphasis> + suivent <emphasis>pas</emphasis> une copie + + Si pour une raison ou une autre, vous décidez que + cette fonctionnalité de propager automatiquement les changements à + travers les copies n'est pas pour vous, utilisez simplement la + commande normale de copie de votre système (sur les systèmes de type + Unix, il s'agit de cp) pour faire une copie d'un + fichier. Utilisez ensuite hg add + pour ajouter les nouveaux fichiers à la main. Cependant, avant d'en + faire ainsi, relisez , et faites + un choix en tout état de cause que cette fonctionnalité n'est pas + appropriée à votre cas spécifique. + + + + Comportement de la commande <command role="hg-cmd">hg copy</command> + + Lorsque vous utilisez la commande hg copy, Mercurial crée une copie de chaque + fichier source tel qu'il est actuellement dans le répertoire de + travail. Cela signifie que si vous faites des modifications à un + fichier, puis faites un hg copy sur + celui-ci sans avoir au préalable commité ces changements, la nouvelle + copie contiendra aussi les modifications que vous avez fait jusqu'à + ce point. modifications you have made up until that point. (Je + trouve ce comportement quelque peu contre intuitif, c'est pourquoi + j'en fais mention ici.) + + La commande hg copy + agit comme la commande Unix cp (vous pouvez + utilisez l'alias hg cp si vous + préférez). Nous devons lui donner deux ou plus arguments où le + dernier est considéré comme la destination, et + les autres comme les sources. + + Si vous passez à hg + copy un seul fichier source, et que la destination + n'existe pas, ceci créera un nouveau fichier avec ce nom. &interaction.daily.copy.simple; - - If the destination is a directory, Mercurial copies its - sources into that directory. + + Si la destination est un répertoire, Mercurial copie + les sources dans ce répertoire. &interaction.daily.copy.dir-dest; - Copying a directory is - recursive, and preserves the directory structure of the - source. + La copie de répertoire est récursive et préserve la + structure du répertoire source. &interaction.daily.copy.dir-src; - If the source and destination are both directories, the - source tree is recreated in the destination directory. - - &interaction.daily.copy.dir-src-dest; - - As with the hg remove - command, if you copy a file manually and then want Mercurial - to know that you've copied the file, simply use the option to hg copy. + Si la source et la destination sont tous deux des + répertoires, l'arborescence de la source est recrée dans le + répertoire destination. + + &interaction.daily.copy.dir-src-dest; + + Comme avec la commande hg + remove, si vous copiez un fichier manuellement et voulez + que Mercurial sache qu'il s'agit d'une copie, utilisez simplement + l'option avec hg copy. &interaction.daily.copy.after; - Renaming files - - It's rather more common to need to rename a file than to - make a copy of it. The reason I discussed the hg copy command before talking about - renaming files is that Mercurial treats a rename in essentially - the same way as a copy. Therefore, knowing what Mercurial does - when you copy a file tells you what to expect when you rename a - file. - - When you use the hg rename - command, Mercurial makes a copy of each source file, then - deletes it and marks the file as removed. - - &interaction.daily.rename.rename; - - The hg status command shows - the newly copied file as added, and the copied-from file as - removed. + Renommer les fichiers + + Il est plus commun d'avoir besoin de renommer un + fichier que d'en faire une copie. La raison pour laquelle j'ai discuté + de la commande hg copy avant de parler + de renommage des fichiers est que Mercurial traite les renommages + essenciellement comme une copie. Ainsi, savoir comment Mercurial traite + les copies de fichiers vous informe sur ce que vous êtes en droit + d'attendre lorsque vous renommez un fichier. + + Lorsque vous utilisez la commande hg rename, Mercurial crée uen copie de chaque + fichier source, les supprime et marque ces fichiers comme étant + supprimés. + + &interaction.daily.rename.rename; + + La commande hg status + montre le nouveau fichier comme ajouté et le fichier origine comme + supprimé. &interaction.daily.rename.status; - As with the results of a hg - copy, we must use the option to hg status to see that the added file - is really being tracked by Mercurial as a copy of the original, - now removed, file. + A cause du hg copy, + nous devons utiliser l'option + pour hg status afin d'observer que le + fichier ajouté est bien suivi par Mercurial comme étant une copie de + l'original maintenant supprimé. &interaction.daily.rename.status-copy; - As with hg remove and - hg copy, you can tell Mercurial - about a rename after the fact using the option. In most other - respects, the behavior of the hg - rename command, and the options it accepts, are - similar to the hg copy - command. - - If you're familiar with the Unix command line, you'll be - glad to know that hg rename - command can be invoked as hg - mv. - - - Renaming files and merging changes - - Since Mercurial's rename is implemented as - copy-and-remove, the same propagation of changes happens when - you merge after a rename as after a copy. - - If I modify a file, and you rename it to a new name, and - then we merge our respective changes, my modifications to the - file under its original name will be propagated into the file - under its new name. (This is something you might expect to - simply work, but not all revision control - systems actually do this.) - - Whereas having changes follow a copy is a feature where - you can perhaps nod and say yes, that might be - useful, it should be clear that having them follow a - rename is definitely important. Without this facility, it - would simply be too easy for changes to become orphaned when - files are renamed. - - - - Divergent renames and merging - - The case of diverging names occurs when two developers - start with a file&emdash;let's call it - foo&emdash;in their respective - repositories. + Comme avec hg remove et + hg copy, vous pouvez informer + Mercurial à propos d'un renommage après coup en utilisant l'option + . Dans le plus grand + respet, le comportement de la commande hg + rename, et les options qu'il accepte sont similaires à la + commande hg copy. + + Si vous êtes familié avec la ligne de commande Unix, + vous serez heureux d'apprendre que la commande hg rename peut être invoquée par hg mv. + + + Renommer les fichiers et fusionner (merge) les changements + + Puise que le rename de Mercurial est implanté comme un + "copy-and-remove", la même propagation des changements a lieue + lorsque vous fusionnez (merge) après un "rename" qu'après un + "copy". + + Si je modifie un fichier et que vous le renommez, si + ensuite nous fusionnons nos changements respectifs, mes modifications + sur le fichier sous son nom originel seront propagés vers le même + fichier sous son nouveau nom. (C'est quelque chose que vous pourriez + espérer voir fonctionner simplement, mais tous les + systèmes de gestion de version ne le font pas.) + + Tandis qu'avoir des changements qui suivent une copie + est une fonctionnalité où vous hocheriez sûrement la tête en disant + oui, cela pourrait être utile, il est clair que les + voir suivre un renommage est définitivement important. Sans cette + aptitude, il serait simplement trop facile d'avoir des changements + qui deviennent orphelins lorsque des fichiers sont renommés. + + + + Renommages divergeants et fusion (merge) + + Le cas de noms divergeants a lieu lorsque deux + développeurs commencent avec un fichier&emdash;apprelons le + foo&emdash;dans leurs dépôts respectifs. &interaction.rename.divergent.clone; - Anne renames the file to bar. + Anne renomme le fichier en + bar. &interaction.rename.divergent.rename.anne; - Meanwhile, Bob renames it to - quux. (Remember that hg mv is an alias for hg rename.) - - &interaction.rename.divergent.rename.bob; - - I like to think of this as a conflict because each - developer has expressed different intentions about what the - file ought to be named. - - What do you think should happen when they merge their - work? Mercurial's actual behavior is that it always preserves - both names when it merges changesets that - contain divergent renames. + Pendant ce temps, Bob le renomme en + quux. (Souvenez vous que hg mv est un alias pour hg rename.) + + &interaction.rename.divergent.rename.bob; + + J'aime à penser qu'il s'agit d'un conflit puisque + chaque développeur a exprimé différentes intentions au sujet de ce + que le nom de ce fichier aurait du être. + + Que pensez vous qu'il devrait se produire lorsqu'ils + fusionnent (merge) leurs travaux ? Le comportement actuel de + Mercurial est qu'il préserve toujours les deux + noms lorsqu'il fusionne (merge) des changesets qui contiennent des + renommages divergeants. &interaction.rename.divergent.merge; - Notice that while Mercurial warns about the divergent - renames, it leaves it up to you to do something about the - divergence after the merge. - - - - Convergent renames and merging - - Another kind of rename conflict occurs when two people - choose to rename different source files - to the same destination. In this case, - Mercurial runs its normal merge machinery, and lets you guide - it to a suitable resolution. - - - - Other name-related corner cases - - Mercurial has a longstanding bug in which it fails to - handle a merge where one side has a file with a given name, - while another has a directory with the same name. This is - documented as issue - 29. + Remarquez que bien que Mercurial vous avertisse au + sujet de la divergeance des renommages, il vous laisse faire quelque + chose au sujet de la divergeance après la fusion (merge). + + + + Renommages et fusion convergeants + + Un autre type de conflit de renommage intervient + lorsque deux personne choisissent de renommer différents fichiers + source vers la même + destination. Dans ce cas, Mercurial exécute la + machinerie normale de fusion (merge) et vous guide vers une + solution convenable. + + + + Autres cas anguleux relatifs aux noms + + Mercurial possède un bug de longue date dans lequel il + échoue à traiter une fusion (merge) où un coté a un fichier avec un + nom donné, alors que l'autre coté a un répertoire avec le même nom. + Ceci est documenté dans l'issue + 29. &interaction.issue29.go; @@ -521,98 +536,102 @@ - Recovering from mistakes - - Mercurial has some useful commands that will help you to - recover from some common mistakes. - - The hg revert command lets - you undo changes that you have made to your working directory. - For example, if you hg add a - file by accident, just run hg - revert with the name of the file you added, and - while the file won't be touched in any way, it won't be tracked - for adding by Mercurial any longer, either. You can also use - hg revert to get rid of - erroneous changes to a file. - - It is helpful to remember that the hg revert command is useful for - changes that you have not yet committed. Once you've committed - a change, if you decide it was a mistake, you can still do - something about it, though your options may be more - limited. - - For more information about the hg revert command, and details about - how to deal with changes you have already committed, see . + Récupération d'erreurs + + Mercurial possède certaines commandes utiles qui vont + vous aider à récupérer certaines erreurs communes. + + La commande hg revert + vous permet d'annuler les changements que vous avez fait dans votre + répertoire de travail. Par exemple, si vous faites un hg add sur un fichier par accident, exécutez + juste hg revert avec le nom du fichier + que vous avez ajouté et tandis que le fichier ne touché d'une + quelconque manière, il ne sera plus suivi comme ajouté par Mercurial. + Vous pouvez aussi utiliser la commande hg + revert pour vous débarasser de modifications erronés + apportées à un fichier. + + Il est utile de se souvenir que la commande hg revert est utile pour les modifications + qui n'ont pas encore été commitées. Une fois que vous avez committé un + changement, si vous décidez qu'il s'agissait d'une erreur, vous pouvez + toujours faire quelquechose à ce sujet, bien que vos options seront + un peu plus limitées. + + Pour plus d'informations au sujet de la commande + hg revert, et des détails sur comment + traiter les modifications que vous avez déjà committées, référez vous à + . - Dealing with tricky merges - - In a complicated or large project, it's not unusual for a - merge of two changesets to result in some headaches. Suppose - there's a big source file that's been extensively edited by each - side of a merge: this is almost inevitably going to result in - conflicts, some of which can take a few tries to sort - out. - - Let's develop a simple case of this and see how to deal with - it. We'll start off with a repository containing one file, and - clone it twice. + Traiter avec les fusions (merge) malicieuses + + Dans des projets compliqués ou conséquents, il n'est pas + rare qu'une fusion (merge) de deux changesets finisse par une migraine. + Supposez qu'il y a un gros fichier source qui a été largement édité de + chaque coté de la fusion (merge) : ceci va inévitablement résulter en + conflits, dont certains peuvent prendre quelques essais pour s'en + sortir. + + Développons en un cas simple pour voir comment traiter + avec. Nous allons commencer avec un dépôt contenant un fichier, et le + cloner deux fois. &interaction.ch04-resolve.init; - In one clone, we'll modify the file in one way. + Dans un des clones, nous allons modifier le fichier + d'une façon. &interaction.ch04-resolve.left; - In another, we'll modify the file differently. + Dans un autre, nous allons modifier le fichier + différamment. &interaction.ch04-resolve.right; - Next, we'll pull each set of changes into our original - repo. + Ensuite, nous allons récupérer (pull) chaque ensemble de + changement dans notre dépôt original. &interaction.ch04-resolve.pull; - We expect our repository to now contain two heads. + Nous nous attendons à ce que notre dépôt contienne deux + HEADS. &interaction.ch04-resolve.heads; - Normally, if we run hg - merge at this point, it will drop us into a GUI that - will let us manually resolve the conflicting edits to - myfile.txt. However, to simplify things - for presentation here, we'd like the merge to fail immediately - instead. Here's one way we can do so. + Normalement, si nous lançons hg + merge à ce point, il nous renverra vers une interface + utilisateur qui nous permettra de résoudre manuellement les éditions + conflictuelles sur le fichier myfile.txt. + Cependant, pour simplifier les choses dans la présentation ici, nous + aimerions que la fusion (merge) échoue immédiatement plutôt. Voici une + façon de le faire. &interaction.ch04-resolve.export; - We've told Mercurial's merge machinery to run the command - false (which, as we desire, fails - immediately) if it detects a merge that it can't sort out - automatically. - - If we now fire up hg - merge, it should grind to a halt and report a - failure. + Nous avons dit à la machinerie de fusion de Mercurial + d'exécuter la commande false (qui échoue + immédiatement, à la demande) s'il détecte une fusion (merge) qu'il ne + peut pas arranger automatiquement. + + Si nous appelons maintenant hg + merge, il devrait planter et reporter une erreur. &interaction.ch04-resolve.merge; - Even if we don't notice that the merge failed, Mercurial - will prevent us from accidentally committing the result of a - failed merge. + Même si nous ne remarquons pas qu'une fusion (merge) a + échoué, Mercurial nous empéchera de committer le résultat d'une fusion + ratée. &interaction.ch04-resolve.cifail; - When hg commit fails in - this case, it suggests that we use the unfamiliar hg resolve command. As usual, - hg help resolve will print a - helpful synopsis. + Lorsque hg commit + échoue dans ce cas, il suggère que nous utilisons la commande peu + connue hg resolve. Comme d'habitude, + hg help resolve affichera une aide + sommaire. File resolution states