1.1 --- a/fr/ch05-daily.xml	Wed Sep 09 16:07:36 2009 +0200
     1.2 +++ b/fr/ch05-daily.xml	Thu Sep 10 01:08:16 2009 +0200
     1.3 @@ -7,513 +7,528 @@
     1.4    <sect1>
     1.5      <title>Telling Mercurial which files to track</title>
     1.6  
     1.7 -    <para id="x_1a3">Mercurial does not work with files in your repository unless
     1.8 -      you tell it to manage them.  The <command role="hg-cmd">hg
     1.9 -	status</command> command will tell you which files Mercurial
    1.10 -      doesn't know about; it uses a
    1.11 -      <quote><literal>?</literal></quote> to display such
    1.12 -      files.</para>
    1.13 -
    1.14 -    <para id="x_1a4">To tell Mercurial to track a file, use the <command
    1.15 -	role="hg-cmd">hg add</command> command.  Once you have added a
    1.16 -      file, the entry in the output of <command role="hg-cmd">hg
    1.17 -	status</command> for that file changes from
    1.18 -      <quote><literal>?</literal></quote> to
    1.19 +    <para id="x_1a3">Mercurial ne fonctionne pas avec les fichiers de votre
    1.20 +      dépôt tant que vous ne lui avez pas dit de les gérer. La commande
    1.21 +      <command role="hg-cmd">hg status</command> vous dira quels fichier sont
    1.22 +      inconnus de Mercurial. Il utilise un
    1.23 +      <quote><literal>?</literal></quote> pour montrer ces fichiers.</para>
    1.24 +
    1.25 +    <para id="x_1a4">Pour informer Mercurial de suivre un fichier, utilisez
    1.26 +      la commande <command role="hg-cmd">hg add</command>. Une fois que vous
    1.27 +      avez ajouté un fichier, la ligne correspondante à ce fichier dans la
    1.28 +      sortie de <command role="hg-cmd">hg status</command> change de
    1.29 +      <quote><literal>?</literal></quote> à
    1.30        <quote><literal>A</literal></quote>.</para>
    1.31  
    1.32 -      &interaction.daily.files.add;
    1.33 -
    1.34 -    <para id="x_1a5">After you run a <command role="hg-cmd">hg commit</command>,
    1.35 -      the files that you added before the commit will no longer be
    1.36 -      listed in the output of <command role="hg-cmd">hg
    1.37 -	status</command>.  The reason for this is that by default, <command
    1.38 -	role="hg-cmd">hg status</command> only tells you about
    1.39 -      <quote>interesting</quote> files&emdash;those that you have (for
    1.40 -      example) modified, removed, or renamed.  If you have a repository
    1.41 -      that contains thousands of files, you will rarely want to know
    1.42 -      about files that Mercurial is tracking, but that have not
    1.43 -      changed.  (You can still get this information; we'll return to
    1.44 -      this later.)</para>
    1.45 -
    1.46 -    <para id="x_1a6">Once you add a file, Mercurial doesn't do anything with it
    1.47 -      immediately.  Instead, it will take a snapshot of the file's
    1.48 -      state the next time you perform a commit.  It will then continue
    1.49 -      to track the changes you make to the file every time you commit,
    1.50 -      until you remove the file.</para>
    1.51 -
    1.52 -    <sect2>
    1.53 -      <title>Explicit versus implicit file naming</title>
    1.54 -
    1.55 -      <para id="x_1a7">A useful behavior that Mercurial has is that if you pass
    1.56 -	the name of a directory to a command, every Mercurial command
    1.57 -	will treat this as <quote>I want to operate on every file in
    1.58 -	  this directory and its subdirectories</quote>.</para>
    1.59 +    &interaction.daily.files.add;
    1.60 +
    1.61 +    <para id="x_1a5">Après avoir exécuté un <command role="hg-cmd">hg
    1.62 +        commit</command>, les fichiers que vous avez ajouté avant le commit
    1.63 +      ne seront plus listé dans la sortie de <command role="hg-cmd">hg
    1.64 +        status</command>. La raison de ceci est que par défaut, <command
    1.65 +        role="hg-cmd">hg status</command> ne vous montre que les fichiers
    1.66 +      <quote>intéressants</quote> &emdash;ceux que vous avez (par exemple)
    1.67 +      modifiés, supprimés ou renommés. Si vous avez un dépôt qui contient un
    1.68 +      millier de fichiers, vous ne voudrez certainement que rarement entendre
    1.69 +      parler des fichiers que Mercurial suit, mais qui n'ont pas changés.
    1.70 +      (Vous pouvez quand même avoir cette information, nous y reviendrons
    1.71 +      plus tard.)</para>
    1.72 +
    1.73 +    <para id="x_1a6">Une fois que vous ajoutez un fichier, Mercurial ne fait
    1.74 +      rien du tout avec celui-ci immédiatement. A lieu de ça, il va prendre
    1.75 +      un "snapshot" de l'état du fichier la prochaine fois que vous
    1.76 +      exécuterez un commit. Il continuera ensuite à suivre les changements
    1.77 +      que vous avez fait au fichier chaque fois que vous committerez, jusqu'à
    1.78 +      ce que vous supprimiez le fichier.</para>
    1.79 +
    1.80 +    <sect2>
    1.81 +      <title>Nommage des fichiers explicite versus implicite</title>
    1.82 +
    1.83 +      <para id="x_1a7">Un comportement utile que Mercurial possède est que si
    1.84 +        vous passez le nom d'un répertoire à une commande, toute commande
    1.85 +        Mercurial la traitera comme <quote>Je veux opérer sur chaque fichier
    1.86 +          dans ce répertoire et ses sous-répertoires</quote>.</para>
    1.87  
    1.88        &interaction.daily.files.add-dir;
    1.89  
    1.90 -      <para id="x_1a8">Notice in this example that Mercurial printed
    1.91 -	the names of the files it added, whereas it didn't do so when
    1.92 -	we added the file named <filename>myfile.txt</filename> in the
    1.93 -	earlier example.</para>
    1.94 -
    1.95 -      <para id="x_1a9">What's going on is that in the former case, we explicitly
    1.96 -	named the file to add on the command line.  The assumption
    1.97 -	that Mercurial makes in such cases is that we know what we
    1.98 -	are doing, and it doesn't print any output.</para>
    1.99 -
   1.100 -      <para id="x_1aa">However, when we <emphasis>imply</emphasis> the names of
   1.101 -	files by giving the name of a directory, Mercurial takes the
   1.102 -	extra step of printing the name of each file that it does
   1.103 -	something with.  This makes it more clear what is happening,
   1.104 -	and reduces the likelihood of a silent and nasty surprise.
   1.105 -	This behavior is common to most Mercurial commands.</para>
   1.106 -    </sect2>
   1.107 -
   1.108 -    <sect2>
   1.109 -      <title>Mercurial tracks files, not directories</title>
   1.110 -
   1.111 -      <para id="x_1ab">Mercurial does not track directory information.  Instead,
   1.112 -	it tracks the path to a file.  Before creating a file, it
   1.113 -	first creates any missing directory components of the path.
   1.114 -	After it deletes a file, it then deletes any empty directories
   1.115 -	that were in the deleted file's path.  This sounds like a
   1.116 -	trivial distinction, but it has one minor practical
   1.117 -	consequence: it is not possible to represent a completely
   1.118 -	empty directory in Mercurial.</para>
   1.119 -
   1.120 -      <para id="x_1ac">Empty directories are rarely useful, and there are
   1.121 -	unintrusive workarounds that you can use to achieve an
   1.122 -	appropriate effect.  The developers of Mercurial thus felt
   1.123 -	that the complexity that would be required to manage empty
   1.124 -	directories was not worth the limited benefit this feature
   1.125 -	would bring.</para>
   1.126 -
   1.127 -      <para id="x_1ad">If you need an empty directory in your repository, there
   1.128 -	are a few ways to achieve this. One is to create a directory,
   1.129 -	then <command role="hg-cmd">hg add</command> a
   1.130 -	<quote>hidden</quote> file to that directory.  On Unix-like
   1.131 -	systems, any file name that begins with a period
   1.132 -	(<quote><literal>.</literal></quote>) is treated as hidden by
   1.133 -	most commands and GUI tools.  This approach is illustrated
   1.134 -	below.</para>
   1.135 -
   1.136 -&interaction.daily.files.hidden;
   1.137 -
   1.138 -      <para id="x_1ae">Another way to tackle a need for an empty directory is to
   1.139 -	simply create one in your automated build scripts before they
   1.140 -	will need it.</para>
   1.141 +      <para id="x_1a8">Remarquez que dans cet exemple, Mercurial affiche le
   1.142 +        nom des fichiers qu'il a ajouté, alors qu'il ne l'a pas fait lorsque
   1.143 +        nous avons ajouté le fichier nommé <filename>myfile.txt</filename>
   1.144 +        dans l'exemple précédent.</para>
   1.145 +
   1.146 +      <para id="x_1a9">Ce qu'il se passe est que dans le premier cas, nous
   1.147 +        avons nommé explicitement le fichier à ajouter sur la ligne de
   1.148 +        commande. La supposition que Mercurial fait dans ces cas est que nous
   1.149 +        savons ce que nous faisons, il n'affiche dont rien en sortie.</para>
   1.150 +
   1.151 +      <para id="x_1aa">Cependant, lorsque nous avons
   1.152 +        <emphasis>implicitement</emphasis> donné les fichiers à l'aide du nom
   1.153 +        d'un répertoire, Mercurial prend le l'initiative d'afficher le nom de
   1.154 +        chaque fichier avec lequel il fait quelque chose. Ceci clarifie ce
   1.155 +        qu'il se passe, et réduit la probabilité d'une surprise silencieuse
   1.156 +        et désagréable. Ce comportement est commun à la plupart des commandes
   1.157 +        Mercurial.</para>
   1.158 +    </sect2>
   1.159 +    <sect2>
   1.160 +      <title>Mercurial suit les fichiers, pas les répertoires</title>
   1.161 +
   1.162 +      <para id="x_1ab">Mercurial ne suit pas les informations sur les
   1.163 +        répertoire. En contrepartie, il suit le chemin vers un fichier. Avant
   1.164 +        de créer un fichier, il crée au préalable les répertoires manquants
   1.165 +        dans le chemin. Après avoir supprimé un fichier, il supprime chaque
   1.166 +        répertoire vide qui apparaît dans le chemin du fichier. Ceci apparaît
   1.167 +        comme une distinction triviale, cependant, ceci a une conséquence
   1.168 +        pratique mineure : il n'est pas possible de représenter un répertoire
   1.169 +        totalement vide dans Mercurial.</para>
   1.170 +
   1.171 +      <para id="x_1ac">Les répertoires vides sont rarement utiles. Il existe
   1.172 +        des solutions alternatives et non intrusives que vous pouvez utiliser
   1.173 +        pour obtenir l'effet approprié. Les développeurs de Mercurial ont
   1.174 +        ainsi pensé que la complexité requise pour gérer les répertoires
   1.175 +        n'était pas aussi importante que le bénéfice que cette fonctionnalité
   1.176 +        apporterait.</para>
   1.177 +
   1.178 +      <para id="x_1ad">Si vous avez besoin d'un répertoire vide dans votre
   1.179 +        dépôt, il existe quelques façons d'y arriver. L'une d'elles est de
   1.180 +        créer un répertoire et d'ensuite, faire un <command role="hg-cmd">hg
   1.181 +          add</command> sur un fichier <quote>hidden</quote> file dans ce
   1.182 +        répertoire. Sur les fichiers de type Unix, tout fichier dont le nom
   1.183 +        commence avec un point (<quote><literal>.</literal></quote>) est
   1.184 +        considéré comme caché par la plupart des commandes et outils
   1.185 +        graphiques. Cette approche est illustré ci-après.</para>
   1.186 +      
   1.187 +      &interaction.daily.files.hidden;
   1.188 +
   1.189 +      <para id="x_1ae">Une autre façon de s'attaquer au besoin d'un
   1.190 +        répertoire vide est de simplement en créer un dans vos scripts
   1.191 +        de construction avant qu'ils n'en aient le besoin.</para>
   1.192      </sect2>
   1.193    </sect1>
   1.194  
   1.195    <sect1>
   1.196 -    <title>How to stop tracking a file</title>
   1.197 -
   1.198 -    <para id="x_1af">Once you decide that a file no longer belongs in
   1.199 -      your repository, use the <command role="hg-cmd">hg
   1.200 -	remove</command> command. This deletes the file, and tells
   1.201 -      Mercurial to stop tracking it (which will occur at the next
   1.202 -      commit).  A removed file is represented in the output of
   1.203 -      <command role="hg-cmd">hg status</command> with a
   1.204 +    <title>Comment arrêter de suivre un fichier</title>
   1.205 +
   1.206 +    <para id="x_1af">Une fois que vous décidez qu'un fichier n'appartient
   1.207 +      plus à votre dépôt, utilisez la commande <command role="hg-cmd">hg
   1.208 +        remove</command>. Ceci supprime le fichier et informe Mercurial
   1.209 +      d'arrêter de le suivre (ce qui prendra effet lors du prochain commit).
   1.210 +      Un fichier supprimé est représenté dans la sortie de la commande
   1.211 +      <command role="hg-cmd">hg status</command> par un
   1.212        <quote><literal>R</literal></quote>.</para>
   1.213  
   1.214      &interaction.daily.files.remove;
   1.215  
   1.216 -    <para id="x_1b0">After you <command role="hg-cmd">hg remove</command> a file,
   1.217 -      Mercurial will no longer track changes to that file, even if you
   1.218 -      recreate a file with the same name in your working directory.
   1.219 -      If you do recreate a file with the same name and want Mercurial
   1.220 -      to track the new file, simply <command role="hg-cmd">hg
   1.221 -	add</command> it. Mercurial will know that the newly added
   1.222 -      file is not related to the old file of the same name.</para>
   1.223 -
   1.224 -    <sect2>
   1.225 -      <title>Removing a file does not affect its history</title>
   1.226 -
   1.227 -      <para id="x_1b1">It is important to understand that removing a file has
   1.228 -	only two effects.</para>
   1.229 +    <para id="x_1b0">Après avoir fait un <command role="hg-cmd">hg
   1.230 +        remove</command> sur un fichier, Mercurial ne suivra plus aucun
   1.231 +      changement sur ce fichier, même si vous recréez un fichier avec le même
   1.232 +      nom dans le répertoire de travail. Si vous recréez un fichier avec le
   1.233 +      même nom et que vous désirez que Mercurial suive ce dernier, faite
   1.234 +      simplement un <command role="hg-cmd">hg add</command> sur celui-ci.
   1.235 +      Mercurial saura alors que le nouveau fichier ne fait pas référence à
   1.236 +      l'ancien fichier qui portait le même nom.</para>
   1.237 +
   1.238 +    <sect2>
   1.239 +      <title>Supprimer un fichier n'affecte pas son historique</title>
   1.240 +
   1.241 +      <para id="x_1b1">Il est important de comprendre que supprmer un fichier
   1.242 +        n'a que deux effets.</para>
   1.243 +
   1.244        <itemizedlist>
   1.245 -	<listitem><para id="x_1b2">It removes the current version of the file
   1.246 -	    from the working directory.</para>
   1.247 -	</listitem>
   1.248 -	<listitem><para id="x_1b3">It stops Mercurial from tracking changes to
   1.249 -	    the file, from the time of the next commit.</para>
   1.250 -	</listitem></itemizedlist>
   1.251 -      <para id="x_1b4">Removing a file <emphasis>does not</emphasis> in any way
   1.252 -	alter the <emphasis>history</emphasis> of the file.</para>
   1.253 -
   1.254 -      <para id="x_1b5">If you update the working directory to a
   1.255 -	changeset that was committed when it was still tracking a file
   1.256 -	that you later removed, the file will reappear in the working
   1.257 -	directory, with the contents it had when you committed that
   1.258 -	changeset.  If you then update the working directory to a
   1.259 -	later changeset, in which the file had been removed, Mercurial
   1.260 -	will once again remove the file from the working
   1.261 -	directory.</para>
   1.262 -    </sect2>
   1.263 -
   1.264 -    <sect2>
   1.265 -      <title>Missing files</title>
   1.266 -
   1.267 -      <para id="x_1b6">Mercurial considers a file that you have deleted, but not
   1.268 -	used <command role="hg-cmd">hg remove</command> to delete, to
   1.269 -	be <emphasis>missing</emphasis>.  A missing file is
   1.270 -	represented with <quote><literal>!</literal></quote> in the
   1.271 -	output of <command role="hg-cmd">hg status</command>.
   1.272 -	Mercurial commands will not generally do anything with missing
   1.273 -	files.</para>
   1.274 +        <listitem><para id="x_1b2">Il supprime la version actuelle de ce
   1.275 +            fichier du répertoire de travail.</para>
   1.276 +        </listitem>
   1.277 +        <listitem><para id="x_1b3">Il arrête, à partir du prochain commit, le
   1.278 +            suivi de Mercurial sur les changements qui ont lieu sur ce
   1.279 +            fichier.</para>
   1.280 +        </listitem></itemizedlist>
   1.281 +        
   1.282 +      <para id="x_1b4">Supprimer un fichier <emphasis>n'</emphasis>affecte en
   1.283 +        <emphasis>aucun</emphasis> cas l'<emphasis>historique</emphasis> du
   1.284 +        fichier.</para>
   1.285 +
   1.286 +      <para id="x_1b5">Si vous mettez à jour le répertoire de travail à un
   1.287 +        changeset qui a été commité alors que le fichier que vous venez de
   1.288 +        supprimer était encore suivi, ce fichier réaparaittra dans le
   1.289 +        répertoire de travail, avec le contenu qu'il avait lorsque vous aviez
   1.290 +        commité ce changeset. Si vous mettez à jour (update) le répertoire de
   1.291 +        travail à un changeset ultérieur, dans lequel le fichier a été
   1.292 +        supprimé, Mercurial supprimera une nouvelle fois le fichier du
   1.293 +        répertoire de travail.</para>
   1.294 +    </sect2>
   1.295 +
   1.296 +    <sect2>
   1.297 +      <title>Fichier manquants</title>
   1.298 +
   1.299 +      <para id="x_1b6">Mercurial considère qu'un fichier que vous avez
   1.300 +        supprimé sans utiliser<command role="hg-cmd">hg remove</command>
   1.301 +        comme étant <emphasis>manquant</emphasis>.  Un fichier manquant est
   1.302 +        représenté avec un <quote><literal>!</literal></quote> en sortie de
   1.303 +        <command role="hg-cmd">hg status</command>.
   1.304 +        Les commandes Mercurial ne feront rien avec les fichiers
   1.305 +        manquants.</para>
   1.306  
   1.307        &interaction.daily.files.missing;
   1.308  
   1.309 -      <para id="x_1b7">If your repository contains a file that <command
   1.310 -	  role="hg-cmd">hg status</command> reports as missing, and
   1.311 -	you want the file to stay gone, you can run <command
   1.312 -	  role="hg-cmd">hg remove <option
   1.313 -	    role="hg-opt-remove">--after</option></command> at any
   1.314 -	time later on, to tell Mercurial that you really did mean to
   1.315 -	remove the file.</para>
   1.316 +      <para id="x_1b7">Si votre dépôt contient un fichier que <command
   1.317 +          role="hg-cmd">hg status</command> repporte comme manquant, et que
   1.318 +        vous voulez que ce fichier reste supprimé, vous pouvez exécuter
   1.319 +        <command role="hg-cmd">hg remove <option
   1.320 +            role="hg-opt-remove">--after</option></command> à tout moment
   1.321 +        pour dire à Mercurial que vous aviez bien voulu supprimer ce
   1.322 +        fichier.</para>
   1.323  
   1.324        &interaction.daily.files.remove-after;
   1.325  
   1.326 -      <para id="x_1b8">On the other hand, if you deleted the missing file by
   1.327 -	accident, give <command role="hg-cmd">hg revert</command> the
   1.328 -	name of the file to recover.  It will reappear, in unmodified
   1.329 -	form.</para>
   1.330 +      <para id="x_1b8">D'un autre coté, si vous avez supprimé le fichier
   1.331 +        manquant par accident, donnez à la commande <command role="hg-cmd">hg
   1.332 +          revert</command> le nom du fichier à retrouver. Il réaparaitra dans
   1.333 +        sa forme non modifiée.</para>
   1.334  
   1.335        &interaction.daily.files.recover-missing;
   1.336 -    </sect2>
   1.337 -
   1.338 -    <sect2>
   1.339 -      <title>Aside: why tell Mercurial explicitly to remove a
   1.340 -	file?</title>
   1.341 -
   1.342 -      <para id="x_1b9">You might wonder why Mercurial requires you to explicitly
   1.343 -	tell it that you are deleting a file.  Early during the
   1.344 -	development of Mercurial, it let you delete a file however you
   1.345 -	pleased; Mercurial would notice the absence of the file
   1.346 -	automatically when you next ran a <command role="hg-cmd">hg
   1.347 -	  commit</command>, and stop tracking the file.  In practice,
   1.348 -	this made it too easy to accidentally remove a file without
   1.349 -	noticing.</para>
   1.350 -    </sect2>
   1.351 -
   1.352 -    <sect2>
   1.353 -      <title>Useful shorthand&emdash;adding and removing files in one
   1.354 -	step</title>
   1.355 -
   1.356 -      <para id="x_1ba">Mercurial offers a combination command, <command
   1.357 -	  role="hg-cmd">hg addremove</command>, that adds untracked
   1.358 -	files and marks missing files as removed.</para>
   1.359 +    
   1.360 +    </sect2>
   1.361 +
   1.362 +    <sect2>
   1.363 +      <title>Entre nous : Pourquoi dire explicitement à Mercurial de supprimer un
   1.364 +      fichier ?</title>
   1.365 +
   1.366 +      <para id="x_1b9">Vous pourriez vous demander pourquoi il est nécessaire
   1.367 +        de dire exprécement à Mercurial que vous souhaitez supprimer un
   1.368 +        fichier. Au début du développement de Mercurial, celui ci vous
   1.369 +        laissait pourtant supprimer un fichier sans soucis ; Mercurial vous
   1.370 +        aurait automatiquement informé de l'absence du fichier lorsque vous
   1.371 +        auriez lancé un <command role="hg-cmd">hg commit</command> et arrêté
   1.372 +        de le suivre. En pratique, ceci a montré qu'il était trop facile de
   1.373 +        supprimer accidentellement un fichier sans le remarquer.</para>
   1.374 +    </sect2>
   1.375 +
   1.376 +    <sect2>
   1.377 +      <title>Racourcis utile&emdash;ajouter et supprimer des fichiers en une
   1.378 +      seule étape.</title>
   1.379 +
   1.380 +      <para id="x_1ba">Mercurial offre une commande combinée, <command
   1.381 +          role="hg-cmd">hg addremove</command>, qui ajoute les fichiers non
   1.382 +        suivis et marque les fichiers manquants comme supprimés.</para>
   1.383  
   1.384        &interaction.daily.files.addremove;
   1.385  
   1.386 -      <para id="x_1bb">The <command role="hg-cmd">hg commit</command> command
   1.387 -	also provides a <option role="hg-opt-commit">-A</option>
   1.388 -	option that performs this same add-and-remove, immediately
   1.389 -	followed by a commit.</para>
   1.390 +      <para id="x_1bb">La commande <command role="hg-cmd">hg commit</command>
   1.391 +        fournit aussi une option <option role="hg-opt-commit">-A</option> qui
   1.392 +        exécute le même ajouter-et-supprimer, immédiatement suivi d'un
   1.393 +        commit.</para>
   1.394  
   1.395        &interaction.daily.files.commit-addremove;
   1.396 +    
   1.397      </sect2>
   1.398    </sect1>
   1.399  
   1.400    <sect1 id="chap:daily.copy">
   1.401 -    <title>Copying files</title>
   1.402 -
   1.403 -    <para id="x_1bc">Mercurial provides a <command role="hg-cmd">hg
   1.404 -	copy</command> command that lets you make a new copy of a
   1.405 -      file.  When you copy a file using this command, Mercurial makes
   1.406 -      a record of the fact that the new file is a copy of the original
   1.407 -      file.  It treats these copied files specially when you merge
   1.408 -      your work with someone else's.</para>
   1.409 -
   1.410 -    <sect2>
   1.411 -      <title>The results of copying during a merge</title>
   1.412 -
   1.413 -      <para id="x_1bd">What happens during a merge is that changes
   1.414 -	<quote>follow</quote> a copy.  To best illustrate what this
   1.415 -	means, let's create an example.  We'll start with the usual
   1.416 -	tiny repository that contains a single file.</para>
   1.417 +    <title>Copier des fichiers</title>
   1.418 +
   1.419 +    <para id="x_1bc">Mercurial fournit une commande <command role="hg-cmd">hg
   1.420 +        copy</command> qui vous permet de faire une nouvelle copie d'un
   1.421 +      fichier. Lorsque vous copiez un fichier en utilisant cette commande,
   1.422 +      Mercurial crée un enregistrement du fait que ce nouveau fichier est une
   1.423 +      copie du fichier originel. Il traite ces fichiers copiés spécialement
   1.424 +      lorsque vous faites une fusion (merge) de votre travail avec quelqu'un
   1.425 +      d'autre.</para>
   1.426 +
   1.427 +    <sect2>
   1.428 +      <title>Les résultat d'une copie durant une fusion (merge)</title>
   1.429 +
   1.430 +      <para id="x_1bd">Ce qu'il se passe durant une fusion (merge) est que
   1.431 +        les changements <quote>suivent</quote> une copie. Pour illustrer ce
   1.432 +        que ça veut dire de la meilleure façon, créons un exemple. Nous
   1.433 +        allons commencer avec le mini dépôt usuel qui contient un simple
   1.434 +        fichier.</para>
   1.435  
   1.436        &interaction.daily.copy.init;
   1.437  
   1.438 -      <para id="x_1be">We need to do some work in
   1.439 -	parallel, so that we'll have something to merge.  So let's
   1.440 -	clone our repository.</para>
   1.441 +      <para id="x_1be">Nous devons faire du travail en parallèle, ainsi,
   1.442 +        nous aurons quelque chose à fusionner (merge). Donc clonons notre
   1.443 +        dépôt.</para>
   1.444  
   1.445        &interaction.daily.copy.clone;
   1.446  
   1.447 -      <para id="x_1bf">Back in our initial repository, let's use the <command
   1.448 -	  role="hg-cmd">hg copy</command> command to make a copy of
   1.449 -	the first file we created.</para>
   1.450 +      <para id="x_1bf">De retour dans notre dépôt initial, utilisons la
   1.451 +        commande <command role="hg-cmd">hg copy</command> pour faire une
   1.452 +        copie du premier fichier que nous avons créé.</para>
   1.453  
   1.454        &interaction.daily.copy.copy;
   1.455  
   1.456 -      <para id="x_1c0">If we look at the output of the <command role="hg-cmd">hg
   1.457 -	  status</command> command afterwards, the copied file looks
   1.458 -	just like a normal added file.</para>
   1.459 +      <para id="x_1c0">Si nous regardons ensuite à la sortie de la commande
   1.460 +        <command role="hg-cmd">hg status</command>, les fichiers copiés
   1.461 +        ont l'air de fichiers normalement ajoutés.</para>
   1.462  
   1.463        &interaction.daily.copy.status;
   1.464  
   1.465 -      <para id="x_1c1">But if we pass the <option
   1.466 -	  role="hg-opt-status">-C</option> option to <command
   1.467 -	  role="hg-cmd">hg status</command>, it prints another line of
   1.468 -	output: this is the file that our newly-added file was copied
   1.469 -	<emphasis>from</emphasis>.</para>
   1.470 +      <para id="x_1c1">Mais si nous passons l'option <option
   1.471 +          role="hg-opt-status">-C</option> à <command role="hg-cmd">hg
   1.472 +          status</command>, il affiche une autre ligne de sortie : il s'agit
   1.473 +        du fichier <emphasis>source</emphasis> pour notre copie.</para>
   1.474  
   1.475        &interaction.daily.copy.status-copy;
   1.476  
   1.477 -      <para id="x_1c2">Now, back in the repository we cloned, let's make a change
   1.478 -	in parallel.  We'll add a line of content to the original file
   1.479 -	that we created.</para>
   1.480 +      <para id="x_1c2">Maintenant, de retour dans le dépôt que nous avons
   1.481 +        cloné, et créons un changement en parallèle. Nous allons ajouter une
   1.482 +        ligne de contenu au fichier original qui a été créé.</para>
   1.483  
   1.484        &interaction.daily.copy.other;
   1.485  
   1.486 -      <para id="x_1c3">Now we have a modified <filename>file</filename> in this
   1.487 -	repository.  When we pull the changes from the first
   1.488 -	repository, and merge the two heads, Mercurial will propagate
   1.489 -	the changes that we made locally to <filename>file</filename>
   1.490 -	into its copy, <filename>new-file</filename>.</para>
   1.491 +      <para id="x_1c3">Maintenant, nous avons un fichier
   1.492 +        <filename>file</filename> modifié dans ce dépôt. Lorsque nous
   1.493 +        récupérons (pull) les changements depuis le premier répertoire et
   1.494 +        fusionnons (merge) les deux HEADS, Mercurial propagera les
   1.495 +        changements que nous avons fait localement au fichier
   1.496 +        <filename>file</filename> dans sa copie
   1.497 +        <filename>new-file</filename>.</para>
   1.498  
   1.499        &interaction.daily.copy.merge;
   1.500 -    </sect2>
   1.501 -
   1.502 +    
   1.503 +    </sect2>
   1.504      <sect2 id="sec:daily:why-copy">
   1.505 -      <title>Why should changes follow copies?</title>
   1.506 -
   1.507 -      <para id="x_1c4">This behavior&emdash;of changes to a file
   1.508 -	propagating out to copies of the file&emdash;might seem
   1.509 -	esoteric, but in most cases it's highly desirable.</para>
   1.510 -
   1.511 -      <para id="x_1c5">First of all, remember that this propagation
   1.512 -	<emphasis>only</emphasis> happens when you merge.  So if you
   1.513 -	<command role="hg-cmd">hg copy</command> a file, and
   1.514 -	subsequently modify the original file during the normal course
   1.515 -	of your work, nothing will happen.</para>
   1.516 -
   1.517 -      <para id="x_1c6">The second thing to know is that modifications will only
   1.518 -	propagate across a copy as long as the changeset that you're
   1.519 -	merging changes from <emphasis>hasn't yet seen</emphasis> 
   1.520 -	the copy.</para>
   1.521 -
   1.522 -      <para id="x_1c7">The reason that Mercurial does this is as follows.  Let's
   1.523 -	say I make an important bug fix in a source file, and commit
   1.524 -	my changes. Meanwhile, you've decided to <command
   1.525 -	  role="hg-cmd">hg copy</command> the file in your repository,
   1.526 -	without knowing about the bug or having seen the fix, and you
   1.527 -	have started hacking on your copy of the file.</para>
   1.528 -
   1.529 -      <para id="x_1c8">If you pulled and merged my changes, and Mercurial
   1.530 -	<emphasis>didn't</emphasis> propagate changes across copies,
   1.531 -	your new source file would now contain the bug, and unless you
   1.532 -	knew to propagate the bug fix by hand, the bug would
   1.533 -	<emphasis>remain</emphasis> in your copy of the file.</para>
   1.534 -
   1.535 -      <para id="x_1c9">By automatically propagating the change that fixed the bug
   1.536 -	from the original file to the copy, Mercurial prevents this
   1.537 -	class of problem. To my knowledge, Mercurial is the
   1.538 -	<emphasis>only</emphasis> revision control system that
   1.539 -	propagates changes across copies like this.</para>
   1.540 -
   1.541 -      <para id="x_1ca">Once your change history has a record that the copy and
   1.542 -	subsequent merge occurred, there's usually no further need to
   1.543 -	propagate changes from the original file to the copied file,
   1.544 -	and that's why Mercurial only propagates changes across copies
   1.545 -	at the first merge, and not afterwards.</para>
   1.546 -    </sect2>
   1.547 -
   1.548 -    <sect2>
   1.549 -      <title>How to make changes <emphasis>not</emphasis> follow a
   1.550 -	copy</title>
   1.551 -
   1.552 -      <para id="x_1cb">If, for some reason, you decide that this business of
   1.553 -	automatically propagating changes across copies is not for
   1.554 -	you, simply use your system's normal file copy command (on
   1.555 -	Unix-like systems, that's <command>cp</command>) to make a
   1.556 -	copy of a file, then <command role="hg-cmd">hg add</command>
   1.557 -	the new copy by hand.  Before you do so, though, please do
   1.558 -	reread <xref linkend="sec:daily:why-copy"/>, and make
   1.559 -	an informed
   1.560 -	decision that this behavior is not appropriate to your
   1.561 -	specific case.</para>
   1.562 -
   1.563 -    </sect2>
   1.564 -    <sect2>
   1.565 -      <title>Behavior of the <command role="hg-cmd">hg copy</command>
   1.566 -	command</title>
   1.567 -
   1.568 -      <para id="x_1cc">When you use the <command role="hg-cmd">hg copy</command>
   1.569 -	command, Mercurial makes a copy of each source file as it
   1.570 -	currently stands in the working directory.  This means that if
   1.571 -	you make some modifications to a file, then <command
   1.572 -	  role="hg-cmd">hg copy</command> it without first having
   1.573 -	committed those changes, the new copy will also contain the
   1.574 -	modifications you have made up until that point.  (I find this
   1.575 -	behavior a little counterintuitive, which is why I mention it
   1.576 -	here.)</para>
   1.577 -
   1.578 -      <para id="x_1cd">The <command role="hg-cmd">hg copy</command>
   1.579 -	command acts similarly to the Unix <command>cp</command>
   1.580 -	command (you can use the <command role="hg-cmd">hg
   1.581 -	  cp</command> alias if you prefer).  We must supply two or
   1.582 -	more arguments, of which the last is treated as the
   1.583 -	<emphasis>destination</emphasis>, and all others are
   1.584 -	<emphasis>sources</emphasis>.</para>
   1.585 -
   1.586 -      <para id="x_685">If you pass <command role="hg-cmd">hg copy</command> a
   1.587 -	single file as the source, and the destination does not exist,
   1.588 -	it creates a new file with that name.</para>
   1.589 +      <title>Pourquoi les changements devraient suivre les copies ?</title>
   1.590 +
   1.591 +      <para id="x_1c4">Ce comportement&emdash;des changements d'un fichiers
   1.592 +        qui se propagent aux copies de ce fichier&emdash;peut sembler
   1.593 +        ésotérique, mais, dans la plupart des cas, c'est hautement
   1.594 +        désirable.</para>
   1.595 +
   1.596 +      <para id="x_1c5">Pour commencer, souvenez vous que cette propagation
   1.597 +        a lieue <emphasis>seulement</emphasis> lors des fusions (merge).
   1.598 +        Donc, si vous faites un	<command role="hg-cmd">hg copy</command> sur
   1.599 +        un fichier, et par la suite modifiez le fichier original durant le
   1.600 +        cours normal de votre travail, rien n'a lieu.</para>
   1.601 +
   1.602 +      <para id="x_1c6">La deuxième chose à savoir c'est que les modifications
   1.603 +        ne se propageront à travers une copie que si le changeset à partir
   1.604 +        duquel vous faites une fusion (merge) <emphasis>n'a pas encore
   1.605 +          vu</emphasis> la copie.</para>
   1.606 +          
   1.607 +      <para id="x_1c7">La raison pour laquelle Mercurial fait ainsi est une
   1.608 +        règle. Disons que je corrige un important bug dans un fichier source
   1.609 +        et commit mes changements. Pendant ce temps, vous avez décidé de
   1.610 +        faire un <command role="hg-cmd">hg copy</command> du fichier dans
   1.611 +        votre dépôt, sans rien savoir au sujet du bug ou sans avoir rien vu à
   1.612 +        propos de la correction, et vous avez commencé à "hacker" sur votre
   1.613 +        copie du fichier.</para>
   1.614 +
   1.615 +      <para id="x_1c8">Si vous aviez récupéré (pull) et fusionné (merge) mes
   1.616 +        changements, et que Mercurial <emphasis>n'avait pas</emphasis>
   1.617 +        propagé les changements à travers les copies, votre nouveau fichier
   1.618 +        source contiendrait maintenant le bug, et à moins que vous sachiez
   1.619 +        qu'il faille propager la correction du bug à la main, le bug aurait
   1.620 +        <emphasis>subsisté</emphasis> dans votre copie du fichier.</para>
   1.621 +
   1.622 +      <para id="x_1c9">En propageant automatiquement les changements qui
   1.623 +        fixent les bugs à partir du fichier original vers les copies,
   1.624 +        Mercurial prévient ce type de problèmes. A ma connaissance, Mercurial
   1.625 +        est le <emphasis>seul</emphasis> système de gestion de révisions qui
   1.626 +        propage les changements à travers les copies comme ceci.</para>
   1.627 +
   1.628 +      <para id="x_1ca">Une fois que votre historique des changements a un
   1.629 +        enregistrement concernant une copie et une fusion postérieure qui a
   1.630 +        eu lieue, il n'y a d'habitude pas d'autre besoin de propager les
   1.631 +        changements du fichier originel vers le fichier copié, et c'est
   1.632 +        pourquoi Mercurial ne propage les changements à travers les copies
   1.633 +        seulement à la première fusion, et pas d'avantage.</para>
   1.634 +    </sect2>
   1.635 +
   1.636 +    <sect2>
   1.637 +      <title>Comment faire des changements qui <emphasis>ne</emphasis>
   1.638 +      suivent <emphasis>pas</emphasis> une copie</title>
   1.639 +
   1.640 +      <para id="x_1cb">Si pour une raison ou une autre, vous décidez que
   1.641 +        cette fonctionnalité de propager automatiquement les changements à
   1.642 +        travers les copies n'est pas pour vous, utilisez simplement la
   1.643 +        commande normale de copie de votre système (sur les systèmes de type
   1.644 +        Unix, il s'agit de <command>cp</command>) pour faire une copie d'un
   1.645 +        fichier. Utilisez ensuite <command role="hg-cmd">hg add</command>
   1.646 +        pour ajouter les nouveaux fichiers à la main. Cependant, avant d'en
   1.647 +        faire ainsi, relisez <xref linkend="sec:daily:why-copy"/>, et faites
   1.648 +        un choix en tout état de cause que cette fonctionnalité n'est pas
   1.649 +        appropriée à votre cas spécifique.</para>
   1.650 +
   1.651 +    </sect2>
   1.652 +    <sect2>
   1.653 +      <title>Comportement de la commande <command role="hg-cmd">hg copy</command></title>
   1.654 +
   1.655 +      <para id="x_1cc">Lorsque vous utilisez la commande <command
   1.656 +          role="hg-cmd">hg copy</command>, Mercurial crée une copie de chaque
   1.657 +        fichier source tel qu'il est actuellement dans le répertoire de
   1.658 +        travail. Cela signifie que si vous faites des modifications à un
   1.659 +        fichier, puis faites un <command role="hg-cmd">hg copy</command> sur
   1.660 +        celui-ci sans avoir au préalable commité ces changements, la nouvelle
   1.661 +        copie contiendra aussi les modifications que vous avez fait jusqu'à
   1.662 +        ce point.	modifications you have made up until that point.  (Je
   1.663 +        trouve ce comportement quelque peu contre intuitif, c'est pourquoi
   1.664 +        j'en fais mention ici.)</para>
   1.665 +
   1.666 +      <para id="x_1cd">La commande <command role="hg-cmd">hg copy</command>
   1.667 +        agit comme la commande Unix <command>cp</command> (vous pouvez
   1.668 +        utilisez l'alias <command role="hg-cmd">hg cp</command> si vous
   1.669 +        préférez).  Nous devons lui donner deux ou plus arguments où le
   1.670 +        dernier est considéré comme la <emphasis>destination</emphasis>, et
   1.671 +        les autres comme les <emphasis>sources</emphasis>.</para>
   1.672 +
   1.673 +      <para id="x_685">Si vous passez à <command role="hg-cmd">hg
   1.674 +          copy</command> un seul fichier source, et que la destination
   1.675 +        n'existe pas, ceci créera un nouveau fichier avec ce nom.</para>
   1.676  
   1.677        &interaction.daily.copy.simple;
   1.678 -      
   1.679 -      <para id="x_1ce">If the destination is a directory, Mercurial copies its
   1.680 -	sources into that directory.</para>
   1.681 +
   1.682 +      <para id="x_1ce">Si la destination est un répertoire, Mercurial copie
   1.683 +        les sources dans ce répertoire.</para>
   1.684  
   1.685        &interaction.daily.copy.dir-dest;
   1.686  
   1.687 -      <para id="x_1cf">Copying a directory is
   1.688 -	recursive, and preserves the directory structure of the
   1.689 -	source.</para>
   1.690 +      <para id="x_1cf">La copie de répertoire est récursive et préserve la
   1.691 +        structure du répertoire source.</para>
   1.692  
   1.693        &interaction.daily.copy.dir-src;
   1.694  
   1.695 -      <para id="x_1d0">If the source and destination are both directories, the
   1.696 -	source tree is recreated in the destination directory.</para>
   1.697 -
   1.698 -	&interaction.daily.copy.dir-src-dest;
   1.699 -
   1.700 -      <para id="x_1d1">As with the <command role="hg-cmd">hg remove</command>
   1.701 -	command, if you copy a file manually and then want Mercurial
   1.702 -	to know that you've copied the file, simply use the <option
   1.703 -	  role="hg-opt-copy">--after</option> option to <command
   1.704 -	  role="hg-cmd">hg copy</command>.</para>
   1.705 +      <para id="x_1d0">Si la source et la destination sont tous deux des
   1.706 +        répertoires, l'arborescence de la source est recrée dans le
   1.707 +        répertoire destination.</para>
   1.708 +    
   1.709 +      &interaction.daily.copy.dir-src-dest;
   1.710 +
   1.711 +      <para id="x_1d1">Comme avec la commande <command role="hg-cmd">hg
   1.712 +          remove</command>, si vous copiez un fichier manuellement et voulez
   1.713 +        que Mercurial sache qu'il s'agit d'une copie, utilisez simplement
   1.714 +        l'option <option role="hg-opt-copy">--after</option> avec <command
   1.715 +          role="hg-cmd">hg copy</command>.</para>
   1.716  
   1.717        &interaction.daily.copy.after;
   1.718      </sect2>
   1.719    </sect1>
   1.720  
   1.721    <sect1>
   1.722 -    <title>Renaming files</title>
   1.723 -
   1.724 -    <para id="x_1d2">It's rather more common to need to rename a file than to
   1.725 -      make a copy of it.  The reason I discussed the <command
   1.726 -	role="hg-cmd">hg copy</command> command before talking about
   1.727 -      renaming files is that Mercurial treats a rename in essentially
   1.728 -      the same way as a copy.  Therefore, knowing what Mercurial does
   1.729 -      when you copy a file tells you what to expect when you rename a
   1.730 -      file.</para>
   1.731 -
   1.732 -    <para id="x_1d3">When you use the <command role="hg-cmd">hg rename</command>
   1.733 -      command, Mercurial makes a copy of each source file, then
   1.734 -      deletes it and marks the file as removed.</para>
   1.735 -
   1.736 -      &interaction.daily.rename.rename;
   1.737 -
   1.738 -    <para id="x_1d4">The <command role="hg-cmd">hg status</command> command shows
   1.739 -      the newly copied file as added, and the copied-from file as
   1.740 -      removed.</para>
   1.741 +    <title>Renommer les fichiers</title>
   1.742 +
   1.743 +    <para id="x_1d2">Il est plus commun d'avoir besoin de renommer un
   1.744 +      fichier que d'en faire une copie. La raison pour laquelle j'ai discuté
   1.745 +      de la commande <command role="hg-cmd">hg copy</command> avant de parler
   1.746 +      de renommage des fichiers est que Mercurial traite les renommages
   1.747 +      essenciellement comme une copie. Ainsi, savoir comment Mercurial traite
   1.748 +      les copies de fichiers vous informe sur ce que vous êtes en droit
   1.749 +      d'attendre lorsque vous renommez un fichier.</para>
   1.750 +
   1.751 +    <para id="x_1d3">Lorsque vous utilisez la commande <command
   1.752 +        role="hg-cmd">hg rename</command>, Mercurial crée uen copie de chaque
   1.753 +      fichier source, les supprime et marque ces fichiers comme étant
   1.754 +      supprimés.</para>
   1.755 +
   1.756 +    &interaction.daily.rename.rename;
   1.757 +
   1.758 +    <para id="x_1d4">La commande <command role="hg-cmd">hg status</command>
   1.759 +      montre le nouveau fichier comme ajouté et le fichier origine comme
   1.760 +      supprimé.</para>
   1.761  
   1.762      &interaction.daily.rename.status;
   1.763  
   1.764 -    <para id="x_1d5">As with the results of a <command role="hg-cmd">hg
   1.765 -	copy</command>, we must use the <option
   1.766 -	role="hg-opt-status">-C</option> option to <command
   1.767 -	role="hg-cmd">hg status</command> to see that the added file
   1.768 -      is really being tracked by Mercurial as a copy of the original,
   1.769 -      now removed, file.</para>
   1.770 +    <para id="x_1d5">A cause du <command role="hg-cmd">hg	copy</command>,
   1.771 +      nous devons utiliser l'option <option role="hg-opt-status">-C</option>
   1.772 +      pour <command	role="hg-cmd">hg status</command> afin d'observer que le
   1.773 +      fichier ajouté est bien suivi par Mercurial comme étant une copie de
   1.774 +      l'original maintenant supprimé.</para>
   1.775  
   1.776      &interaction.daily.rename.status-copy;
   1.777  
   1.778 -    <para id="x_1d6">As with <command role="hg-cmd">hg remove</command> and
   1.779 -      <command role="hg-cmd">hg copy</command>, you can tell Mercurial
   1.780 -      about a rename after the fact using the <option
   1.781 -	role="hg-opt-rename">--after</option> option.  In most other
   1.782 -      respects, the behavior of the <command role="hg-cmd">hg
   1.783 -	rename</command> command, and the options it accepts, are
   1.784 -      similar to the <command role="hg-cmd">hg copy</command>
   1.785 -      command.</para>
   1.786 -
   1.787 -    <para id="x_686">If you're familiar with the Unix command line, you'll be
   1.788 -      glad to know that <command role="hg-cmd">hg rename</command>
   1.789 -      command can be invoked as <command role="hg-cmd">hg
   1.790 -	mv</command>.</para>
   1.791 -
   1.792 -    <sect2>
   1.793 -      <title>Renaming files and merging changes</title>
   1.794 -
   1.795 -      <para id="x_1d7">Since Mercurial's rename is implemented as
   1.796 -	copy-and-remove, the same propagation of changes happens when
   1.797 -	you merge after a rename as after a copy.</para>
   1.798 -
   1.799 -      <para id="x_1d8">If I modify a file, and you rename it to a new name, and
   1.800 -	then we merge our respective changes, my modifications to the
   1.801 -	file under its original name will be propagated into the file
   1.802 -	under its new name. (This is something you might expect to
   1.803 -	<quote>simply work,</quote> but not all revision control
   1.804 -	systems actually do this.)</para>
   1.805 -
   1.806 -      <para id="x_1d9">Whereas having changes follow a copy is a feature where
   1.807 -	you can perhaps nod and say <quote>yes, that might be
   1.808 -	  useful,</quote> it should be clear that having them follow a
   1.809 -	rename is definitely important.  Without this facility, it
   1.810 -	would simply be too easy for changes to become orphaned when
   1.811 -	files are renamed.</para>
   1.812 -    </sect2>
   1.813 -
   1.814 -    <sect2>
   1.815 -      <title>Divergent renames and merging</title>
   1.816 -
   1.817 -      <para id="x_1da">The case of diverging names occurs when two developers
   1.818 -	start with a file&emdash;let's call it
   1.819 -	<filename>foo</filename>&emdash;in their respective
   1.820 -	repositories.</para>
   1.821 +    <para id="x_1d6">Comme avec <command role="hg-cmd">hg remove</command> et
   1.822 +      <command role="hg-cmd">hg copy</command>, vous pouvez informer
   1.823 +      Mercurial à propos d'un renommage après coup en utilisant l'option
   1.824 +      <option role="hg-opt-rename">--after</option>. Dans le plus grand
   1.825 +      respet, le comportement de la commande <command role="hg-cmd">hg
   1.826 +        rename</command>, et les options qu'il accepte sont similaires à la
   1.827 +      commande <command role="hg-cmd">hg copy</command>.</para>
   1.828 +
   1.829 +    <para id="x_686">Si vous êtes familié avec la ligne de commande Unix,
   1.830 +      vous serez heureux d'apprendre que la commande <command
   1.831 +        role="hg-cmd">hg rename</command> peut être invoquée par <command
   1.832 +        role="hg-cmd">hg mv</command>.</para>
   1.833 +
   1.834 +    <sect2>
   1.835 +      <title>Renommer les fichiers et fusionner (merge) les changements</title>
   1.836 +
   1.837 +      <para id="x_1d7">Puise que le rename de Mercurial est implanté comme un
   1.838 +        "copy-and-remove", la même propagation des changements a lieue
   1.839 +        lorsque vous fusionnez (merge) après un "rename" qu'après un
   1.840 +        "copy".</para>
   1.841 +
   1.842 +      <para id="x_1d8">Si je modifie un fichier et que vous le renommez, si
   1.843 +        ensuite nous fusionnons nos changements respectifs, mes modifications
   1.844 +        sur le fichier sous son nom originel seront propagés vers le même
   1.845 +        fichier sous son nouveau nom. (C'est quelque chose que vous pourriez
   1.846 +        espérer voir <quote>fonctionner simplement</quote>, mais tous les
   1.847 +        systèmes de gestion de version ne le font pas.)</para>
   1.848 +
   1.849 +      <para id="x_1d9">Tandis qu'avoir des changements qui suivent une copie
   1.850 +        est une fonctionnalité où vous hocheriez sûrement la tête en disant
   1.851 +        <quote>oui, cela pourrait être utile</quote>, il est clair que les
   1.852 +        voir suivre un renommage est définitivement important. Sans cette
   1.853 +        aptitude, il serait simplement trop facile d'avoir des changements
   1.854 +        qui deviennent orphelins lorsque des fichiers sont renommés.</para>
   1.855 +    </sect2>
   1.856 +
   1.857 +    <sect2>
   1.858 +      <title>Renommages divergeants et fusion (merge)</title>
   1.859 +
   1.860 +      <para id="x_1da">Le cas de noms divergeants a lieu lorsque deux
   1.861 +        développeurs commencent avec un fichier&emdash;apprelons le
   1.862 +        <filename>foo</filename>&emdash;dans leurs dépôts respectifs.</para>
   1.863  
   1.864        &interaction.rename.divergent.clone;
   1.865  
   1.866 -      <para id="x_1db">Anne renames the file to <filename>bar</filename>.</para>
   1.867 +      <para id="x_1db">Anne renomme le fichier en
   1.868 +        <filename>bar</filename>.</para>
   1.869  
   1.870        &interaction.rename.divergent.rename.anne;
   1.871  
   1.872 -      <para id="x_1dc">Meanwhile, Bob renames it to
   1.873 -	<filename>quux</filename>. (Remember that <command
   1.874 -	  role="hg-cmd">hg mv</command> is an alias for <command
   1.875 -	  role="hg-cmd">hg rename</command>.)</para>
   1.876 -
   1.877 -	&interaction.rename.divergent.rename.bob;
   1.878 -
   1.879 -      <para id="x_1dd">I like to think of this as a conflict because each
   1.880 -	developer has expressed different intentions about what the
   1.881 -	file ought to be named.</para>
   1.882 -
   1.883 -      <para id="x_1de">What do you think should happen when they merge their
   1.884 -	work? Mercurial's actual behavior is that it always preserves
   1.885 -	<emphasis>both</emphasis> names when it merges changesets that
   1.886 -	contain divergent renames.</para>
   1.887 +      <para id="x_1dc">Pendant ce temps, Bob le renomme en
   1.888 +        <filename>quux</filename>. (Souvenez vous que <command
   1.889 +          role="hg-cmd">hg mv</command> est un alias pour <command
   1.890 +          role="hg-cmd">hg rename</command>.)</para>
   1.891 +    
   1.892 +      &interaction.rename.divergent.rename.bob;
   1.893 +
   1.894 +      <para id="x_1dd">J'aime à penser qu'il s'agit d'un conflit puisque
   1.895 +        chaque développeur a exprimé différentes intentions au sujet de ce
   1.896 +        que le nom de ce fichier aurait du être.</para>
   1.897 +
   1.898 +      <para id="x_1de">Que pensez vous qu'il devrait se produire lorsqu'ils
   1.899 +        fusionnent (merge) leurs travaux ? Le comportement actuel de
   1.900 +        Mercurial est qu'il préserve toujours les <emphasis>deux</emphasis>
   1.901 +        noms lorsqu'il fusionne (merge) des changesets qui contiennent des
   1.902 +        renommages divergeants.</para>
   1.903  
   1.904        &interaction.rename.divergent.merge;
   1.905  
   1.906 -      <para id="x_1df">Notice that while Mercurial warns about the divergent
   1.907 -	renames, it leaves it up to you to do something about the
   1.908 -	divergence after the merge.</para>
   1.909 -    </sect2>
   1.910 -
   1.911 -    <sect2>
   1.912 -      <title>Convergent renames and merging</title>
   1.913 -
   1.914 -      <para id="x_1e0">Another kind of rename conflict occurs when two people
   1.915 -	choose to rename different <emphasis>source</emphasis> files
   1.916 -	to the same <emphasis>destination</emphasis>. In this case,
   1.917 -	Mercurial runs its normal merge machinery, and lets you guide
   1.918 -	it to a suitable resolution.</para>
   1.919 -    </sect2>
   1.920 -
   1.921 -    <sect2>
   1.922 -      <title>Other name-related corner cases</title>
   1.923 -
   1.924 -      <para id="x_1e1">Mercurial has a longstanding bug in which it fails to
   1.925 -	handle a merge where one side has a file with a given name,
   1.926 -	while another has a directory with the same name.  This is
   1.927 -	documented as <ulink role="hg-bug"
   1.928 -	  url="http://www.selenic.com/mercurial/bts/issue29">issue
   1.929 -	  29</ulink>.</para>
   1.930 +      <para id="x_1df">Remarquez que bien que Mercurial vous avertisse au
   1.931 +        sujet de la divergeance des renommages, il vous laisse faire quelque
   1.932 +        chose au sujet de la divergeance après la fusion (merge).</para>
   1.933 +    </sect2>
   1.934 +
   1.935 +    <sect2>
   1.936 +      <title>Renommages et fusion convergeants</title>
   1.937 +
   1.938 +      <para id="x_1e0">Un autre type de conflit de renommage intervient
   1.939 +        lorsque deux personne choisissent de renommer différents fichiers
   1.940 +        <emphasis>source</emphasis> vers la même
   1.941 +        <emphasis>destination</emphasis>. Dans ce cas, Mercurial exécute la
   1.942 +        machinerie normale de fusion (merge) et vous guide vers une
   1.943 +        solution convenable.</para>
   1.944 +    </sect2>
   1.945 +
   1.946 +    <sect2>
   1.947 +      <title>Autres cas anguleux relatifs aux noms</title>
   1.948 +
   1.949 +      <para id="x_1e1">Mercurial possède un bug de longue date dans lequel il
   1.950 +        échoue à traiter une fusion (merge) où un coté a un fichier avec un
   1.951 +        nom donné, alors que l'autre coté a un répertoire avec le même nom.
   1.952 +        Ceci est documenté dans l'<ulink role="hg-bug"
   1.953 +          url="http://www.selenic.com/mercurial/bts/issue29">issue
   1.954 +          29</ulink>.</para>
   1.955  
   1.956        &interaction.issue29.go;
   1.957  
   1.958 @@ -521,98 +536,102 @@
   1.959    </sect1>
   1.960  
   1.961    <sect1>
   1.962 -    <title>Recovering from mistakes</title>
   1.963 -
   1.964 -    <para id="x_1e2">Mercurial has some useful commands that will help you to
   1.965 -      recover from some common mistakes.</para>
   1.966 -
   1.967 -    <para id="x_1e3">The <command role="hg-cmd">hg revert</command> command lets
   1.968 -      you undo changes that you have made to your working directory.
   1.969 -      For example, if you <command role="hg-cmd">hg add</command> a
   1.970 -      file by accident, just run <command role="hg-cmd">hg
   1.971 -	revert</command> with the name of the file you added, and
   1.972 -      while the file won't be touched in any way, it won't be tracked
   1.973 -      for adding by Mercurial any longer, either.  You can also use
   1.974 -      <command role="hg-cmd">hg revert</command> to get rid of
   1.975 -      erroneous changes to a file.</para>
   1.976 -
   1.977 -    <para id="x_1e4">It is helpful to remember that the <command
   1.978 -	role="hg-cmd">hg revert</command> command is useful for
   1.979 -      changes that you have not yet committed.  Once you've committed
   1.980 -      a change, if you decide it was a mistake, you can still do
   1.981 -      something about it, though your options may be more
   1.982 -      limited.</para>
   1.983 -
   1.984 -    <para id="x_1e5">For more information about the <command
   1.985 -	role="hg-cmd">hg revert</command> command, and details about
   1.986 -      how to deal with changes you have already committed, see <xref
   1.987 -	linkend="chap:undo"/>.</para>
   1.988 +    <title>Récupération d'erreurs</title>
   1.989 +
   1.990 +    <para id="x_1e2">Mercurial possède certaines commandes utiles qui vont
   1.991 +      vous aider à récupérer certaines erreurs communes.</para>
   1.992 +
   1.993 +    <para id="x_1e3">La commande <command role="hg-cmd">hg revert</command>
   1.994 +      vous permet d'annuler les changements que vous avez fait dans votre
   1.995 +      répertoire de travail. Par exemple, si vous faites un <command
   1.996 +        role="hg-cmd">hg add</command> sur un fichier par accident, exécutez
   1.997 +      juste <command role="hg-cmd">hg	revert</command> avec le nom du fichier
   1.998 +      que vous avez ajouté et tandis que le fichier ne touché d'une
   1.999 +      quelconque manière, il ne sera plus suivi comme ajouté par Mercurial.
  1.1000 +      Vous pouvez aussi utiliser la commande <command role="hg-cmd">hg
  1.1001 +        revert</command> pour vous débarasser de modifications erronés
  1.1002 +      apportées à un fichier.</para>
  1.1003 +
  1.1004 +    <para id="x_1e4">Il est utile de se souvenir que la commande <command
  1.1005 +        role="hg-cmd">hg revert</command> est utile pour les modifications
  1.1006 +      qui n'ont pas encore été commitées. Une fois que vous avez committé un
  1.1007 +      changement, si vous décidez qu'il s'agissait d'une erreur, vous pouvez
  1.1008 +      toujours faire quelquechose à ce sujet, bien que vos options seront
  1.1009 +      un peu plus limitées.</para>
  1.1010 +
  1.1011 +    <para id="x_1e5">Pour plus d'informations au sujet de la commande
  1.1012 +      <command role="hg-cmd">hg revert</command>, et des détails sur comment
  1.1013 +      traiter les modifications que vous avez déjà committées, référez vous à
  1.1014 +      <xref linkend="chap:undo"/>.</para>
  1.1015    </sect1>
  1.1016  
  1.1017    <sect1>
  1.1018 -    <title>Dealing with tricky merges</title>
  1.1019 -
  1.1020 -    <para id="x_687">In a complicated or large project, it's not unusual for a
  1.1021 -      merge of two changesets to result in some headaches.  Suppose
  1.1022 -      there's a big source file that's been extensively edited by each
  1.1023 -      side of a merge: this is almost inevitably going to result in
  1.1024 -      conflicts, some of which can take a few tries to sort
  1.1025 -      out.</para>
  1.1026 -
  1.1027 -    <para id="x_688">Let's develop a simple case of this and see how to deal with
  1.1028 -      it.  We'll start off with a repository containing one file, and
  1.1029 -      clone it twice.</para>
  1.1030 +    <title>Traiter avec les fusions (merge) malicieuses</title>
  1.1031 +
  1.1032 +    <para id="x_687">Dans des projets compliqués ou conséquents, il n'est pas
  1.1033 +      rare qu'une fusion (merge) de deux changesets finisse par une migraine.
  1.1034 +      Supposez qu'il y a un gros fichier source qui a été largement édité de
  1.1035 +      chaque coté de la fusion (merge) : ceci va inévitablement résulter en
  1.1036 +      conflits, dont certains peuvent prendre quelques essais pour s'en
  1.1037 +      sortir.</para>
  1.1038 +
  1.1039 +    <para id="x_688">Développons en un cas simple pour voir comment traiter
  1.1040 +      avec. Nous allons commencer avec un dépôt contenant un fichier, et le
  1.1041 +      cloner deux fois.</para>
  1.1042  
  1.1043      &interaction.ch04-resolve.init;
  1.1044  
  1.1045 -    <para id="x_689">In one clone, we'll modify the file in one way.</para>
  1.1046 +    <para id="x_689">Dans un des clones, nous allons modifier le fichier
  1.1047 +      d'une façon.</para>
  1.1048  
  1.1049      &interaction.ch04-resolve.left;
  1.1050  
  1.1051 -    <para id="x_68a">In another, we'll modify the file differently.</para>
  1.1052 +    <para id="x_68a">Dans un autre, nous allons modifier le fichier
  1.1053 +      différamment.</para>
  1.1054  
  1.1055      &interaction.ch04-resolve.right;
  1.1056  
  1.1057 -    <para id="x_68b">Next, we'll pull each set of changes into our original
  1.1058 -      repo.</para>
  1.1059 +    <para id="x_68b">Ensuite, nous allons récupérer (pull) chaque ensemble de
  1.1060 +      changement dans notre dépôt original.</para>
  1.1061  
  1.1062      &interaction.ch04-resolve.pull;
  1.1063  
  1.1064 -    <para id="x_68c">We expect our repository to now contain two heads.</para>
  1.1065 +    <para id="x_68c">Nous nous attendons à ce que notre dépôt contienne deux
  1.1066 +      HEADS.</para>
  1.1067  
  1.1068      &interaction.ch04-resolve.heads;
  1.1069  
  1.1070 -    <para id="x_68d">Normally, if we run <command role="hg-cmd">hg
  1.1071 -	merge</command> at this point, it will drop us into a GUI that
  1.1072 -      will let us manually resolve the conflicting edits to
  1.1073 -      <filename>myfile.txt</filename>.  However, to simplify things
  1.1074 -      for presentation here, we'd like the merge to fail immediately
  1.1075 -      instead.  Here's one way we can do so.</para>
  1.1076 +    <para id="x_68d">Normalement, si nous lançons <command role="hg-cmd">hg
  1.1077 +        merge</command> à ce point, il nous renverra vers une interface
  1.1078 +      utilisateur qui nous permettra de résoudre manuellement les éditions
  1.1079 +      conflictuelles sur le fichier <filename>myfile.txt</filename>.
  1.1080 +      Cependant, pour simplifier les choses dans la présentation ici, nous
  1.1081 +      aimerions que la fusion (merge) échoue immédiatement plutôt. Voici une
  1.1082 +      façon de le faire.</para>
  1.1083  
  1.1084      &interaction.ch04-resolve.export;
  1.1085  
  1.1086 -    <para id="x_68e">We've told Mercurial's merge machinery to run the command
  1.1087 -      <command>false</command> (which, as we desire, fails
  1.1088 -      immediately) if it detects a merge that it can't sort out
  1.1089 -      automatically.</para>
  1.1090 -
  1.1091 -    <para id="x_68f">If we now fire up <command role="hg-cmd">hg
  1.1092 -	merge</command>, it should grind to a halt and report a
  1.1093 -	failure.</para>
  1.1094 +    <para id="x_68e">Nous avons dit à la machinerie de fusion de Mercurial
  1.1095 +      d'exécuter la commande <command>false</command> (qui échoue
  1.1096 +      immédiatement, à la demande) s'il détecte une fusion (merge) qu'il ne
  1.1097 +      peut pas arranger automatiquement.</para>
  1.1098 +
  1.1099 +    <para id="x_68f">Si nous appelons maintenant <command role="hg-cmd">hg
  1.1100 +        merge</command>, il devrait planter et reporter une erreur.</para>
  1.1101  
  1.1102      &interaction.ch04-resolve.merge;
  1.1103  
  1.1104 -    <para id="x_690">Even if we don't notice that the merge failed, Mercurial
  1.1105 -      will prevent us from accidentally committing the result of a
  1.1106 -      failed merge.</para>
  1.1107 +    <para id="x_690">Même si nous ne remarquons pas qu'une fusion (merge) a
  1.1108 +      échoué, Mercurial nous empéchera de committer le résultat d'une fusion
  1.1109 +      ratée.</para>
  1.1110  
  1.1111      &interaction.ch04-resolve.cifail;
  1.1112  
  1.1113 -    <para id="x_691">When <command role="hg-cmd">hg commit</command> fails in
  1.1114 -      this case, it suggests that we use the unfamiliar <command
  1.1115 -	role="hg-cmd">hg resolve</command> command.  As usual,
  1.1116 -	<command role="hg-cmd">hg help resolve</command> will print a
  1.1117 -      helpful synopsis.</para>
  1.1118 +    <para id="x_691">Lorsque <command role="hg-cmd">hg commit</command>
  1.1119 +      échoue dans ce cas, il suggère que nous utilisons la commande peu
  1.1120 +      connue <command	role="hg-cmd">hg resolve</command>.  Comme d'habitude,
  1.1121 +      <command role="hg-cmd">hg help resolve</command> affichera une aide
  1.1122 +      sommaire.</para>
  1.1123  
  1.1124      <sect2>
  1.1125        <title>File resolution states</title>