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