1.1 --- a/fr/ch05-daily.xml	Wed Nov 25 15:33:52 2009 +0100
     1.2 +++ b/fr/ch05-daily.xml	Mon Nov 30 10:57:15 2009 +0100
     1.3 @@ -2,10 +2,10 @@
     1.4  
     1.5  <chapter id="chap:daily">
     1.6    <?dbhtml filename="mercurial-in-daily-use.html"?>
     1.7 -  <title>Mercurial pour une utilisation de tous les jours</title>
     1.8 +  <title>Utilisation quotidienne de Mercurial</title>
     1.9  
    1.10    <sect1>
    1.11 -    <title>Informer Mercurial des fichier à suivre</title>
    1.12 +    <title>Informer Mercurial des fichiers à suivre</title>
    1.13  
    1.14      <para id="x_1a3">Mercurial ne suit pas les fichiers de votre dépôt tant
    1.15        que vous ne lui avez pas dit de les gérer. La commande <command
    1.16 @@ -28,7 +28,7 @@
    1.17          status</command>. La raison de ceci est que, par défaut, <command
    1.18          role="hg-cmd">hg status</command> ne vous montre que les fichiers
    1.19        <quote>intéressants</quote> &emdash;ceux que vous avez (par exemple)
    1.20 -      modifiés, supprimés ou renommés. Si vous aviez un dépôt qui contient un
    1.21 +      modifiés, supprimés ou renommés. Si vous avez un dépôt qui contient un
    1.22        millier de fichiers, vous ne voudriez certainement que rarement entendre
    1.23        parler des fichiers que Mercurial suit, mais qui n'ont pas changés.
    1.24        (Vous pouvez quand même avoir cette information, nous y reviendrons
    1.25 @@ -179,7 +179,7 @@
    1.26  
    1.27        &interaction.daily.files.remove-after;
    1.28  
    1.29 -      <para id="x_1b8">D'un autre coté, si vous avez supprimé le fichier
    1.30 +      <para id="x_1b8">D'un autre côté, si vous avez supprimé le fichier
    1.31          manquant par accident, donnez à la commande <command role="hg-cmd">hg
    1.32            revert</command> le nom du fichier à retrouver. Il réapparaitra dans
    1.33          sa forme non modifiée.</para>
    1.34 @@ -189,13 +189,13 @@
    1.35      </sect2>
    1.36  
    1.37      <sect2>
    1.38 -      <title>Entre nous : Pourquoi dire explicitement à Mercurial de supprimer un
    1.39 +      <title>Aparté : Pourquoi dire explicitement à Mercurial de supprimer un
    1.40        fichier ?</title>
    1.41 -
    1.42 +<!-- TODO Choisir une traduction commune à tous les chapitres pour Aside -->
    1.43        <para id="x_1b9">Vous pourriez vous demander pourquoi il est nécessaire
    1.44          de dire explicitement à Mercurial que vous souhaitez supprimer un
    1.45          fichier. Au début du développement de Mercurial, celui ci vous
    1.46 -        laissait pourtant supprimer un fichier sans soucis ; Mercurial vous
    1.47 +        laissait pourtant supprimer un fichier sans souci ; Mercurial vous
    1.48          aurait automatiquement informé de l'absence du fichier lorsque vous
    1.49          auriez lancé un <command role="hg-cmd">hg commit</command> et arrêté
    1.50          de le suivre. En pratique, ceci a montré qu'il était trop facile de
    1.51 @@ -286,21 +286,20 @@
    1.52      
    1.53      </sect2>
    1.54      <sect2 id="sec:daily:why-copy">
    1.55 -      <title>Pourquoi est-ce que les changements devraient suivre les copies
    1.56 -        ?</title>
    1.57 -
    1.58 -      <para id="x_1c4">Ce comportement&emdash;des changements d'un fichiers
    1.59 +      <title>Pourquoi les changements devraient-ils suivre les copies ?</title>
    1.60 +
    1.61 +      <para id="x_1c4">Ce comportement&emdash;des changements d'un fichier
    1.62          qui se propagent aux copies de ce fichier&emdash;peut sembler
    1.63 -        ésotérique, mais, dans la plupart des cas, c'est hautement
    1.64 -        désirable.</para>
    1.65 -
    1.66 -      <para id="x_1c5">Pour commencer, souvenez vous que cette propagation
    1.67 -        a lieue <emphasis>seulement</emphasis> lors des fusions (merge).
    1.68 +        ésotérique, mais, dans la plupart des cas, c'est fortement
    1.69 +        souhaitable.</para>
    1.70 +
    1.71 +      <para id="x_1c5">Pour commencer, souvenez-vous que cette propagation
    1.72 +        a lieu <emphasis>seulement</emphasis> lors des fusions (merge).
    1.73          Donc, si vous faites un	<command role="hg-cmd">hg copy</command> sur
    1.74          un fichier, et par la suite modifiez le fichier original durant le
    1.75 -        cours normal de votre travail, rien n'a lieu.</para>
    1.76 -
    1.77 -      <para id="x_1c6">La deuxième chose à savoir c'est que les modifications
    1.78 +        cours normal de votre travail, rien n'aura lieu.</para>
    1.79 +
    1.80 +      <para id="x_1c6">La deuxième chose à savoir est que les modifications
    1.81          ne se propageront à travers une copie que si le changeset à partir
    1.82          duquel vous faites une fusion (merge) <emphasis>n'a pas encore
    1.83            vu</emphasis> la copie.</para>
    1.84 @@ -322,16 +321,16 @@
    1.85  
    1.86        <para id="x_1c9">En propageant automatiquement les changements qui
    1.87          fixent les bugs à partir du fichier original vers les copies,
    1.88 -        Mercurial prévient ce type de problèmes. A ma connaissance, Mercurial
    1.89 +        Mercurial prévient ce type de problèmes. À ma connaissance, Mercurial
    1.90          est le <emphasis>seul</emphasis> système de gestion de révisions qui
    1.91          propage les changements à travers les copies comme ceci.</para>
    1.92  
    1.93        <para id="x_1ca">Une fois que votre historique des changements a un
    1.94          enregistrement concernant une copie et qu'une fusion postérieure a
    1.95 -        eu lieue, il n'y a d'habitude pas d'autre besoin de propager les
    1.96 +        eu lieu, il n'y a d'habitude pas d'autre besoin de propager les
    1.97          changements du fichier originel vers le fichier copié. C'est pourquoi
    1.98          Mercurial ne propage les changements à travers les copies qu'à la
    1.99 -        première fusion, et pas d'avantage.</para>
   1.100 +        première fusion, et pas après.</para>
   1.101      </sect2>
   1.102  
   1.103      <sect2>
   1.104 @@ -428,7 +427,7 @@
   1.105  
   1.106      &interaction.daily.rename.status;
   1.107  
   1.108 -    <para id="x_1d5">A cause du <command role="hg-cmd">hg	copy</command>,
   1.109 +    <para id="x_1d5">À cause du <command role="hg-cmd">hg copy</command>,
   1.110        nous devons utiliser l'option <option role="hg-opt-status">-C</option>
   1.111        pour la commande <command	role="hg-cmd">hg status</command> afin
   1.112        d'observer que le fichier ajouté est bien suivi par Mercurial comme
   1.113 @@ -438,10 +437,10 @@
   1.114  
   1.115      <para id="x_1d6">Comme avec <command role="hg-cmd">hg remove</command> et
   1.116        <command role="hg-cmd">hg copy</command>, vous pouvez informer
   1.117 -      Mercurial au sujet d'un renommage après coup en utilisant l'option
   1.118 -      <option role="hg-opt-rename">--after</option>. Dans le plus grand
   1.119 -      respect, le comportement de la commande <command role="hg-cmd">hg
   1.120 -        rename</command>, et les options qu'il accepte sont similaires à la
   1.121 +      Mercurial d'un renommage après coup en utilisant l'option
   1.122 +      <option role="hg-opt-rename">--after</option>. Dans la plupart des autres
   1.123 +      situations, le comportement de la commande <command role="hg-cmd">hg
   1.124 +        rename</command>, et les options qu'elle accepte sont similaires à la
   1.125        commande <command role="hg-cmd">hg copy</command>.</para>
   1.126  
   1.127      <para id="x_686">Si vous êtes familier avec la ligne de commande Unix,
   1.128 @@ -452,9 +451,9 @@
   1.129      <sect2>
   1.130        <title>Renommer les fichiers et fusionner (merge) les changements</title>
   1.131  
   1.132 -      <para id="x_1d7">Puise que le "rename" de Mercurial est implanté comme un
   1.133 -        "copy-and-remove", la même propagation des changements a lieue après
   1.134 -        un "rename" qu'après un "copy" lorsque vous fusionnez (merge).</para>
   1.135 +      <para id="x_1d7">Puisque le <quote>rename</quote> de Mercurial est implanté comme un
   1.136 +        <quote>copy-and-remove</quote>, la même propagation des changements a lieu après
   1.137 +        un <quote>rename</quote> qu'après un <quote>copy</quote> lorsque vous fusionnez (merge).</para>
   1.138  
   1.139        <para id="x_1d8">Si je modifie un fichier et que vous le renommez, si
   1.140          ensuite nous fusionnons nos changements respectifs, mes modifications
   1.141 @@ -466,8 +465,8 @@
   1.142        <para id="x_1d9">Tandis qu'avoir des changements qui suivent une copie
   1.143          est une fonctionnalité où vous hocheriez sûrement la tête en disant
   1.144          <quote>oui, cela pourrait être utile</quote>, il est clair que les
   1.145 -        voir suivre un renommage est définitivement important. Sans cette
   1.146 -        aptitude, il serait vraiment trop facile d'avoir des changements
   1.147 +        voir suivre un renommage est sans aucun doute important. Sans cette
   1.148 +        facilité, il serait vraiment trop facile d'avoir des changements
   1.149          qui deviennent orphelins lorsque des fichiers sont renommés.</para>
   1.150      </sect2>
   1.151  
   1.152 @@ -486,7 +485,7 @@
   1.153        &interaction.rename.divergent.rename.anne;
   1.154  
   1.155        <para id="x_1dc">Pendant ce temps, Bob le renomme en
   1.156 -        <filename>quux</filename>. (Souvenez vous que <command
   1.157 +        <filename>quux</filename>. (Souvenez-vous que <command
   1.158            role="hg-cmd">hg mv</command> est un alias pour <command
   1.159            role="hg-cmd">hg rename</command>.)</para>
   1.160      
   1.161 @@ -496,7 +495,7 @@
   1.162          chaque développeur a exprimé différentes intentions au sujet de ce
   1.163          que le nom de ce fichier aurait du être.</para>
   1.164  
   1.165 -      <para id="x_1de">Que pensez vous qu'il devrait se produire lorsqu'ils
   1.166 +      <para id="x_1de">Que pensez-vous qu'il devrait se produire lorsqu'ils
   1.167          fusionnent (merge) leurs travaux ? Le comportement actuel de
   1.168          Mercurial est qu'il préserve toujours les <emphasis>deux</emphasis>
   1.169          noms lorsqu'il fusionne (merge) des changesets qui contiennent des
   1.170 @@ -506,14 +505,14 @@
   1.171  
   1.172        <para id="x_1df">Remarquez que bien que Mercurial vous avertisse au
   1.173          sujet de la divergeance des renommages, il vous laisse faire quelque
   1.174 -        chose au sujet de la divergeance après la fusion (merge).</para>
   1.175 +        chose au sujet de la divergence après la fusion (merge).</para>
   1.176      </sect2>
   1.177  
   1.178      <sect2>
   1.179        <title>Renommages et fusion convergeants</title>
   1.180  
   1.181        <para id="x_1e0">Un autre type de conflit de renommage intervient
   1.182 -        lorsque deux personne choisissent de renommer différents fichiers
   1.183 +        lorsque deux personnes choisissent de renommer différents fichiers
   1.184          <emphasis>source</emphasis> vers la même
   1.185          <emphasis>destination</emphasis>. Dans ce cas, Mercurial exécute la
   1.186          machinerie normale de fusion (merge) et vous guide vers une
   1.187 @@ -521,11 +520,11 @@
   1.188      </sect2>
   1.189  
   1.190      <sect2>
   1.191 -      <title>Autres cas anguleux relatifs aux noms</title>
   1.192 +      <title>Autres cas épineux relatifs aux noms</title>
   1.193  
   1.194        <para id="x_1e1">Mercurial possède un bug de longue date dans lequel il
   1.195 -        échoue à traiter une fusion (merge) où un coté a un fichier avec un
   1.196 -        nom donné, alors que l'autre coté possède un répertoire avec le même nom.
   1.197 +        échoue à traiter une fusion (merge) où un côté a un fichier avec un
   1.198 +        nom donné, alors que l'autre côté possède un répertoire avec le même nom.
   1.199          Ceci est documenté dans l'<ulink role="hg-bug"
   1.200            url="http://www.selenic.com/mercurial/bts/issue29">issue
   1.201            29</ulink>.</para>
   1.202 @@ -534,7 +533,6 @@
   1.203  
   1.204      </sect2>
   1.205    </sect1>
   1.206 -
   1.207    <sect1>
   1.208      <title>Récupération d'erreurs</title>
   1.209  
   1.210 @@ -545,11 +543,11 @@
   1.211        vous permet d'annuler les changements que vous avez faits dans votre
   1.212        répertoire de travail. Par exemple, si vous faites un <command
   1.213          role="hg-cmd">hg add</command> sur un fichier par accident, exécutez
   1.214 -      juste <command role="hg-cmd">hg	revert</command> avec le nom du fichier
   1.215 +      juste <command role="hg-cmd">hg revert</command> avec le nom du fichier
   1.216        que vous avez ajouté et tandis que le fichier ne sera touché d'une
   1.217        quelconque manière, il ne sera plus suivi comme ajouté par Mercurial.
   1.218        Vous pouvez aussi utiliser la commande <command role="hg-cmd">hg
   1.219 -        revert</command> pour vous débarrasser de modifications erronés
   1.220 +        revert</command> pour vous débarrasser de modifications erronées
   1.221        apportées à un fichier.</para>
   1.222  
   1.223      <para id="x_1e4">Il est utile de se souvenir que la commande <command
   1.224 @@ -629,7 +627,7 @@
   1.225  
   1.226      <para id="x_691">Lorsque <command role="hg-cmd">hg commit</command>
   1.227        échoue dans ce cas, il suggère que nous utilisons la commande peu
   1.228 -      connue <command	role="hg-cmd">hg resolve</command>.  Comme d'habitude,
   1.229 +      connue <command role="hg-cmd">hg resolve</command>. Comme d'habitude,
   1.230        <command role="hg-cmd">hg help resolve</command> affichera une aide
   1.231        sommaire.</para>
   1.232  
   1.233 @@ -668,8 +666,8 @@
   1.234        &interaction.ch04-resolve.list;
   1.235  
   1.236        <para id="x_697">En sortie de <command role="hg-cmd">hg
   1.237 -          resolve</command>, un fichier "resolved" est marqué avec un
   1.238 -        <literal>R</literal>, alors qu'un fichier "unresolved" est marqué
   1.239 +          resolve</command>, un fichier <quote>resolved</quote> est marqué avec un
   1.240 +        <literal>R</literal>, alors qu'un fichier <quote>unresolved</quote> est marqué
   1.241          d'un <literal>U</literal>.  S'il existe un fichier listé avec un
   1.242          <literal>U</literal>, nous savons qu'essayer de committer le résultat
   1.243          de la fusion (merge) échouera.</para>
   1.244 @@ -679,27 +677,28 @@
   1.245        <title>Résoudre une fusion de fichier</title>
   1.246  
   1.247        <para id="x_698">Nous avons plusieurs options pour changer l'état d'un
   1.248 -        fichier de "unresolved" à "resolved". Le plus commun est de relancer
   1.249 +        fichier de <quote>unresolved</quote> à <quote>resolved</quote>.
   1.250 +        Le plus habituel est de relancer
   1.251          <command role="hg-cmd">hg resolve</command>. Si nous passons les noms
   1.252          des fichiers individuels ou des répertoires, ceci retentera la fusion
   1.253          de tous les fichiers présents à cet endroit. Nous pouvons aussi
   1.254          passer l'option <option role="hg-opt-resolve">--all</option> ou
   1.255          <option role="hg-opt-resolve">-a</option> qui tentera de fusionner
   1.256 -        <emphasis>tous</emphasis> les fichiers "unresolved".</para>
   1.257 +        <emphasis>tous</emphasis> les fichiers <quote>unresolved</quote>.</para>
   1.258  
   1.259        <para id="x_699">Mercurial nous laisse aussi modifier la résolution
   1.260 -        d'un fichier directement. Nous pouvons marquer un fichier "resolved"
   1.261 +        d'un fichier directement. Nous pouvons marquer un fichier <quote>resolved</quote>
   1.262          en utilisant l'option <option role="hg-opt-resolve">--mark</option>,
   1.263 -        ou "unresolved" en utilisant l'option <option
   1.264 +        ou <quote>unresolved</quote> en utilisant l'option <option
   1.265            role="hg-opt-resolve">--unmark</option>. Ceci nous autorise à
   1.266          nettoyer une fusion particulièrement compliquée à la main, et de
   1.267          garder un suivi de nos progrès avec chaque fichier pendant que nous
   1.268 -        procédons.</para>
   1.269 +        avançons.</para>
   1.270      </sect2>
   1.271    </sect1>
   1.272  
   1.273    <sect1>
   1.274 -    <title>Des "diffs" plus utiles</title>
   1.275 +    <title>Des <quote>diffs</quote> plus utiles</title>
   1.276  
   1.277      <para id="x_6c7">La sortie par défaut de la commande <command
   1.278          role="hg-cmd">hg diff</command> est compatible rétrospectivement avec
   1.279 @@ -720,8 +719,8 @@
   1.280  
   1.281      &interaction.ch04-diff.rename.git;
   1.282  
   1.283 -    <para id="x_6ca">Cette option peut aussi aider avec le cas autrement
   1.284 -      confus : un fichier qui apparaît comme étant modifié en accord avec
   1.285 +    <para id="x_6ca">Cette option peut aussi aider avec le cas qui peut être autrement
   1.286 +      perturbant : un fichier qui apparaît comme étant modifié en accord avec
   1.287        <command role="hg-cmd">hg status</command>, mais où <command
   1.288          role="hg-cmd">hg diff</command> n'affiche rien. Cette situation peut
   1.289        survenir si nous changeons les permissions d'exécution du
   1.290 @@ -733,7 +732,7 @@
   1.291        attention aux permissions des fichiers, ce qui explique pourquoi
   1.292        <command role="hg-cmd">hg diff</command> n'affiche rien du tout par
   1.293        défaut. Si nous lui passons l'option <option>-g</option>, ceci nous
   1.294 -      informe de ce qu'il s'est vraiment passé.</para>
   1.295 +      informe de ce qui s'est vraiment passé.</para>
   1.296  
   1.297      &interaction.ch04-diff.chmod.git;
   1.298    </sect1>
   1.299 @@ -766,7 +765,7 @@
   1.300        guident les décisions sur quels fichiers gérer et comment.</para>
   1.301  
   1.302      <para id="x_6d0">Par exemple, un système distribué de gestion de révisions
   1.303 -      ne peut pas, par sa nature, offrir un système de véroux (lock) sur les
   1.304 +      ne peut pas, par sa nature, offrir un système de verrou (lock) sur les
   1.305        fichiers. Il n'y a donc pas de mécanisme inclus pour empêcher deux
   1.306        personnes de faire des modifications conflictuelles sur un fichier
   1.307        binaire. Si vous avez une équipe où plusieurs personnes peuvent souvent
   1.308 @@ -794,8 +793,8 @@
   1.309        comme des fichiers compressés zip. Même le fait d'éditer ces fichiers
   1.310        d'une seule lettre, changera les bits de la quasi totalité du fichier
   1.311        lorsque vous le sauvegarderez. Maintenant, supposez que ce fichier
   1.312 -      fasse une taille de 2Mo. Puisque la plupart du fichier change à chaque
   1.313 -      fois que vous sauvegardez, Mercurial aura à sauvegarder tous les 2Mo du
   1.314 +      fasse une taille de 2 Mo. Puisque la plupart du fichier change à chaque
   1.315 +      fois que vous sauvegardez, Mercurial aura à sauvegarder tous les 2 Mo du
   1.316        fichier à chaque commit, alors que de votre point de vue, il n'y a
   1.317        que peu de mots qui changent à chaque fois. Un seul fichier
   1.318        souvent édité qui n'est pas bien traité par les hypothèses que Mercurial
   1.319 @@ -820,7 +819,7 @@
   1.320       <!-- TODO : Trouver une meilleure traduction pour : ISO CD-ROM images, will by
   1.321       virtue of sheer size make clones over a network very slow. -->
   1.322        <listitem><para id="x_6d6">Les fichiers qui changent beaucoup d'une
   1.323 -          révision à l'autre peuvent être très chers à sauvegarder si vous
   1.324 +          révision à l'autre peuvent être très coûteux à sauvegarder si vous
   1.325            les éditez fréquemment, de même que les conflits entre deux éditions
   1.326            concurrentes peuvent être difficiles à résoudre.</para>
   1.327        </listitem>
   1.328 @@ -845,7 +844,7 @@
   1.329        distant chaque heure. Ceci sera difficile seulement dans le cas
   1.330        improbable où le nombre des dépôts maîtres que vous maintenez change
   1.331        souvent, auquel cas vous aurez besoin de faire un peu de scripting pour
   1.332 -      rafraichir la liste des dépôt à sauvegarder.</para>
   1.333 +      rafraichir la liste des dépôts à sauvegarder.</para>
   1.334  
   1.335      <para id="x_6d9">Si vous exécutez des sauvegardes traditionnelles de
   1.336        votre dépôt maître sur bande ou disque, et que vous voulez sauvegarder
   1.337 @@ -858,7 +857,7 @@
   1.338  
   1.339      <para id="x_6da">Si vous voulez ensuite sauvegarder
   1.340        <filename>myrepo.bak</filename> au lieu de <filename>myrepo</filename>,
   1.341 -      vous aurez la garantie d'avoir une image (snapshot) consistante de
   1.342 +      vous aurez la garantie d'avoir une image (snapshot) cohérente de
   1.343        votre dépôt sur lequel un développeur insomniaque n'enverra (push) pas de
   1.344        changements en milieu de sauvegarde.</para>
   1.345    </sect1>