1.1 --- a/fr/ch05-daily.xml	Thu Sep 10 13:06:34 2009 +0200
     1.2 +++ b/fr/ch05-daily.xml	Thu Sep 10 14:45:17 2009 +0200
     1.3 @@ -2,14 +2,14 @@
     1.4  
     1.5  <chapter id="chap:daily">
     1.6    <?dbhtml filename="mercurial-in-daily-use.html"?>
     1.7 -  <title>Mercurial in daily use</title>
     1.8 +  <title>Mercurial pour une utilisation de tous les jours</title>
     1.9  
    1.10    <sect1>
    1.11 -    <title>Telling Mercurial which files to track</title>
    1.12 -
    1.13 -    <para id="x_1a3">Mercurial ne fonctionne pas avec les fichiers de votre
    1.14 -      dépôt tant que vous ne lui avez pas dit de les gérer. La commande
    1.15 -      <command role="hg-cmd">hg status</command> vous dira quels fichier sont
    1.16 +    <title>Informer Mercurial des fichier à suivre</title>
    1.17 +
    1.18 +    <para id="x_1a3">Mercurial ne suit pas les fichiers de votre dépôt tant
    1.19 +      que vous ne lui avez pas dit de les gérer. La commande <command
    1.20 +        role="hg-cmd">hg status</command> vous dira quels fichiers sont
    1.21        inconnus de Mercurial. Il utilise un
    1.22        <quote><literal>?</literal></quote> pour montrer ces fichiers.</para>
    1.23  
    1.24 @@ -23,30 +23,30 @@
    1.25      &interaction.daily.files.add;
    1.26  
    1.27      <para id="x_1a5">Après avoir exécuté un <command role="hg-cmd">hg
    1.28 -        commit</command>, les fichiers que vous avez ajouté avant le commit
    1.29 -      ne seront plus listé dans la sortie de <command role="hg-cmd">hg
    1.30 -        status</command>. La raison de ceci est que par défaut, <command
    1.31 +        commit</command>, les fichiers que vous avez ajoutés avant le commit
    1.32 +      ne seront plus listés dans la sortie de <command role="hg-cmd">hg
    1.33 +        status</command>. La raison de ceci est que, par défaut, <command
    1.34          role="hg-cmd">hg status</command> ne vous montre que les fichiers
    1.35        <quote>intéressants</quote> &emdash;ceux que vous avez (par exemple)
    1.36 -      modifiés, supprimés ou renommés. Si vous avez un dépôt qui contient un
    1.37 -      millier de fichiers, vous ne voudrez certainement que rarement entendre
    1.38 +      modifiés, supprimés ou renommés. Si vous aviez un dépôt qui contient un
    1.39 +      millier de fichiers, vous ne voudriez certainement que rarement entendre
    1.40        parler des fichiers que Mercurial suit, mais qui n'ont pas changés.
    1.41        (Vous pouvez quand même avoir cette information, nous y reviendrons
    1.42        plus tard.)</para>
    1.43  
    1.44      <para id="x_1a6">Une fois que vous ajoutez un fichier, Mercurial ne fait
    1.45 -      rien du tout avec celui-ci immédiatement. A lieu de ça, il va prendre
    1.46 +      rien du tout avec celui-ci immédiatement. Au lieu de ça, il va prendre
    1.47        un "snapshot" de l'état du fichier la prochaine fois que vous
    1.48        exécuterez un commit. Il continuera ensuite à suivre les changements
    1.49 -      que vous avez fait au fichier chaque fois que vous committerez, jusqu'à
    1.50 -      ce que vous supprimiez le fichier.</para>
    1.51 +      que vous avez fait au fichier chaque fois que vous committerez, et ce,
    1.52 +      jusqu'à ce que vous supprimiez le fichier.</para>
    1.53  
    1.54      <sect2>
    1.55        <title>Nommage des fichiers explicite versus implicite</title>
    1.56  
    1.57        <para id="x_1a7">Un comportement utile que Mercurial possède est que si
    1.58          vous passez le nom d'un répertoire à une commande, toute commande
    1.59 -        Mercurial la traitera comme <quote>Je veux opérer sur chaque fichier
    1.60 +        Mercurial la traitera comme : <quote>Je veux opérer sur chaque fichier
    1.61            dans ce répertoire et ses sous-répertoires</quote>.</para>
    1.62  
    1.63        &interaction.daily.files.add-dir;
    1.64 @@ -58,49 +58,49 @@
    1.65  
    1.66        <para id="x_1a9">Ce qu'il se passe est que dans le premier cas, nous
    1.67          avons nommé explicitement le fichier à ajouter sur la ligne de
    1.68 -        commande. La supposition que Mercurial fait dans ces cas est que nous
    1.69 -        savons ce que nous faisons, il n'affiche dont rien en sortie.</para>
    1.70 +        commande. Ce que Mercurial suppose dans ce cas est que nous savons ce
    1.71 +        que nous faisons, il n'affiche donc rien en sortie.</para>
    1.72  
    1.73        <para id="x_1aa">Cependant, lorsque nous avons
    1.74          <emphasis>implicitement</emphasis> donné les fichiers à l'aide du nom
    1.75 -        d'un répertoire, Mercurial prend le l'initiative d'afficher le nom de
    1.76 +        d'un répertoire, Mercurial prend l'initiative d'afficher le nom de
    1.77          chaque fichier avec lequel il fait quelque chose. Ceci clarifie ce
    1.78 -        qu'il se passe, et réduit la probabilité d'une surprise silencieuse
    1.79 -        et désagréable. Ce comportement est commun à la plupart des commandes
    1.80 -        Mercurial.</para>
    1.81 +        qu'il se passe et réduit la probabilité d'une mauvaise surprise
    1.82 +        restée silencieuse. Ce comportement est commun à la plupart des
    1.83 +        commandes Mercurial.</para>
    1.84      </sect2>
    1.85      <sect2>
    1.86        <title>Mercurial suit les fichiers, pas les répertoires</title>
    1.87  
    1.88        <para id="x_1ab">Mercurial ne suit pas les informations sur les
    1.89 -        répertoire. En contrepartie, il suit le chemin vers un fichier. Avant
    1.90 +        répertoires. En contrepartie, il suit le chemin vers un fichier. Avant
    1.91          de créer un fichier, il crée au préalable les répertoires manquants
    1.92          dans le chemin. Après avoir supprimé un fichier, il supprime chaque
    1.93          répertoire vide qui apparaît dans le chemin du fichier. Ceci apparaît
    1.94 -        comme une distinction triviale, cependant, ceci a une conséquence
    1.95 +        comme une distinction triviale, cependant, cela a une conséquence
    1.96          pratique mineure : il n'est pas possible de représenter un répertoire
    1.97          totalement vide dans Mercurial.</para>
    1.98  
    1.99        <para id="x_1ac">Les répertoires vides sont rarement utiles. Il existe
   1.100 -        des solutions alternatives et non intrusives que vous pouvez utiliser
   1.101 -        pour obtenir l'effet approprié. Les développeurs de Mercurial ont
   1.102 -        ainsi pensé que la complexité requise pour gérer les répertoires
   1.103 -        n'était pas aussi importante que le bénéfice que cette fonctionnalité
   1.104 -        apporterait.</para>
   1.105 +        cependant des solutions alternatives et non intrusives que vous
   1.106 +        pouvez utiliser pour obtenir l'effet approprié. Les développeurs de
   1.107 +        Mercurial ont ainsi pensé que la complexité requise pour gérer les
   1.108 +        répertoires n'était pas aussi importante que le bénéfice que cette
   1.109 +        fonctionnalité apporterait.</para>
   1.110  
   1.111        <para id="x_1ad">Si vous avez besoin d'un répertoire vide dans votre
   1.112          dépôt, il existe quelques façons d'y arriver. L'une d'elles est de
   1.113 -        créer un répertoire et d'ensuite, faire un <command role="hg-cmd">hg
   1.114 -          add</command> sur un fichier <quote>hidden</quote> file dans ce
   1.115 -        répertoire. Sur les fichiers de type Unix, tout fichier dont le nom
   1.116 +        créer un répertoire et ensuite, de faire un <command role="hg-cmd">hg
   1.117 +          add</command> sur un fichier <quote>caché</quote> dans ce
   1.118 +        répertoire. Sur les systèmes de type Unix, tout fichier dont le nom
   1.119          commence avec un point (<quote><literal>.</literal></quote>) est
   1.120          considéré comme caché par la plupart des commandes et outils
   1.121 -        graphiques. Cette approche est illustré ci-après.</para>
   1.122 +        graphiques. Cette approche est illustrée ci-après.</para>
   1.123        
   1.124        &interaction.daily.files.hidden;
   1.125  
   1.126        <para id="x_1ae">Une autre façon de s'attaquer au besoin d'un
   1.127 -        répertoire vide est de simplement en créer un dans vos scripts
   1.128 +        répertoire vide est de simplement d'en créer un dans vos scripts
   1.129          de construction avant qu'ils n'en aient le besoin.</para>
   1.130      </sect2>
   1.131    </sect1>
   1.132 @@ -121,7 +121,7 @@
   1.133      <para id="x_1b0">Après avoir fait un <command role="hg-cmd">hg
   1.134          remove</command> sur un fichier, Mercurial ne suivra plus aucun
   1.135        changement sur ce fichier, même si vous recréez un fichier avec le même
   1.136 -      nom dans le répertoire de travail. Si vous recréez un fichier avec le
   1.137 +      nom dans votre répertoire de travail. Si vous recréez un fichier avec le
   1.138        même nom et que vous désirez que Mercurial suive ce dernier, faite
   1.139        simplement un <command role="hg-cmd">hg add</command> sur celui-ci.
   1.140        Mercurial saura alors que le nouveau fichier ne fait pas référence à
   1.141 @@ -130,7 +130,7 @@
   1.142      <sect2>
   1.143        <title>Supprimer un fichier n'affecte pas son historique</title>
   1.144  
   1.145 -      <para id="x_1b1">Il est important de comprendre que supprmer un fichier
   1.146 +      <para id="x_1b1">Il est important de comprendre que supprimer un fichier
   1.147          n'a que deux effets.</para>
   1.148  
   1.149        <itemizedlist>
   1.150 @@ -147,17 +147,17 @@
   1.151          fichier.</para>
   1.152  
   1.153        <para id="x_1b5">Si vous mettez à jour le répertoire de travail à un
   1.154 -        changeset qui a été commité alors que le fichier que vous venez de
   1.155 -        supprimer était encore suivi, ce fichier réaparaittra dans le
   1.156 +        changeset qui a été committé alors que le fichier que vous venez de
   1.157 +        supprimer était encore suivi, ce fichier réapparaîtra dans le
   1.158          répertoire de travail, avec le contenu qu'il avait lorsque vous aviez
   1.159 -        commité ce changeset. Si vous mettez à jour (update) le répertoire de
   1.160 -        travail à un changeset ultérieur, dans lequel le fichier a été
   1.161 +        committé ce changeset. Si vous mettez à jour (update) le répertoire de
   1.162 +        travail à un changeset ultérieur dans lequel le fichier a été
   1.163          supprimé, Mercurial supprimera une nouvelle fois le fichier du
   1.164          répertoire de travail.</para>
   1.165      </sect2>
   1.166  
   1.167      <sect2>
   1.168 -      <title>Fichier manquants</title>
   1.169 +      <title>Fichiers manquants</title>
   1.170  
   1.171        <para id="x_1b6">Mercurial considère qu'un fichier que vous avez
   1.172          supprimé sans utiliser<command role="hg-cmd">hg remove</command>
   1.173 @@ -170,7 +170,7 @@
   1.174        &interaction.daily.files.missing;
   1.175  
   1.176        <para id="x_1b7">Si votre dépôt contient un fichier que <command
   1.177 -          role="hg-cmd">hg status</command> repporte comme manquant, et que
   1.178 +          role="hg-cmd">hg status</command> reporte comme manquant, et que
   1.179          vous voulez que ce fichier reste supprimé, vous pouvez exécuter
   1.180          <command role="hg-cmd">hg remove <option
   1.181              role="hg-opt-remove">--after</option></command> à tout moment
   1.182 @@ -181,7 +181,7 @@
   1.183  
   1.184        <para id="x_1b8">D'un autre coté, si vous avez supprimé le fichier
   1.185          manquant par accident, donnez à la commande <command role="hg-cmd">hg
   1.186 -          revert</command> le nom du fichier à retrouver. Il réaparaitra dans
   1.187 +          revert</command> le nom du fichier à retrouver. Il réapparaitra dans
   1.188          sa forme non modifiée.</para>
   1.189  
   1.190        &interaction.daily.files.recover-missing;
   1.191 @@ -193,7 +193,7 @@
   1.192        fichier ?</title>
   1.193  
   1.194        <para id="x_1b9">Vous pourriez vous demander pourquoi il est nécessaire
   1.195 -        de dire exprécement à Mercurial que vous souhaitez supprimer un
   1.196 +        de dire explicitement à Mercurial que vous souhaitez supprimer un
   1.197          fichier. Au début du développement de Mercurial, celui ci vous
   1.198          laissait pourtant supprimer un fichier sans soucis ; Mercurial vous
   1.199          aurait automatiquement informé de l'absence du fichier lorsque vous
   1.200 @@ -203,7 +203,7 @@
   1.201      </sect2>
   1.202  
   1.203      <sect2>
   1.204 -      <title>Racourcis utile&emdash;ajouter et supprimer des fichiers en une
   1.205 +      <title>Raccourci utile&emdash;ajouter et supprimer des fichiers en une
   1.206        seule étape.</title>
   1.207  
   1.208        <para id="x_1ba">Mercurial offre une commande combinée, <command
   1.209 @@ -230,15 +230,15 @@
   1.210        fichier. Lorsque vous copiez un fichier en utilisant cette commande,
   1.211        Mercurial crée un enregistrement du fait que ce nouveau fichier est une
   1.212        copie du fichier originel. Il traite ces fichiers copiés spécialement
   1.213 -      lorsque vous faites une fusion (merge) de votre travail avec quelqu'un
   1.214 +      lorsque vous fusionnez (merge) votre travail avec quelqu'un
   1.215        d'autre.</para>
   1.216  
   1.217      <sect2>
   1.218 -      <title>Les résultat d'une copie durant une fusion (merge)</title>
   1.219 +      <title>Les résultats d'une copie durant une fusion (merge)</title>
   1.220  
   1.221        <para id="x_1bd">Ce qu'il se passe durant une fusion (merge) est que
   1.222          les changements <quote>suivent</quote> une copie. Pour illustrer ce
   1.223 -        que ça veut dire de la meilleure façon, créons un exemple. Nous
   1.224 +        que cela veut dire de la meilleure façon, créons un exemple. Nous
   1.225          allons commencer avec le mini dépôt usuel qui contient un simple
   1.226          fichier.</para>
   1.227  
   1.228 @@ -270,24 +270,24 @@
   1.229        &interaction.daily.copy.status-copy;
   1.230  
   1.231        <para id="x_1c2">Maintenant, de retour dans le dépôt que nous avons
   1.232 -        cloné, et créons un changement en parallèle. Nous allons ajouter une
   1.233 +        cloné, créons un changement en parallèle. Nous allons ajouter une
   1.234          ligne de contenu au fichier original qui a été créé.</para>
   1.235  
   1.236        &interaction.daily.copy.other;
   1.237  
   1.238 -      <para id="x_1c3">Maintenant, nous avons un fichier
   1.239 -        <filename>file</filename> modifié dans ce dépôt. Lorsque nous
   1.240 -        récupérons (pull) les changements depuis le premier répertoire et
   1.241 -        fusionnons (merge) les deux HEADS, Mercurial propagera les
   1.242 -        changements que nous avons fait localement au fichier
   1.243 -        <filename>file</filename> dans sa copie
   1.244 +      <para id="x_1c3">Nous avons alors un fichier <filename>file</filename>
   1.245 +        modifié dans ce dépôt. Lorsque nous récupérons (pull) les changements
   1.246 +        depuis le premier répertoire et fusionnons (merge) les deux "heads",
   1.247 +        Mercurial propagera les changements que nous avons faits localement
   1.248 +        au fichier <filename>file</filename> dans sa copie
   1.249          <filename>new-file</filename>.</para>
   1.250  
   1.251        &interaction.daily.copy.merge;
   1.252      
   1.253      </sect2>
   1.254      <sect2 id="sec:daily:why-copy">
   1.255 -      <title>Pourquoi les changements devraient suivre les copies ?</title>
   1.256 +      <title>Pourquoi est-ce que les changements devraient suivre les copies
   1.257 +        ?</title>
   1.258  
   1.259        <para id="x_1c4">Ce comportement&emdash;des changements d'un fichiers
   1.260          qui se propagent aux copies de ce fichier&emdash;peut sembler
   1.261 @@ -306,17 +306,17 @@
   1.262            vu</emphasis> la copie.</para>
   1.263            
   1.264        <para id="x_1c7">La raison pour laquelle Mercurial fait ainsi est une
   1.265 -        règle. Disons que je corrige un important bug dans un fichier source
   1.266 -        et commit mes changements. Pendant ce temps, vous avez décidé de
   1.267 +        règle. Imaginons que je corrige un important bug dans un fichier source
   1.268 +        et que je commit mes changements. Pendant ce temps, vous avez décidé de
   1.269          faire un <command role="hg-cmd">hg copy</command> du fichier dans
   1.270 -        votre dépôt, sans rien savoir au sujet du bug ou sans avoir rien vu à
   1.271 -        propos de la correction, et vous avez commencé à "hacker" sur votre
   1.272 -        copie du fichier.</para>
   1.273 +        votre dépôt, sans rien savoir au sujet du bug ou à propos de la
   1.274 +        correction. Vous avez alors commencé à "hacker" sur votre copie du
   1.275 +        fichier.</para>
   1.276  
   1.277        <para id="x_1c8">Si vous aviez récupéré (pull) et fusionné (merge) mes
   1.278          changements, et que Mercurial <emphasis>n'avait pas</emphasis>
   1.279          propagé les changements à travers les copies, votre nouveau fichier
   1.280 -        source contiendrait maintenant le bug, et à moins que vous sachiez
   1.281 +        source contiendrait maintenant le bug, et à moins que vous ne sachiez
   1.282          qu'il faille propager la correction du bug à la main, le bug aurait
   1.283          <emphasis>subsisté</emphasis> dans votre copie du fichier.</para>
   1.284  
   1.285 @@ -327,11 +327,11 @@
   1.286          propage les changements à travers les copies comme ceci.</para>
   1.287  
   1.288        <para id="x_1ca">Une fois que votre historique des changements a un
   1.289 -        enregistrement concernant une copie et une fusion postérieure qui a
   1.290 +        enregistrement concernant une copie et qu'une fusion postérieure a
   1.291          eu lieue, il n'y a d'habitude pas d'autre besoin de propager les
   1.292 -        changements du fichier originel vers le fichier copié, et c'est
   1.293 -        pourquoi Mercurial ne propage les changements à travers les copies
   1.294 -        seulement à la première fusion, et pas d'avantage.</para>
   1.295 +        changements du fichier originel vers le fichier copié. C'est pourquoi
   1.296 +        Mercurial ne propage les changements à travers les copies qu'à la
   1.297 +        première fusion, et pas d'avantage.</para>
   1.298      </sect2>
   1.299  
   1.300      <sect2>
   1.301 @@ -346,8 +346,8 @@
   1.302          fichier. Utilisez ensuite <command role="hg-cmd">hg add</command>
   1.303          pour ajouter les nouveaux fichiers à la main. Cependant, avant d'en
   1.304          faire ainsi, relisez <xref linkend="sec:daily:why-copy"/>, et faites
   1.305 -        un choix en tout état de cause que cette fonctionnalité n'est pas
   1.306 -        appropriée à votre cas spécifique.</para>
   1.307 +        un choix en connaissance de cause comme quoi cette fonctionnalité
   1.308 +        n'est pas appropriée à votre cas spécifique.</para>
   1.309  
   1.310      </sect2>
   1.311      <sect2>
   1.312 @@ -356,13 +356,14 @@
   1.313        <para id="x_1cc">Lorsque vous utilisez la commande <command
   1.314            role="hg-cmd">hg copy</command>, Mercurial crée une copie de chaque
   1.315          fichier source tel qu'il est actuellement dans le répertoire de
   1.316 -        travail. Cela signifie que si vous faites des modifications à un
   1.317 +        travail. Cela signifie que si vous effectuez des modifications sur un
   1.318          fichier, puis faites un <command role="hg-cmd">hg copy</command> sur
   1.319 -        celui-ci sans avoir au préalable commité ces changements, la nouvelle
   1.320 +        celui-ci sans avoir au préalable committé ces changements, la nouvelle
   1.321          copie contiendra aussi les modifications que vous avez fait jusqu'à
   1.322 -        ce point.	modifications you have made up until that point.  (Je
   1.323 -        trouve ce comportement quelque peu contre intuitif, c'est pourquoi
   1.324 -        j'en fais mention ici.)</para>
   1.325 +        ce point.	(Je trouve ce comportement quelque peu contre intuitif,
   1.326 +        c'est pourquoi j'en fais mention ici.)</para>
   1.327 +      <!-- Vérifier que je n'ai pas fait de contre sens en relisant la
   1.328 +      version anglaise, ce que je comprend ici me paraît un peu bizarre -->
   1.329  
   1.330        <para id="x_1cd">La commande <command role="hg-cmd">hg copy</command>
   1.331          agit comme la commande Unix <command>cp</command> (vous pouvez
   1.332 @@ -388,7 +389,7 @@
   1.333        &interaction.daily.copy.dir-src;
   1.334  
   1.335        <para id="x_1d0">Si la source et la destination sont tous deux des
   1.336 -        répertoires, l'arborescence de la source est recrée dans le
   1.337 +        répertoires, l'arborescence de la source est recréée dans le
   1.338          répertoire destination.</para>
   1.339      
   1.340        &interaction.daily.copy.dir-src-dest;
   1.341 @@ -410,40 +411,40 @@
   1.342        fichier que d'en faire une copie. La raison pour laquelle j'ai discuté
   1.343        de la commande <command role="hg-cmd">hg copy</command> avant de parler
   1.344        de renommage des fichiers est que Mercurial traite les renommages
   1.345 -      essenciellement comme une copie. Ainsi, savoir comment Mercurial traite
   1.346 +      essentiellement comme une copie. Ainsi, savoir comment Mercurial traite
   1.347        les copies de fichiers vous informe sur ce que vous êtes en droit
   1.348        d'attendre lorsque vous renommez un fichier.</para>
   1.349  
   1.350      <para id="x_1d3">Lorsque vous utilisez la commande <command
   1.351 -        role="hg-cmd">hg rename</command>, Mercurial crée uen copie de chaque
   1.352 -      fichier source, les supprime et marque ces fichiers comme étant
   1.353 +        role="hg-cmd">hg rename</command>, Mercurial crée une copie de tous
   1.354 +      les fichiers sources, les supprime et marque ces fichiers comme étant
   1.355        supprimés.</para>
   1.356  
   1.357      &interaction.daily.rename.rename;
   1.358  
   1.359      <para id="x_1d4">La commande <command role="hg-cmd">hg status</command>
   1.360 -      montre le nouveau fichier comme ajouté et le fichier origine comme
   1.361 -      supprimé.</para>
   1.362 +      montre les nouveaux fichiers comme ajoutés et les fichiers originaux
   1.363 +      comme supprimés.</para>
   1.364  
   1.365      &interaction.daily.rename.status;
   1.366  
   1.367      <para id="x_1d5">A cause du <command role="hg-cmd">hg	copy</command>,
   1.368        nous devons utiliser l'option <option role="hg-opt-status">-C</option>
   1.369 -      pour <command	role="hg-cmd">hg status</command> afin d'observer que le
   1.370 -      fichier ajouté est bien suivi par Mercurial comme étant une copie de
   1.371 -      l'original maintenant supprimé.</para>
   1.372 +      pour la commande <command	role="hg-cmd">hg status</command> afin
   1.373 +      d'observer que le fichier ajouté est bien suivi par Mercurial comme
   1.374 +      étant une copie de l'original maintenant supprimé.</para>
   1.375  
   1.376      &interaction.daily.rename.status-copy;
   1.377  
   1.378      <para id="x_1d6">Comme avec <command role="hg-cmd">hg remove</command> et
   1.379        <command role="hg-cmd">hg copy</command>, vous pouvez informer
   1.380 -      Mercurial à propos d'un renommage après coup en utilisant l'option
   1.381 +      Mercurial au sujet d'un renommage après coup en utilisant l'option
   1.382        <option role="hg-opt-rename">--after</option>. Dans le plus grand
   1.383 -      respet, le comportement de la commande <command role="hg-cmd">hg
   1.384 +      respect, le comportement de la commande <command role="hg-cmd">hg
   1.385          rename</command>, et les options qu'il accepte sont similaires à la
   1.386        commande <command role="hg-cmd">hg copy</command>.</para>
   1.387  
   1.388 -    <para id="x_686">Si vous êtes familié avec la ligne de commande Unix,
   1.389 +    <para id="x_686">Si vous êtes familier avec la ligne de commande Unix,
   1.390        vous serez heureux d'apprendre que la commande <command
   1.391          role="hg-cmd">hg rename</command> peut être invoquée par <command
   1.392          role="hg-cmd">hg mv</command>.</para>
   1.393 @@ -451,10 +452,9 @@
   1.394      <sect2>
   1.395        <title>Renommer les fichiers et fusionner (merge) les changements</title>
   1.396  
   1.397 -      <para id="x_1d7">Puise que le rename de Mercurial est implanté comme un
   1.398 -        "copy-and-remove", la même propagation des changements a lieue
   1.399 -        lorsque vous fusionnez (merge) après un "rename" qu'après un
   1.400 -        "copy".</para>
   1.401 +      <para id="x_1d7">Puise que le "rename" de Mercurial est implanté comme un
   1.402 +        "copy-and-remove", la même propagation des changements a lieue après
   1.403 +        un "rename" qu'après un "copy" lorsque vous fusionnez (merge).</para>
   1.404  
   1.405        <para id="x_1d8">Si je modifie un fichier et que vous le renommez, si
   1.406          ensuite nous fusionnons nos changements respectifs, mes modifications
   1.407 @@ -467,7 +467,7 @@
   1.408          est une fonctionnalité où vous hocheriez sûrement la tête en disant
   1.409          <quote>oui, cela pourrait être utile</quote>, il est clair que les
   1.410          voir suivre un renommage est définitivement important. Sans cette
   1.411 -        aptitude, il serait simplement trop facile d'avoir des changements
   1.412 +        aptitude, il serait vraiment trop facile d'avoir des changements
   1.413          qui deviennent orphelins lorsque des fichiers sont renommés.</para>
   1.414      </sect2>
   1.415  
   1.416 @@ -475,7 +475,7 @@
   1.417        <title>Renommages divergeants et fusion (merge)</title>
   1.418  
   1.419        <para id="x_1da">Le cas de noms divergeants a lieu lorsque deux
   1.420 -        développeurs commencent avec un fichier&emdash;apprelons le
   1.421 +        développeurs commencent avec un fichier&emdash;appelons le
   1.422          <filename>foo</filename>&emdash;dans leurs dépôts respectifs.</para>
   1.423  
   1.424        &interaction.rename.divergent.clone;
   1.425 @@ -525,7 +525,7 @@
   1.426  
   1.427        <para id="x_1e1">Mercurial possède un bug de longue date dans lequel il
   1.428          échoue à traiter une fusion (merge) où un coté a un fichier avec un
   1.429 -        nom donné, alors que l'autre coté a un répertoire avec le même nom.
   1.430 +        nom donné, alors que l'autre coté possède un répertoire avec le même nom.
   1.431          Ceci est documenté dans l'<ulink role="hg-bug"
   1.432            url="http://www.selenic.com/mercurial/bts/issue29">issue
   1.433            29</ulink>.</para>
   1.434 @@ -539,24 +539,24 @@
   1.435      <title>Récupération d'erreurs</title>
   1.436  
   1.437      <para id="x_1e2">Mercurial possède certaines commandes utiles qui vont
   1.438 -      vous aider à récupérer certaines erreurs communes.</para>
   1.439 +      vous aider à récupérer de certaines erreurs communes.</para>
   1.440  
   1.441      <para id="x_1e3">La commande <command role="hg-cmd">hg revert</command>
   1.442 -      vous permet d'annuler les changements que vous avez fait dans votre
   1.443 +      vous permet d'annuler les changements que vous avez faits dans votre
   1.444        répertoire de travail. Par exemple, si vous faites un <command
   1.445          role="hg-cmd">hg add</command> sur un fichier par accident, exécutez
   1.446        juste <command role="hg-cmd">hg	revert</command> avec le nom du fichier
   1.447 -      que vous avez ajouté et tandis que le fichier ne touché d'une
   1.448 +      que vous avez ajouté et tandis que le fichier ne sera touché d'une
   1.449        quelconque manière, il ne sera plus suivi comme ajouté par Mercurial.
   1.450        Vous pouvez aussi utiliser la commande <command role="hg-cmd">hg
   1.451 -        revert</command> pour vous débarasser de modifications erronés
   1.452 +        revert</command> pour vous débarrasser de modifications erronés
   1.453        apportées à un fichier.</para>
   1.454  
   1.455      <para id="x_1e4">Il est utile de se souvenir que la commande <command
   1.456          role="hg-cmd">hg revert</command> est utile pour les modifications
   1.457 -      qui n'ont pas encore été commitées. Une fois que vous avez committé un
   1.458 +      qui n'ont pas encore été committées. Une fois que vous avez committé un
   1.459        changement, si vous décidez qu'il s'agissait d'une erreur, vous pouvez
   1.460 -      toujours faire quelquechose à ce sujet, bien que vos options seront
   1.461 +      toujours faire quelque chose à ce sujet, bien que vos options soient
   1.462        un peu plus limitées.</para>
   1.463  
   1.464      <para id="x_1e5">Pour plus d'informations au sujet de la commande
   1.465 @@ -570,13 +570,13 @@
   1.466  
   1.467      <para id="x_687">Dans des projets compliqués ou conséquents, il n'est pas
   1.468        rare qu'une fusion (merge) de deux changesets finisse par une migraine.
   1.469 -      Supposez qu'il y a un gros fichier source qui a été largement édité de
   1.470 +      Supposez qu'il y ait un gros fichier source qui ait été largement édité de
   1.471        chaque coté de la fusion (merge) : ceci va inévitablement résulter en
   1.472 -      conflits, dont certains peuvent prendre quelques essais pour s'en
   1.473 +      conflits, dont certains peuvent prendre plusieurs essais pour s'en
   1.474        sortir.</para>
   1.475  
   1.476 -    <para id="x_688">Développons en un cas simple pour voir comment traiter
   1.477 -      avec. Nous allons commencer avec un dépôt contenant un fichier, et le
   1.478 +    <para id="x_688">Développons en un cas simple pour voir comment le gérer.
   1.479 +      Nous allons commencer avec un dépôt contenant un fichier, et le
   1.480        cloner deux fois.</para>
   1.481  
   1.482      &interaction.ch04-resolve.init;
   1.483 @@ -587,7 +587,7 @@
   1.484      &interaction.ch04-resolve.left;
   1.485  
   1.486      <para id="x_68a">Dans un autre, nous allons modifier le fichier
   1.487 -      différamment.</para>
   1.488 +      différemment.</para>
   1.489  
   1.490      &interaction.ch04-resolve.right;
   1.491  
   1.492 @@ -597,7 +597,7 @@
   1.493      &interaction.ch04-resolve.pull;
   1.494  
   1.495      <para id="x_68c">Nous nous attendons à ce que notre dépôt contienne deux
   1.496 -      HEADS.</para>
   1.497 +      "heads".</para>
   1.498  
   1.499      &interaction.ch04-resolve.heads;
   1.500  
   1.501 @@ -605,24 +605,24 @@
   1.502          merge</command> à ce point, il nous renverra vers une interface
   1.503        utilisateur qui nous permettra de résoudre manuellement les éditions
   1.504        conflictuelles sur le fichier <filename>myfile.txt</filename>.
   1.505 -      Cependant, pour simplifier les choses dans la présentation ici, nous
   1.506 -      aimerions que la fusion (merge) échoue immédiatement plutôt. Voici une
   1.507 +      Cependant, pour simplifier ici les choses dans la présentation, nous
   1.508 +      aimerions plutôt que la fusion (merge) échoue immédiatement. Voici une
   1.509        façon de le faire.</para>
   1.510  
   1.511      &interaction.ch04-resolve.export;
   1.512  
   1.513 -    <para id="x_68e">Nous avons dit à la machinerie de fusion de Mercurial
   1.514 +    <para id="x_68e">Nous avons dit au processus de fusion de Mercurial
   1.515        d'exécuter la commande <command>false</command> (qui échoue
   1.516        immédiatement, à la demande) s'il détecte une fusion (merge) qu'il ne
   1.517        peut pas arranger automatiquement.</para>
   1.518  
   1.519      <para id="x_68f">Si nous appelons maintenant <command role="hg-cmd">hg
   1.520 -        merge</command>, il devrait planter et reporter une erreur.</para>
   1.521 +        merge</command>, il devrait échouer et reporter une erreur.</para>
   1.522  
   1.523      &interaction.ch04-resolve.merge;
   1.524  
   1.525      <para id="x_690">Même si nous ne remarquons pas qu'une fusion (merge) a
   1.526 -      échoué, Mercurial nous empéchera de committer le résultat d'une fusion
   1.527 +      échoué, Mercurial nous empêchera de committer le résultat d'une fusion
   1.528        ratée.</para>
   1.529  
   1.530      &interaction.ch04-resolve.cifail;
   1.531 @@ -634,10 +634,10 @@
   1.532        sommaire.</para>
   1.533  
   1.534      <sect2>
   1.535 -      <title>Etats de résolution des fichiers</title>
   1.536 +      <title>États de résolution des fichiers</title>
   1.537        <!-- TODO Vérifier traduction : File resolution states -->
   1.538  
   1.539 -      <para id="x_692">Lorsqu'une fusion intervient, la plupart des fichier
   1.540 +      <para id="x_692">Lorsqu'une fusion intervient, la plupart des fichiers
   1.541          vont, la plupart du temps, rester sans modification. Pour chaque
   1.542          fichier sur lequel Mercurial doit faire quelque chose, il suit l'état
   1.543          de celui-ci.</para>
   1.544 @@ -654,11 +654,11 @@
   1.545          </listitem>
   1.546        </itemizedlist>
   1.547  
   1.548 -      <para id="x_695">Si Mercurial voit <emphasis>n'importe quel</emphasis>
   1.549 -        fichier dans un état <quote>unresolved</quote> après une fusion
   1.550 -        (merge), il considère que la fusion (merge) a échoué. Heureusement,
   1.551 -        nous n'avons pas à recommencer la fusion (merge) à partir du
   1.552 -        début.</para>
   1.553 +      <para id="x_695">Si Mercurial voit un fichier
   1.554 +        <emphasis>quelconque</emphasis> dans un état
   1.555 +        <quote>unresolved</quote> après une fusion (merge), il considère que
   1.556 +        la fusion (merge) a échoué. Heureusement, nous n'avons pas à
   1.557 +        recommencer la procédure à partir du début.</para>
   1.558  
   1.559        <para id="x_696">L'option <option role="hg-opt-resolve">--list</option>
   1.560          ou <option role="hg-opt-resolve">-l</option> passée à <command
   1.561 @@ -672,7 +672,7 @@
   1.562          <literal>R</literal>, alors qu'un fichier "unresolved" est marqué
   1.563          d'un <literal>U</literal>.  S'il existe un fichier listé avec un
   1.564          <literal>U</literal>, nous savons qu'essayer de committer le résultat
   1.565 -        de la fusion (merge) échoura.</para>
   1.566 +        de la fusion (merge) échouera.</para>
   1.567      </sect2>
   1.568  
   1.569      <sect2>
   1.570 @@ -692,26 +692,28 @@
   1.571          en utilisant l'option <option role="hg-opt-resolve">--mark</option>,
   1.572          ou "unresolved" en utilisant l'option <option
   1.573            role="hg-opt-resolve">--unmark</option>. Ceci nous autorise à
   1.574 -        nettoyer une fusion particulièrement compliqué à la main, et de
   1.575 +        nettoyer une fusion particulièrement compliquée à la main, et de
   1.576          garder un suivi de nos progrès avec chaque fichier pendant que nous
   1.577          procédons.</para>
   1.578      </sect2>
   1.579    </sect1>
   1.580  
   1.581    <sect1>
   1.582 -    <title>Des diffs plus utiles</title>
   1.583 +    <title>Des "diffs" plus utiles</title>
   1.584  
   1.585      <para id="x_6c7">La sortie par défaut de la commande <command
   1.586 -        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.587 +        role="hg-cmd">hg diff</command> est compatible rétrospectivement avec
   1.588 +      la commande régulière <command>diff</command>, mais ceci a quelques
   1.589 +      inconvénients.</para>
   1.590  
   1.591      <para id="x_6c8">Considérez le cas où nous utilisons <command role="hg-cmd">hg
   1.592          rename</command> pour renommer un fichier.</para>
   1.593  
   1.594      &interaction.ch04-diff.rename.basic;
   1.595  
   1.596 -    <para id="x_6c9">La sortie de <command role="hg-cmd">hg diff</command> ci
   1.597 -      dessus cache le fait que nous avons simplement renommé un fichier. La
   1.598 -      commande <command	role="hg-cmd">hg diff</command> accepte l'option
   1.599 +    <para id="x_6c9">La sortie de <command role="hg-cmd">hg diff</command>
   1.600 +      ci-dessus cache le fait que nous avons simplement renommé un fichier.
   1.601 +      La commande <command role="hg-cmd">hg diff</command> accepte l'option
   1.602        <option>--git</option> ou <option>-g</option> pour utiliser un nouveau
   1.603        format de diff qui montre ces informations sous une forme plus
   1.604        expressive.</para>
   1.605 @@ -737,17 +739,17 @@
   1.606    </sect1>
   1.607  
   1.608    <sect1>
   1.609 -    <title>Quels fichiers gérer et lesquels éviter</title>
   1.610 +    <title>Quels fichiers suivre et lesquels éviter</title>
   1.611  
   1.612      <para id="x_6cc">Les systèmes de gestion de révisions sont en général
   1.613        meilleurs pour gérer les fichiers textes qui sont écrits par les
   1.614        humains, comme le code source, où les fichiers ne changent pas
   1.615        énormément d'une révision à l'autre. Certains systèmes de gestion de
   1.616 -      révisions centralisés peuvent aussi traiter très correctement les
   1.617 -      fichiers binaires, comme les images bitmap.</para>
   1.618 +      révisions centralisés peuvent aussi traiter très convenablement les
   1.619 +      fichiers binaires, tels que les images bitmap.</para>
   1.620  
   1.621      <para id="x_6cd">Par exemple, une équipe de développement de jeux va
   1.622 -      probablement gérer les deux : ses codes source et tous ses binaires
   1.623 +      probablement gérer les deux types : ses codes source et tous ses binaires
   1.624        (ex. données géométriques, textures, schémas de cartes) dans un système
   1.625        de contrôle de révisions.</para>
   1.626      <!-- Vérifier la traduction de map layouts que j'ai traduit par schémas
   1.627 @@ -755,21 +757,21 @@
   1.628  
   1.629      <para id="x_6ce">Puisqu'il est d'habitude impossible de fusionner (merge)
   1.630        deux modifications conflictuelles sur un fichier binaire, les systèmes
   1.631 -      de version centralisé offre souvent un mécanisme de verrou (lock) qui
   1.632 +      de version centralisés offrent souvent un mécanisme de verrou (lock) qui
   1.633        permet à un utilisateur de dire <quote>Je suis la seule personne qui
   1.634          peut éditer ce fichier</quote>.</para>
   1.635  
   1.636 -    <para id="x_6cf">En comparaison d'un système centralisé, un système
   1.637 +    <para id="x_6cf">En comparaison avec un système centralisé, un système
   1.638        décentralisé de gestion de révision change certains facteurs qui
   1.639        guident les décisions sur quels fichiers gérer et comment.</para>
   1.640  
   1.641 -    <para id="x_6d0">Par exemple, un système distribé de gestion de révisions
   1.642 -      ne peut pas, par sa nature, offrir un système de vérrous (lock) sur les
   1.643 -      fichiers. Il n'y a donc pas de mécanisme inclu pour empécher deux
   1.644 +    <para id="x_6d0">Par exemple, un système distribué de gestion de révisions
   1.645 +      ne peut pas, par sa nature, offrir un système de véroux (lock) sur les
   1.646 +      fichiers. Il n'y a donc pas de mécanisme inclus pour empêcher deux
   1.647        personnes de faire des modifications conflictuelles sur un fichier
   1.648        binaire. Si vous avez une équipe où plusieurs personnes peuvent souvent
   1.649        éditer un fichier binaire, cela ne serait pas une très bonne idée
   1.650 -      d'utiliser Mercurial &emdash;ou tout autre système distribé de gestion
   1.651 +      d'utiliser Mercurial &emdash;ou tout autre système distribué de gestion
   1.652        de révisions&emdash;pour gérer ces fichiers.</para>
   1.653  
   1.654      <para id="x_6d1">Lorsque vous sauvegardez les modifications sur un
   1.655 @@ -779,12 +781,12 @@
   1.656        fichiers (en particulier les fichiers binaires) sont construits d'une
   1.657        façon que même un petit changement sur un contenu logique résulte sur
   1.658        un changement de la plupart des octets du fichier. Par exemple, les
   1.659 -      fichiers compressés sont particulièrement suceptibles à ce
   1.660 -      comportement. Si les différences entre deux versions successives d'un
   1.661 -      fichier sont toujours très grandes, Mercurial ne sera pas capable de
   1.662 -      sauvegarder l'historique des révisions sur le fichier très
   1.663 -      efficacement. Ceci peut affecter aussi bien les besoins locaux pour
   1.664 -      sauvegarder que le temps nécessaire à cloner le dépôt.</para>
   1.665 +      fichiers compressés sont particulièrement sujets à ce comportement. Si
   1.666 +      les différences entre deux versions successives d'un fichier sont
   1.667 +      toujours très grandes, Mercurial ne sera pas capable de sauvegarder
   1.668 +      l'historique des révisions sur le fichier très efficacement. Ceci peut
   1.669 +      affecter aussi bien les besoins pour la sauvegarde locale que le temps
   1.670 +      nécessaire à cloner le dépôt.</para>
   1.671  
   1.672      <para id="x_6d2">Pour avoir une idée de comment ceci pourrait vous
   1.673        affecter en pratique, supposez que nous voulions que Mercurial gère des
   1.674 @@ -795,8 +797,8 @@
   1.675        fasse une taille de 2Mo. Puisque la plupart du fichier change à chaque
   1.676        fois que vous sauvegardez, Mercurial aura à sauvegarder tous les 2Mo du
   1.677        fichier à chaque commit, alors que de votre point de vue, il n'y a
   1.678 -      seulement que peu de mots qui changent à chaque fois. Un seul fichier
   1.679 -      souvent édité qui n'est pas bien connu des hypothèses que Mercurial
   1.680 +      que peu de mots qui changent à chaque fois. Un seul fichier
   1.681 +      souvent édité qui n'est pas bien traité par les hypothèses que Mercurial
   1.682        fait sur les sauvegardes peut facilement avoir un effet colossal sur la
   1.683        taille du dépôt.</para>
   1.684  
   1.685 @@ -806,20 +808,20 @@
   1.686        utile de montrer que les différences sont faites à partir de votre
   1.687        vision des modifications.</para>
   1.688  
   1.689 -    <para id="x_6d4">Il y a ainsi quelques recommendations claires sur les
   1.690 +    <para id="x_6d4">Il y a ainsi quelques recommandations claires sur les
   1.691        types de fichiers spécifiques avec lesquels faire très
   1.692        attention.</para>
   1.693  
   1.694      <itemizedlist>
   1.695        <listitem><para id="x_6d5">Les fichier qui sont très gros et
   1.696 -          imcompressibles, comme les images ISO de CD-ROM, sont, par
   1.697 +          incompressibles, comme les images ISO de CD-ROM, sont, par
   1.698            construction très gros et les cloner à travers un réseau sera très
   1.699            long.</para></listitem>
   1.700 -     <!-- Trouver une meilleure traduction pour : ISO CD-ROM images, will by
   1.701 +     <!-- TODO : Trouver une meilleure traduction pour : ISO CD-ROM images, will by
   1.702       virtue of sheer size make clones over a network very slow. -->
   1.703        <listitem><para id="x_6d6">Les fichiers qui changent beaucoup d'une
   1.704            révision à l'autre peuvent être très chers à sauvegarder si vous
   1.705 -          les éditez fréquement, de même que les conflits entre deux éditions
   1.706 +          les éditez fréquemment, de même que les conflits entre deux éditions
   1.707            concurrentes peuvent être difficiles à résoudre.</para>
   1.708        </listitem>
   1.709      </itemizedlist>
   1.710 @@ -831,7 +833,7 @@
   1.711      <para id="x_6d7">Puisque Mercurial maintient une copie complète de
   1.712        l'historique de chaque clone, toute personne qui utilise Mercurial pour
   1.713        collaborer à un projet peut potentiellement agir comme une source de
   1.714 -      sauvegarde si une catastrophe avait lieue. Si un dépôt central devient
   1.715 +      sauvegarde si une catastrophe survenait. Si un dépôt central devient
   1.716        indisponible, vous pouvez construire un remplaçant en clonant une copie
   1.717        du dépôt à partir d'un des contributeurs en récupérant (pull) tous les
   1.718        changements qui n'auraient pas été vus par les autres.</para>
   1.719 @@ -840,24 +842,24 @@
   1.720        serveurs hors site de sauvegarde et des miroirs distants. Initiez une
   1.721        tâche périodique (ex. via la commande <command>cron</command>) sur un
   1.722        serveur distant pour récupérer (pull) les changements de votre dépôt
   1.723 -      distant chaque heure. Ceci sera difficile seullement dans le cas
   1.724 +      distant chaque heure. Ceci sera difficile seulement dans le cas
   1.725        improbable où le nombre des dépôts maîtres que vous maintenez change
   1.726        souvent, auquel cas vous aurez besoin de faire un peu de scripting pour
   1.727 -      raffraichir la liste des dépôt à sauvegarder.</para>
   1.728 +      rafraichir la liste des dépôt à sauvegarder.</para>
   1.729  
   1.730      <para id="x_6d9">Si vous exécutez des sauvegardes traditionnelles de
   1.731 -      votre dépôt maître sur des bandes ou disques, et que vous voulez
   1.732 -      sauvegarder un dépôt nommé <filename>myrepo</filename>, utilisez la
   1.733 -      commande <command>hg clone -U myrepo myrepo.bak</command> pour créer un
   1.734 -      clone de <filename>myrepo</filename> avant de commencer vos backups.
   1.735 +      votre dépôt maître sur bande ou disque, et que vous voulez sauvegarder
   1.736 +      un dépôt nommé <filename>myrepo</filename>, utilisez la commande
   1.737 +      <command>hg clone -U myrepo myrepo.bak</command> pour créer un clone de
   1.738 +      <filename>myrepo</filename> avant de commencer vos backups.
   1.739        L'option <option>-U</option> ne crée pas de répertoire de travail après
   1.740        que le clone soit accompli, puisque ceci serait superflu et ferait que
   1.741        la sauvegarde prenne plus de temps.</para>
   1.742  
   1.743      <para id="x_6da">Si vous voulez ensuite sauvegarder
   1.744        <filename>myrepo.bak</filename> au lieu de <filename>myrepo</filename>,
   1.745 -      vous aurez la garantie d'avoir une image (snapshot) consistente de
   1.746 -      votre dépôt sur lequel un développeur insomniac n'enverra (push) pas de
   1.747 +      vous aurez la garantie d'avoir une image (snapshot) consistante de
   1.748 +      votre dépôt sur lequel un développeur insomniaque n'enverra (push) pas de
   1.749        changements en milieu de sauvegarde.</para>
   1.750    </sect1>
   1.751  </chapter>