1.1 --- a/fr/ch00-preface.xml	Mon Sep 14 01:31:50 2009 +0200
     1.2 +++ b/fr/ch00-preface.xml	Tue Sep 15 13:43:02 2009 +0200
     1.3 @@ -7,16 +7,16 @@
     1.4    <sect1>
     1.5      <title>Un conte technique</title>
     1.6  
     1.7 -    <para id="x_72e">Il y a quelques années, quand j'ai voulu expliqué
     1.8 -    pourquoi je pensais que le gestion de révision distribuée est importante,
     1.9 +    <para id="x_72e">Il y a quelques années, quand j'ai voulu expliquer
    1.10 +    pourquoi je pensais que la gestion de révisions distribuée était importante,
    1.11      le domaine était encore si nouveau qu'il n'y avait presque aucune 
    1.12      littérature publiée pour servir de référence aux personnes intéressées.</para>
    1.13  
    1.14      <para id="x_72f">Bien qu'à cette époque je passais beaucoup de temps
    1.15      à travailler sur les entrailles de Mercurial, je me suis mis à la 
    1.16 -    rédaction de ce livre parce qu'il me semblait la manière la plus efficace
    1.17 +    rédaction de ce livre parce que ça me semblait être la manière la plus efficace
    1.18      d'aider notre logiciel à atteindre un vaste auditoire, toujours avec 
    1.19 -    l'idée que la gestion de révision devrait être distribuée par nature. J'ai 
    1.20 +    l'idée que la gestion de révisions devrait être distribuée par nature. J'ai 
    1.21      publié ce libre en ligne sous une licence libre pour la même raison : pour 
    1.22      diffuser la parole auprès du monde.</para>
    1.23  
    1.24 @@ -24,7 +24,7 @@
    1.25      qui ressemble de près au fait de conter une histoire : Pourquoi ceci est ? 
    1.26      Pourquoi ceci est important ? Comment peut il m'aider ? Comment m'en 
    1.27      servir ? Dans ce livre, j'essaye de répondre à toutes ces questions pour
    1.28 -    la gestion de révision distribuée en général, et pour Mercurial en 
    1.29 +    la gestion de révisions distribuée en général, et pour Mercurial en 
    1.30      particulier.</para>
    1.31    </sect1>
    1.32      
    1.33 @@ -61,18 +61,18 @@
    1.34      Fitzhardinge, Rachel Chalmers.</para>
    1.35  
    1.36      <para id="x_735">J'ai conçu ce livre de manière ouverte, en publiant
    1.37 -    des brouillons des chapitres du livre sur des site web, au fur et à 
    1.38 +    des brouillons de chapitres du livre sur des site web, au fur et à 
    1.39      mesure que je les réalisais. Leurs lecteurs m'ont fait des retours 
    1.40      utilisant l'application web que j'avais développée. A la fin de sa
    1.41      conception, plus de 100 personnes m'avaient fait des commentaires, 
    1.42 -    un chiffre incroyable quand l'on considère que ce système de 
    1.43 +    un chiffre incroyable quand on considère que ce système de 
    1.44      commentaire n'a tourné que dans les deux derniers mois de la 
    1.45      rédaction du livre.</para>
    1.46  
    1.47      <para id="x_736">J'aimerais particulièrement remercier les 
    1.48      personnes suivantes, dont les commentaires représentent plus
    1.49 -    d'un tiers de l'ensemble de ces derniers. Je voudrais les 
    1.50 -    remercier pour leur attention et effort à me faire des retours
    1.51 +    d'un tiers de l'ensemble de ces derniers. Je voudrai les 
    1.52 +    remercier pour leurs attentions et efforts à me faire des retours
    1.53      très détaillés.</para>
    1.54  
    1.55      <para id="x_737">Martin Geisler, Damien Cassou, Alexey Bakhirkin, Till Plewe,
    1.56 @@ -142,7 +142,7 @@
    1.57          <term><userinput>Taille constante avec gras</userinput></term>
    1.58  
    1.59          <listitem>
    1.60 -          <para id="x_73d">Afficher les commandes ou autres textes qui
    1.61 +          <para id="x_73d">Affiche les commandes ou autres textes qui
    1.62            devraient être saisis par l'utilisateur.</para>
    1.63          </listitem>
    1.64        </varlistentry>

     2.1 --- a/fr/ch01-intro.xml	Mon Sep 14 01:31:50 2009 +0200
     2.2 +++ b/fr/ch01-intro.xml	Tue Sep 15 13:43:02 2009 +0200
     2.3 @@ -5,17 +5,18 @@
     2.4    <title>Comment en est on arrivé là ?</title>
     2.5  
     2.6  <sect1>
     2.7 -<title>À propos de la gestion source</title>
     2.8 -
     2.9 -    <para id="x_6d">La gestion de sources est un processus permettant de gérer différentes
    2.10 +<title>À propos de la gestion de révisions. Pourquoi Mercurial ?</title>
    2.11 +
    2.12 +    <para id="x_6d">La gestion de révisions est un processus permettant de gérer différentes
    2.13  versions de la même information. Dans sa forme la plus simple, c'est
    2.14  ce que tout le monde fait manuellement : quand vous modifiez
    2.15  un fichier, vous le sauvegardez sous un nouveau nom contenant un numéro,
    2.16  à chaque fois plus grand que celui de la version précédente.</para>
    2.17  
    2.18 -    <para id="x_6e">Ce genre de gestion de version manuelle est cependant facilement sujette
    2.19 +    <para id="x_6e">Ce genre de gestion de révisions manuelle, ne serait-ce que 
    2.20 +        d'un seul fichier, est cependant facilement sujette
    2.21  aux erreurs, ainsi, depuis longtemps, des logiciels existent pour
    2.22 -résoudre cette problématique. Les premiers outils de gestion de sources
    2.23 +résoudre cette problématique. Les premiers outils de gestion de révisions
    2.24  étaient destinés à aider un seul utilisateur, à automatiser la gestion
    2.25  des versions d'un seul fichier. Dans les dernières décades, cette cible
    2.26  s'est largement agrandie, ils gèrent désormais de multiples fichiers, et
    2.27 @@ -24,23 +25,23 @@
    2.28  personnes travaillant ensemble sur des projets regroupant plusieurs
    2.29  centaines de milliers de fichiers.</para>
    2.30  
    2.31 -    <para id="x_6f">L'arrivée de la gestion de révision distribuée est
    2.32 +    <para id="x_6f">L'arrivée de la gestion de révisions distribuée est
    2.33      relativement récente, et, pour le moment, ce nouveau domaine a grandi
    2.34      grâce à la volonté des gens d'explorer ces territoires encore inconnus.
    2.35      </para>
    2.36  
    2.37 -    <para id="x_70">J'écris un livre sur la gestion de révision distribuée
    2.38 +    <para id="x_70">J'écris un livre sur la gestion de révisions distribuée
    2.39      parce que je pense qu'il s'agit d'un sujet important qui mérite un guide
    2.40 -    du terrain. J'ai choisi d'écrire un livre sur Mercurial car il est
    2.41 +    de terrain. J'ai choisi d'écrire un livre sur Mercurial car il est
    2.42      l'outil le plus facile pour découvrir ce nouveau domaine, tout en étant
    2.43      un outil efficace qui répond aux demandes d'environnements réels et
    2.44 -    difficiles, là où d'autres outils de gestions de versions s'effondrent.</para>
    2.45 +    difficiles, là où d'autres outils de gestion de révisions s'effondrent.</para>
    2.46  
    2.47      <sect2>
    2.48 -      <title>Pourquoi utiliser un gestionnaire de source ?</title>
    2.49 +      <title>Pourquoi utiliser un gestionnaire de révisions ?</title>
    2.50  
    2.51        <para id="x_71">Il y a de nombreuses raisons pour que vous ou votre équipe souhaitiez
    2.52 -utiliser un outil automatisant la gestion de version pour votre projet.</para>
    2.53 +utiliser un outil automatisant la gestion de révisions pour votre projet.</para>
    2.54  
    2.55        <itemizedlist>
    2.56  	<listitem><para id="x_72">L'outil se chargera de suivre l'évolution de votre projet, sans
    2.57 @@ -50,14 +51,14 @@
    2.58  <emphasis>ce</emphasis> qu'il a modifié.</para>
    2.59  </listitem>
    2.60  <listitem><para id="x_73">Quand vous travaillez avec d'autres personnes, les logiciels de
    2.61 -gestion de source facilitent le travail collaboratif. Par exemple, quand
    2.62 +gestion de révisions facilitent le travail collaboratif. Par exemple, quand
    2.63  plusieurs personnes font, plus ou moins simultanément, des modifications
    2.64  incompatibles, le logiciel vous aidera à identifier et à résoudre les conflits.</para>
    2.65  </listitem>
    2.66  <listitem><para id="x_74">L'outil vous aidera à réparer vos erreurs. Si vous effectuez un changement
    2.67  qui se révèle être une erreur, vous pourrez revenir à une version
    2.68  antérieure d'un fichier ou même d'un ensemble de fichiers. En fait, un outil de
    2.69 -gestion de source <emphasis>vraiment</emphasis> efficace vous permettra d'identifier à quel
    2.70 +gestion de révisions <emphasis>vraiment</emphasis> efficace vous permettra d'identifier à quel
    2.71  moment le problème est apparu (voir la section <xref linkend="sec:undo:bisect"/> pour plus
    2.72  de détails).</para>
    2.73  </listitem>
    2.74 @@ -65,27 +66,27 @@
    2.75  de votre projet et de gérer l'écart entre chacune.</para>
    2.76  </listitem></itemizedlist>
    2.77  <para id="x_76">La plupart de ces raisons ont autant d'importances &emdash;du
    2.78 -  moins en théorie&emdash; que vous travailliez sur un projet pour vous, ou
    2.79 +  moins en théorie&emdash; que vous travailliez seul sur un projet, ou
    2.80    avec une centaine d'autres personnes.
    2.81  </para>
    2.82  
    2.83  <para id="x_77">Une question fondamentale à propos des outils de gestion de
    2.84 -  source, qu'il s'agisse du projet d'une personne ou d'une grande équipe, est
    2.85 -  quels sont ses <emphasis>avantages</emphasis> par rapport à ses
    2.86 -  <emphasis>coûts</emphasis>. Un outil qui est difficile à utiliser ou à
    2.87 +  révisions, qu'il s'agisse du projet d'une personne ou d'une grande équipe, est
    2.88 +  quels sont ses <emphasis>gains</emphasis> par rapport à ses
    2.89 +  <emphasis>coût</emphasis>. Un outil qui est difficile à utiliser ou à
    2.90    comprendre exigera un lourd effort d'adaptation.
    2.91  </para>
    2.92  
    2.93 -<para id="x_78">)Un projet de cinq milles personnes s'effondrera très
    2.94 +<para id="x_78">Un projet de cinq milles personnes s'effondrera très
    2.95    certainement de lui même sans aucun processus et outil de gestion de
    2.96 -  source. Dans ce cas, le coût d'utilisation d'un logiciel de gestion de
    2.97 -  source est dérisoire puisque <emphasis>sans</emphasis>, l'échec est presque
    2.98 +  révisions. Dans ce cas, le coût d'utilisation d'un logiciel de gestion de
    2.99 +  révisions est dérisoire puisque <emphasis>sans</emphasis>, l'échec est presque
   2.100    garanti.
   2.101  </para>
   2.102  
   2.103  <para id="x_79">D'un autre coté, un <quote>rapide hack</quote> d'une personne
   2.104    peut sembler un contexte bien pauvre pour utiliser un outil de gestion de
   2.105 -  source, car, bien évidement le coût d'utilisation dépasse le coût total du
   2.106 +  révisions, car, bien évidement le coût d'utilisation dépasse le coût total du
   2.107    projet. N'est ce pas ?
   2.108  </para>
   2.109  
   2.110 @@ -93,7 +94,7 @@
   2.111          échelles de travail. Vous pouvez apprendre les bases en quelques
   2.112          minutes seulement, et, grâce à sa performance, vous pouvez l'utiliser
   2.113          avec facilité sur le plus petit des projets. Cette simplicité
   2.114 -        signifie que vous n'avez pas de concept obscurs ou de séquence de
   2.115 +        signifie que vous n'avez pas de concept obscur ou de séquence de
   2.116          commandes défiant l'imagination, sans aucune corrélation avec
   2.117          <emphasis>ce que vous êtes entrain de faire</emphasis>. En même
   2.118          temps, ces mêmes performances et sa nature
   2.119 @@ -101,7 +102,7 @@
   2.120          difficulté, son utilisation à de très grands projets.
   2.121  </para>
   2.122  
   2.123 -      <para id="x_7b">Aucun outil de gestion de source ne peut sauver un
   2.124 +      <para id="x_7b">Aucun outil de gestion de révisions ne peut sauver un
   2.125          projet mal mené, mais un bon outil peut rendre beaucoup plus fluide
   2.126          votre travail.
   2.127  </para>
   2.128 @@ -113,7 +114,7 @@
   2.129  
   2.130        <para id="x_7c">La gestion de source
   2.131          <!-- TODO:<footnote><J'ai utilisé systématiquement le terme
   2.132 -            <quote>gestion de source</quote> à travers tout l'ouvrage. Ce
   2.133 +            <quote>gestion de révisions</quote> à travers tout l'ouvrage. Ce
   2.134              n'est pas forcement la meilleure traduction, et ceci peut rendre
   2.135              la lecture un peu lourde, mais je pense que le document y gagne
   2.136              en clarté et en précision. -->
   2.137 @@ -148,13 +149,13 @@
   2.138  
   2.139    <sect1>
   2.140  
   2.141 -<title>A propos des exemples dans ce livre</title>
   2.142 -
   2.143 -    <para id="x_84">Ce livre prend une approche non usuel pour les exemples
   2.144 +<title>À propos des exemples dans ce livre</title>
   2.145 +
   2.146 +    <para id="x_84">Ce livre prend une approche non usuelle pour les exemples
   2.147        de code. Tous les exemples sont en <quote>live</quote> &emdash; Chacun
   2.148        est actuellement le résultat d'un script shell qui exécute les
   2.149        commandes Mercurial que vous voyez. A chaque fois qu'une image du livre
   2.150 -      est construite à partir des sources, tous les scripts d'exemple sont
   2.151 +      est construite à partir des sources, tous les scripts d'exemples sont
   2.152        lancés automatiquement, et leurs résultats effectifs sont comparés aux
   2.153        résultats attendus.</para>
   2.154  
   2.155 @@ -185,7 +186,7 @@
   2.156      <para id="x_88">Donc, lorsque vous lisez ces exemples, ne prêtez pas trop
   2.157        d'importance aux dates et heures que vous voyez dans la sortie des
   2.158        commandes. Cependant, <emphasis>soyez</emphasis> confiants que le
   2.159 -      comportement que vous voyez est consistent et reproductible 
   2.160 +      comportement que vous voyez est constant et reproductible 
   2.161      </para>
   2.162  
   2.163    </sect1>
   2.164 @@ -193,7 +194,7 @@
   2.165  <!-- The next section has disapper from this part of the book. it may be splaced somewhere else... t-->
   2.166  
   2.167    <sect1>
   2.168 -    <title>Tendances de la gestion de source</title>
   2.169 +    <title>Tendances de la gestion de révisions</title>
   2.170  
   2.171      <para id="x_89">Il y a eu une tendance évidente dans le développement et
   2.172        l'utilisation d'outils de gestion de source depuis les quatre dernières
   2.173 @@ -213,7 +214,7 @@
   2.174        adoptant une architecture réseau et centralisée, permettant de gérer
   2.175        plusieurs projets entiers en même temps. Alors que les projets
   2.176        grandirent en taille, ils rencontrèrent de nouveaux problèmes. Avec les
   2.177 -      clients discutant régulièrement avec le serveurs, la montée en charge
   2.178 +      clients discutant régulièrement avec le serveur, la montée en charge
   2.179        devint un réel problème sur les gros projets. Une connexion réseau peu
   2.180        fiable pouvait complètement empêcher les utilisateurs distants de
   2.181        dialoguer avec le serveur. Alors que les projets <emphasis
   2.182 @@ -224,10 +225,10 @@
   2.183        comme ils ne pouvaient pas non plus enregistrer leurs modifications.
   2.184      </para>
   2.185  
   2.186 -    <para id="x_8c">La génération actuelle des outils de gestion de source
   2.187 +    <para id="x_8c">La génération actuelle des outils de gestion de révisions
   2.188        est <quote>peer-to-peer</quote> par nature. Tous ces systèmes ont
   2.189 -      abandonné la dépendance à un serveur central, et ont permis à leur
   2.190 -      utilisateur de distribuer les données de leur gestion de source à qui
   2.191 +      abandonné la dépendance à un serveur central, et ont permis à leurs
   2.192 +      utilisateurs de distribuer les données de leur gestion de révisions à qui
   2.193        en a besoin. La collaboration à travers Internet a transformé la
   2.194        contrainte technologique en une simple question de choix et de
   2.195        consensus. Les outils modernes peuvent maintenant fonctionner en mode
   2.196 @@ -238,12 +239,12 @@
   2.197    </sect1>
   2.198      
   2.199    <sect1>
   2.200 -    <title>Quelques avantages des gestionnaires de source distribués</title>
   2.201 +    <title>Quelques avantages des gestionnaires de révisions distribués</title>
   2.202        
   2.203 -    <para id="x_8d">Même si les gestionnaire de source distribués sont depuis
   2.204 +    <para id="x_8d">Même si les gestionnaire de révisions distribués sont depuis
   2.205        plusieurs années assez robustes et aussi utilisables que leurs
   2.206        prédécesseurs, les utilisateurs d'autres outils n'y ont pas encore été
   2.207 -      sensibilisés. Les gestionnaires de source distribués se distinguent
   2.208 +      sensibilisés. Les gestionnaires de révisions distribués se distinguent
   2.209        particulièrement de leurs équivalents centralisés de nombreuses
   2.210        manières.
   2.211      </para>
   2.212 @@ -256,7 +257,7 @@
   2.213        stocke toute ses métadonnées localement. À tâche égale, effectuer un
   2.214        échange avec le réseau ajoute un délai aux outils centralisés. Ne
   2.215        sous-estimez pas la valeur d'un outil rapide : vous allez passer
   2.216 -      beaucoup de temps à interagir avec un logiciel de gestion de source.
   2.217 +      beaucoup de temps à interagir avec un logiciel de gestion de révisions.
   2.218      </para>
   2.219  
   2.220      <para id="x_8f">Les outils distribués sont complètement indépendants des
   2.221 @@ -264,7 +265,7 @@
   2.222        à beaucoup d'endroits. Si votre serveur central prend feu, vous avez
   2.223        intérêt à ce que les médias de sauvegardes soient fiables, et que votre
   2.224        dernier <quote>backup</quote> soit récent et fonctionne sans problème.
   2.225 -      Avec un outil distribué, vous avez autant de <quote>backup</quote> que
   2.226 +      Avec un outil distribué, vous avez autant de <quote>backups</quote> que
   2.227        de contributeurs.
   2.228      </para>
   2.229  
   2.230 @@ -275,7 +276,7 @@
   2.231        pendant que vous travaillez, vous pouvez ne même pas vous en rendre
   2.232        compte. La seule chose que vous ne serez pas capable de faire sera de
   2.233        communiquer avec des dépôts distants, opération somme toute assez rare
   2.234 -      en comparaison aux opérations locales. Si vous avez une équipe de
   2.235 +      en comparaison des opérations locales. Si vous avez une équipe de
   2.236        collaborateurs très dispersée ceci peut être significatif.
   2.237      </para>
   2.238  
   2.239 @@ -285,7 +286,7 @@
   2.240        <para id="x_91">Si vous prenez goût à un projet <emphasis
   2.241            remap="it">Open Source</emphasis> et que vous décidez de commencer
   2.242          à toucher à son code, et que le projet utilise un gestionnaire de
   2.243 -        source distribué, vous êtes immédiatement un "pair" avec les
   2.244 +        révisions distribué, vous êtes immédiatement un "pair" avec les
   2.245          personnes formant le <quote>cœur</quote> du projet. S'ils publient
   2.246          leurs dépôts, vous pouvez immédiatement copier leurs historiques de
   2.247          projet, faire des modifications, enregistrer votre travail en
   2.248 @@ -303,7 +304,7 @@
   2.249        <title>Le non-problème du "fork"</title>
   2.250        
   2.251        <para id="x_92">Il a été souvent suggéré que les gestionnaires de
   2.252 -        source distribués posent un risque pour les projets <emphasis
   2.253 +        révisions distribués posent un risque pour les projets <emphasis
   2.254            remap="it">Open Source</emphasis> car ils facilitent grandement la
   2.255          création de <quote>fork</quote>.
   2.256          <!--footnote{NdT:Création d'une <ulink url="version alternative du
   2.257 @@ -332,7 +333,7 @@
   2.258          probablement la <emphasis>meilleure</emphasis> façon de développer un
   2.259          projet. Chaque modification que vous effectuez est potentiellement un
   2.260          <quote>fork</quote>. La grande force de cette approche est que les
   2.261 -        gestionnaires de source distribués doivent être vraiment très
   2.262 +        gestionnaires de révisions distribués doivent être vraiment très
   2.263          efficaces pour <emphasis>fusionner (merge)</emphasis>
   2.264          <!-- TODO footnote{NdT:j'ai choisi de traduire ici <emphasis
   2.265            remap="it">merging</emphasis> par <quote>fusionner</quote> pour des
   2.266 @@ -345,7 +346,7 @@
   2.267          moment, est vue comme un <quote>fork</quote> à fusionner, alors ce
   2.268          que le monde de l'<emphasis remap="it">Open Source</emphasis> voit
   2.269          comme un <quote>fork</quote> devient <emphasis>uniquement</emphasis>
   2.270 -        une problématique sociale. En fait, les outils de gestions de source
   2.271 +        une problématique sociale. En fait, les outils de gestions de révisions
   2.272          distribués <emphasis>réduisent</emphasis> les chances de
   2.273          <quote>fork</quote> :
   2.274        </para>
   2.275 @@ -354,7 +355,7 @@
   2.276          <listitem>
   2.277          <para>Ils éliminent la distinction sociale qu'imposent les outils
   2.278            centralisés entre les membres du projets (ceux qui ont accès au
   2.279 -          <quote>commit</quote>) et ceux de l'extérieur (ce qui ne l'ont
   2.280 +          <quote>commit</quote>) et ceux de l'extérieur (qui ne l'ont
   2.281            pas).
   2.282          </para>
   2.283          <para>Ils rendent plus facile la réconciliation après un
   2.284 @@ -365,7 +366,7 @@
   2.285        </itemizedlist>
   2.286  
   2.287        <para id="x_98">Certaines personnes font de la résistance envers les
   2.288 -        gestionnaires de source distribués parce qu'ils veulent garder un
   2.289 +        gestionnaires de révisions distribués parce qu'ils veulent garder un
   2.290          contrôle ferme sur leur projet, et ils pensent que les outils
   2.291          centralisés leur fournissent ce contrôle. Néanmoins, si c'est votre
   2.292          cas, sachez que si vous publiez votre dépôt CVS ou Subversion de
   2.293 @@ -386,7 +387,7 @@
   2.294        <para id="x_99">Beaucoup de projets commerciaux sont réalisés par des
   2.295          équipes éparpillées à travers le globe. Les contributeurs qui sont
   2.296          loin du serveur central devront subir des commandes lentes et même
   2.297 -        parfois peu fiables. Les solutions propriétaires de gestion de source
   2.298 +        parfois peu fiables. Les solutions propriétaires de gestion de révisions
   2.299          tentent de palier ce problème avec des réplications de sites distants
   2.300          qui sont à la fois coûteuses à mettre en place et lourdes à
   2.301          administrer. Un système distribué ne souffre pas de ce genre de
   2.302 @@ -396,24 +397,24 @@
   2.303          connexion longue distance souvent onéreuse.
   2.304        </para>
   2.305  
   2.306 -      <para id="x_9a">Les systèmes de gestion de source supportent
   2.307 +      <para id="x_9a">Les systèmes de gestion de révisions supportent
   2.308          généralement assez mal la monté en charge. Il n'est pas rare pour un
   2.309 -        gestionnaire de source centralisé pourtant onéreux de s'effondrer
   2.310 +        gestionnaire de révisions centralisé pourtant onéreux de s'effondrer
   2.311          sous la charge combinée d'une douzaine d'utilisateurs concurrents
   2.312          seulement. Une fois encore, la réponse à cette problématique est
   2.313          généralement encore la mise en place d'un ensemble complexe de
   2.314          serveurs synchronisés par un mécanisme de réplication. Dans le cas
   2.315 -        d'un gestionnaire de source distribué, la charge du serveur central
   2.316 -        &emdash; si vous avez un&emdash; est plusieurs fois inférieure (car
   2.317 +        d'un gestionnaire de révisions distribué, la charge du serveur central
   2.318 +        &emdash; si vous en avez un&emdash; est largement inférieure (car
   2.319          toutes les données sont déjà répliquées ailleurs), un simple serveur,
   2.320 -        pas très cher, peut gérer les besoins d'une plus grande équipe, et la
   2.321 +        peu onéreux, peut gérer les besoins d'une plus grande équipe, et la
   2.322          réplication pour balancer la charge devient le travail d'un simple
   2.323          script.
   2.324        </para>
   2.325  
   2.326        <para id="x_9b">Si vous avez des employés sur le terrain, en train de
   2.327          chercher à résoudre un souci sur le site d'un client, ils
   2.328 -        bénéficieront aussi d'un gestionnaire de source distribué. Cet outil
   2.329 +        bénéficieront aussi d'un gestionnaire de révisions distribué. Cet outil
   2.330          leur permettra de générer des versions personnalisées, d'essayer
   2.331          différentes solutions, en les isolant aisément les unes des autres,
   2.332          et de rechercher efficacement à travers l'historique des sources, la
   2.333 @@ -427,7 +428,7 @@
   2.334        <title>Pourquoi choisir Mercurial?</title>
   2.335  
   2.336        <para id="x_9c">Mercurial a plusieurs caractéristiques qui en font un
   2.337 -        choix particulièrement pertinent pour la gestion de source :
   2.338 +        choix particulièrement pertinent pour la gestion de révisions :
   2.339        </para>
   2.340      <itemizedlist>
   2.341        <listitem><para id="x_9d">Il est simple à apprendre et à utiliser.</para></listitem>
   2.342 @@ -437,7 +438,7 @@
   2.343      </itemizedlist>
   2.344  
   2.345      <para id="x_a1">Si vous êtes déjà familier d'un outil de gestion de
   2.346 -      source, vous serez capable de l'utiliser en moins de 5 minutes. Sinon,
   2.347 +      révisions, vous serez capable de l'utiliser en moins de 5 minutes. Sinon,
   2.348        ça ne sera pas beaucoup plus long. Les commandes utilisées par
   2.349        Mercurial, comme ses fonctionnalités, sont généralement uniformes et
   2.350        cohérentes, et vous pouvez ainsi garder en tête simplement quelques
   2.351 @@ -448,7 +449,7 @@
   2.352        avec Mercurial en quelques instants. Ajouter des modifications ou des
   2.353        branches, transférer ces modifications (localement ou via le réseau),
   2.354        et les opérations d'historique ou de statut sont aussi très rapides.
   2.355 -      Mercurial reste hors de votre chemin grâce à sa simplicité
   2.356 +      Mercurial ne vous encombre pas grâce à sa simplicité
   2.357        d'utilisation et sa rapidité d'exécution.
   2.358      </para>
   2.359  
   2.360 @@ -481,7 +482,7 @@
   2.361      <sect2>
   2.362        <title>Subversion</title>
   2.363  
   2.364 -      <para id="x_a6">Subversion est un des outils de gestion de source les
   2.365 +      <para id="x_a6">Subversion est un des outils de gestion de révisions les
   2.366          plus populaire, il fût développé pour remplacer CVS. Il a une
   2.367          architecture client/server centralisée.
   2.368        </para>
   2.369 @@ -539,7 +540,7 @@
   2.370          vous suivez une cinquantaine de versions d'un fichier incompressible
   2.371          de 10MB, l'occupation disque coté client d'un projet sous Subversion
   2.372          restera à peu près constante. A l'inverse, l'occupation disque du
   2.373 -        même projet sous n'importe lequel des gestionnaires de source
   2.374 +        même projet sous n'importe lequel des gestionnaires de révisions
   2.375          distribués grandira rapidement, proportionnellement aux nombres de
   2.376          versions, car les différences entre chaque révisions seront très
   2.377          grandes.
   2.378 @@ -568,7 +569,7 @@
   2.379      <sect2>
   2.380        <title>Git</title>
   2.381  
   2.382 -      <para id="x_af">Git est un outil de gestion de source distribué qui fût
   2.383 +      <para id="x_af">Git est un outil de gestion de révisions distribué qui fût
   2.384          développé pour gérer le code source de noyau de Linux. Comme
   2.385          Mercurial, sa conception initiale a été inspirée par Monotone.
   2.386        </para>
   2.387 @@ -605,7 +606,7 @@
   2.388          Git sont implémentées sous forme de scripts Shell ou Perl, et la
   2.389          qualité de ces scripts varie grandement. J'ai plusieurs fois constaté
   2.390          que certains de ces scripts étaient chargés en mémoire aveuglément et
   2.391 -        que la présence d'erreurs pouvait s'avérer fatal.
   2.392 +        que la présence d'erreurs pouvait s'avérer fatale.
   2.393        </para>
   2.394  
   2.395        <para id="x_b4">Mercurial peut importer l'historique d'un dépôt Git.</para>
   2.396 @@ -614,7 +615,7 @@
   2.397      <sect2>
   2.398        <title>CVS</title>
   2.399  
   2.400 -      <para id="x_b5">CVS est probablement l'outil de gestion de source le
   2.401 +      <para id="x_b5">CVS est probablement l'outil de gestion de révisions le
   2.402          plus utilisé aujourd'hui dans le monde. À cause de son manque de
   2.403          clarté interne, il n'est plus maintenu depuis plusieurs années.
   2.404        </para>
   2.405 @@ -622,8 +623,8 @@
   2.406        <para id="x_b6">Il a une architecture client/serveur centralisée. Il ne
   2.407          regroupe pas les modifications de fichiers dans une opération de
   2.408          <quote>commit</quote> atomique, ce qui permet à ses utilisateurs de
   2.409 -        <quote>casser le <emphasis>build</emphasis></quote> assez facilement
   2.410 -        : une personne peut effectuer une opération de <quote>commit</quote>
   2.411 +        <quote>casser le <emphasis>build</emphasis></quote> assez facilement :
   2.412 +        une personne peut effectuer une opération de <quote>commit</quote>
   2.413          sans problème puis être bloquée par besoin de fusion, avec comme
   2.414          conséquence néfaste, que les autres utilisateurs ne récupèreront
   2.415          qu'une partie de ses modifications. Ce problème affecte aussi la
   2.416 @@ -647,7 +648,7 @@
   2.417        <para id="x_b8">Mercurial peut importer l'historique d'un projet CVS.
   2.418          Néanmoins, il y a quelques principes à respecter; ce qui est vrai
   2.419          aussi pour les autres outils d'import de projet CVS. À cause de
   2.420 -        l'absence de <quote>commit</quote> atomique et gestion de version de
   2.421 +        l'absence de <quote>commit</quote> atomique et gestion de versions de
   2.422          l'arborescence, il n'est pas possible de reconstruire de manière
   2.423          précise l'ensemble de l'historique. Un travail de
   2.424          <quote>devinette</quote> est donc nécessaire, et les fichiers
   2.425 @@ -670,7 +671,7 @@
   2.426  
   2.427        <para id="x_ba">Perforce a une architecture client/serveur centralisée,
   2.428          sans aucun mécanisme de mise en cache de données coté client.
   2.429 -        Contrairement à la plupart des outils modernes de gestion de source,
   2.430 +        Contrairement à la plupart des outils modernes de gestion de révisions,
   2.431          Perforce exige de ses utilisateurs d'exécuter une commande pour
   2.432          informer le serveur central de tout fichier qu'ils souhaitent
   2.433          modifier.
   2.434 @@ -685,12 +686,12 @@
   2.435  
   2.436      </sect2>
   2.437      <sect2>
   2.438 -      <title>Choisir un outil de gestion de source</title>
   2.439 +      <title>Choisir un outil de gestion de révisions</title>
   2.440  
   2.441        <para id="x_bc">A l'exception de CVS, tous les outils listés ci-dessus
   2.442 -        ont des forces qui leur sont propres et qui correspondent à certaines
   2.443 +        ont des forces qui leurs sont propres et qui correspondent à certaines
   2.444          formes de projet. Il n'y a pas un seul meilleur outil de gestion de
   2.445 -        source qui correspondrait le mieux à toutes les situations.
   2.446 +        révisions qui correspondrait le mieux à toutes les situations.
   2.447        </para>
   2.448  
   2.449        <para id="x_bd">En guise exemple, Subversion est un très bon choix
   2.450 @@ -718,7 +719,7 @@
   2.451        effectuées depuis votre import initial.
   2.452      </para>
   2.453  
   2.454 -    <para id="x_c0">Les outils de gestion de source supportés par <literal
   2.455 +    <para id="x_c0">Les outils de gestion de révisions supportés par <literal
   2.456          role="hg-ext">convert</literal> sont :
   2.457      </para>
   2.458      <itemizedlist>
   2.459 @@ -745,9 +746,9 @@
   2.460    </sect1>
   2.461  
   2.462    <sect1>
   2.463 -    <title>Une courte histoire de la gestion de source</title>
   2.464 -
   2.465 -    <para id="x_c7">Le plus célèbre des anciens outils de gestion de source
   2.466 +    <title>Une courte histoire de la gestion de révisions</title>
   2.467 +
   2.468 +    <para id="x_c7">Le plus célèbre des anciens outils de gestion de révisions
   2.469        est <emphasis remap="it">SCCS</emphasis> (Source Code Control System)},
   2.470        que Marc Rochkind conçu dans les laboratoires de recherche de Bell
   2.471        (<emphasis remap="it">Bell Labs</emphasis>), dans le début des années
   2.472 @@ -796,12 +797,12 @@
   2.473        l'historique du projet. L'espace de travail client ne contient qu'une
   2.474        copie de la dernière version du projet, et quelques métadonnées pour
   2.475        indiquer où le serveur se trouve. CVS a été un grand succès,
   2.476 -      aujourd'hui il est probablement l'outil de gestion de contrôle le plus
   2.477 +      aujourd'hui il est probablement l'outil de gestion de révisions le plus
   2.478        utilisé au monde.
   2.479      </para>
   2.480      
   2.481      <para>Au début des années 1990, Sun Microsystems développa un premier
   2.482 -      outil de gestion de source distribué, nommé TeamWare. Un espace de
   2.483 +      outil de gestion de révisions distribué, nommé TeamWare. Un espace de
   2.484        travail TeamWare contient une copie complète de l'historique du projet.
   2.485        TeamWare n'a pas de notion de dépôt central. (CVS utilisait RCS pour le
   2.486        stockage de l'historique, TeamWare utilisait SCCS).
   2.487 @@ -831,10 +832,10 @@
   2.488      </para>
   2.489      
   2.490      <para>Plus ou moins simultanément, Graydon Hoare a commencé sur
   2.491 -      l'ambitieux système de gestion distribué Monotone. Bien que Monotone
   2.492 +      l'ambitieux système de gestion distribuée Monotone. Bien que Monotone
   2.493        corrige plusieurs défauts de CVS tout en offrant une architecture
   2.494        <quote>peer-to-peer</quote>, il va aussi plus loin que la plupart des
   2.495 -      outils de révision de manière assez innovante. Il utilise des
   2.496 +      outils de gestion de révisions de manière assez innovante. Il utilise des
   2.497        <quote>hashs</quote> cryptographiques comme identifiants, et il a une
   2.498        notion complète de <quote>confiance</quote> du code issu des
   2.499        différentes sources.
   2.500 @@ -842,7 +843,7 @@
   2.501      
   2.502      <para>Mercurial est né en 2005. Bien que très influencé par Monotone,
   2.503        Mercurial se concentre sur la facilité d'utilisation, les performances
   2.504 -      et la capacité à monter en charge pour de très gros projets.
   2.505 +      et la capacité à monter en charge sur de très gros projets.
   2.506      </para>
   2.507    
   2.508    </sect1>

     3.1 --- a/fr/ch02-tour-basic.xml	Mon Sep 14 01:31:50 2009 +0200
     3.2 +++ b/fr/ch02-tour-basic.xml	Tue Sep 15 13:43:02 2009 +0200
     3.3 @@ -14,7 +14,7 @@
     3.4      <sect2>
     3.5        <title>Windows</title>
     3.6  
     3.7 -      <para id="x_c">La meilleur version de Mercurial pour Windows est
     3.8 +      <para id="x_c">La meilleure version de Mercurial pour Windows est
     3.9          TortoiseHg, qui peut être téléchargée ici : <ulink
    3.10            url="http://bitbucket.org/tortoisehg/stable/wiki/Home">http://bitbucket.org/tortoisehg/stable/wiki/Home</ulink>.
    3.11          Ce logiciel n'a aucune dépendance exterieure; il fonctionne <quote>et
    3.12 @@ -96,18 +96,18 @@
    3.13        &interaction.tour.help;
    3.14  
    3.15        <para id="x_10">Pour un niveau d'informations encore plus détaillé 
    3.16 -        (ce dont vous aurez rarement besoin), exécuter <command role="hg-cmd">hg 
    3.17 +        (ce dont vous aurez rarement besoin), exécutez <command role="hg-cmd">hg 
    3.18          help <option role="hg-opt-global">-v</option></command>.  L'option 
    3.19          <option role="hg-opt-global">-v</option> est l'abréviation de 
    3.20          <option role="hg-opt-global">--verbose</option>, et indique à Mercurial 
    3.21 -        d'ficher plus d'informations que d'habitude.</para>
    3.22 +        d'afficher plus d'informations que d'habitude.</para>
    3.23  
    3.24       </sect2>
    3.25    </sect1>
    3.26    <sect1>
    3.27      <title>Travailler avec un dépôt</title>
    3.28  
    3.29 -    <para id="x_11">Avec Mercurial, tout se déroule au sein du 
    3.30 +    <para id="x_11">Avec Mercurial, tout se déroule au sein d'un 
    3.31        <emphasis>dépôt</emphasis>. Le dépôt d'un projet contient tous 
    3.32        les fichiers qui <quote>appartiennent</quote> au projet.</para>
    3.33  
    3.34 @@ -130,7 +130,7 @@
    3.35  
    3.36        <para id="x_67c">Un avantage de la commande <command role="hg-cmd">hg
    3.37            clone</command> est que, comme nous l'avons vu ci dessus, elle nous
    3.38 -        permet de faire de cloner les dépôts à travers le réseau. Un autre
    3.39 +        permet de cloner les dépôts à travers le réseau. Un autre
    3.40          est qu'elle se rappelle d'où a été cloné un dépôt, ce qui est utile
    3.41          quand on veut mettre à jour le clone.</para>
    3.42  
    3.43 @@ -204,25 +204,25 @@
    3.44      <itemizedlist>
    3.45        <listitem><para id="x_1e"><literal>changeset</literal> : Ce champ contient 
    3.46          un nombre, séparé par deux points (:), d'une chaine hexadécimale. Il 
    3.47 -        s'agit en fait d'<emphasis>identifiants</emphasis>  d'un changeset. Il y a 
    3.48 -        deux identifiants car le numéro de la révision est plus court et plus à 
    3.49 +        s'agit en fait d'<emphasis>identifiants</emphasis>  d'un <quote>changeset</quote>. Il y a 
    3.50 +        deux identifiants car le numéro de la révision est plus court et plus 
    3.51          facile à saisir qu'une séquence hexadécimale.</para>
    3.52        </listitem>
    3.53        <listitem><para id="x_1f"><literal>user</literal> : L'identité de la personne 
    3.54 -        qui a créée ce  %%% laisser le terme anglais car il sera affiché
    3.55 -        changeset. C'est un champ libre de forme, mais la plupart du
    3.56 +          qui a créé ce <!--ntd %%% laisser le terme anglais car il sera affiché-->
    3.57 +          <quote>changeset</quote>. C'est un champ libre de forme, mais la plupart du
    3.58          temps il contient le nom et l'email de la personne.</para>
    3.59        </listitem>
    3.60        <listitem><para id="x_20"><literal>date</literal> : La date et l'heure à 
    3.61 -        laquelle le \textit{changeset} a été créé, ainsi que le fuseau horaire dans 
    3.62 +              laquelle le <quote>changeset</quote> a été créé, ainsi que le fuseau horaire dans 
    3.63          lequelle il a été créé. (La date et l'heure sont locales à ce
    3.64 -        \textit{fuseau}, elles indiquent donc quelle date et heure il était
    3.65 -        pour la personne qui a créé ce changeset.</para>
    3.66 +        <quote>fuseau</quote>, elles indiquent donc quelle date et heure il était
    3.67 +        pour la personne qui a créé ce <quote>changeset</quote>.</para>
    3.68        </listitem>
    3.69        <listitem><para id="x_21"><literal>résumé</literal>: La première ligne du 
    3.70 -        message que le créateur a associé à son changeset pour le décrire.</para>
    3.71 +              message que le créateur a associé à son <quote>changeset</quote> pour le décrire.</para>
    3.72        </listitem>
    3.73 -      <listitem><para id="x_67d">Certains changesets, comme le premier de la
    3.74 +      <listitem><para id="x_67d">Certains <quote>changesets</quote>, comme le premier de la
    3.75          liste ci-dessus ont un champ <literal>tag</literal>. Le tag est une autre
    3.76          façon d'identifier un changeset en lui donnant un nom simple à retenir.
    3.77          (Le tag nommé <literal>tip</literal> est spécial : il fait toujours
    3.78 @@ -234,14 +234,14 @@
    3.79  
    3.80      <para id="x_23">La figure <xref linkend="fig:tour-basic:history"/> fournit une 
    3.81        représentation graphique de l'historique du dépôt <filename class="directory">hello
    3.82 -      </filename>, pour rendre plus facile de voir dans quelle direction 
    3.83 +      </filename>, pour voir plus facilement dans quelle direction 
    3.84        l'historique se <quote>déroule</quote>. Nous reviendrons régulièrement 
    3.85        sur cette représentation dans ce chapitre et ceux qui suivent.</para>
    3.86  
    3.87  
    3.88      <figure id="fig:tour-basic:history">
    3.89 -      <title>Graphical history of the <filename
    3.90 -                    class="directory">hello</filename> repository</title>
    3.91 +      <title>Historique graphique du dépôt <filename
    3.92 +                    class="directory">hello</filename></title>
    3.93        <mediaobject>
    3.94          <imageobject><imagedata fileref="figs/tour-history.png"/></imageobject>
    3.95          <textobject><phrase>XXX add text</phrase></textobject>
    3.96 @@ -255,18 +255,18 @@
    3.97        <para id="x_25">Comme l'anglais est réputé pour être un langage maladroit,
    3.98          et que l'informatique est la source de bien des erreurs de terminologie
    3.99          (pourquoi utiliser un seul terme quand quatre feront l'affaire ?), la
   3.100 -        gestion de version a une variété de mots et de phrases qui veulent dire
   3.101 +        gestion de révisions a une variété de mots et de phrases qui veulent dire
   3.102          la même chose. Si vous discutez d'historique de Mercurial avec d'autres
   3.103          personnes, vous constaterez que souvent, le mot <quote>changeset</quote>
   3.104          est contracté simplement en <quote>change</quote> ou (à l'écrit)
   3.105 -        <quote>cset</quote>, et même parfois un changeset
   3.106 +        <quote>cset</quote>, et même parfois 
   3.107          <quote>révision</quote>, abrégé en <quote>rev</quote>.</para>
   3.108  
   3.109        <para id="x_26">Bien que le <emphasis>mot</emphasis> que vous utilisez pour 
   3.110          désigner le concept de changeset importe peu, l'<emphasis>identifiant</emphasis> 
   3.111          que vous utilisez pour désigner un <emphasis>changeset</emphasis> spécifique 
   3.112 -        a une grande importance. Rappelez vous que le champ changeset affiché par la
   3.113 -        commande <command role="hg-cmd">hg log</command> identifie un changeset à
   3.114 +        a une grande importance. Rappelez vous que le champ <quote>changeset</quote> affiché par la
   3.115 +        commande <command role="hg-cmd">hg log</command> identifie un <quote>changeset</quote> à
   3.116          la fois avec un numéro de révision et une séquence hexadécimale.</para>
   3.117  
   3.118        <itemizedlist>
   3.119 @@ -274,24 +274,24 @@
   3.120          valable dans ce dépôt</emphasis>,</para></listitem>
   3.121          <listitem><para id="x_28">La séquence hexadécimale est un
   3.122          <emphasis>identifiant permanent, et invariant</emphasis> qui 
   3.123 -        pourra toujours être associé au changeset exact de <emphasis>chaque</emphasis> 
   3.124 +        pourra toujours être associé au <quote>changeset</quote> exact de <emphasis>chaque</emphasis> 
   3.125          copie de votre dépôt.</para></listitem></itemizedlist>
   3.126  
   3.127        <para id="x_29">La distinction est importante. Si vous envoyez un email 
   3.128           à quelqu'un en parlant de la <quote>révision 33</quote>, il est très 
   3.129 -         probable que sa révision 33 <emphasis>ne sera pas la même</emphasis> 
   3.130 +         probable que sa <quote>révision 33</quote> <emphasis>ne sera pas la même</emphasis> 
   3.131           que la votre. La raison de ceci est que le numéro de révision dépend 
   3.132           de l'ordre dans lequel les modifications sont arrivées dans le dépôt, 
   3.133           et il n'y a aucune garantie que les mêmes changements soient arrivés 
   3.134           dans le même ordre dans différents dépôts. Trois modifications
   3.135 -         <literal>a,b,c</literal> peuvent aisément apparaitre dans un dépôt 
   3.136 -         comme <literal>0,1,2</literal>, et dans un autre comme <literal>0,2,1
   3.137 +         <literal>a, b, c</literal> peuvent aisément apparaitre dans un dépôt 
   3.138 +         comme <literal>0, 1, 2</literal>, et dans un autre comme <literal>0, 2, 1
   3.139           </literal>.</para>
   3.140  
   3.141        <para id="x_2a">Mercurial utilise les numéros de révision uniquement comme des raccourcis
   3.142 -        pratiques. Si vous devez discuter d'un \textit{changeset} avec quelqu'un,
   3.143 -        ou identifer un \textit{changeset} pour une quelconque raison (par exemple,
   3.144 -        un rapport de \textit{bug}), utilisez la séquence hexadécimale.</para>
   3.145 +          pratiques. Si vous devez discuter d'un <quote>changeset</quote> avec quelqu'un,
   3.146 +          ou identifer un <quote>changeset</quote> pour une quelconque raison (par exemple,
   3.147 +          un rapport de <quote>bug</quote>), utilisez la séquence hexadécimale.</para>
   3.148  
   3.149      </sect2>
   3.150      <sect2>
   3.151 @@ -306,7 +306,7 @@
   3.152        &interaction.tour.log-r;
   3.153  
   3.154        <para id="x_2c">Si vous voulez voir l'historique de plusieurs révisions
   3.155 -        sans avoir à les énumérer, vous pouvez utiliser la <emphasis>intervalle
   3.156 +        sans avoir à les énumérer, vous pouvez utiliser un <emphasis>intervalle
   3.157          de numérotation</emphasis> qui vous permet d'exprimer l'idée <quote>je
   3.158          veux toutes les révisions entre $a$ et $b$, inclus</quote></para>
   3.159  
   3.160 @@ -314,8 +314,8 @@
   3.161  
   3.162        <para id="x_2d">Mercurial respecte aussi l'ordre dans lequel vous spécifiez
   3.163          les révisions, ainsi <command role="hg-cmd">hg log -r 2:4</command>
   3.164 -        affichera <literal>2,3,4</literal> alors que <command role="hg-cmd">hg
   3.165 -        log -r 4:2</command> affichera <literal>4,3,2</literal>.</para>
   3.166 +        affichera <literal>2, 3, 4</literal> alors que <command role="hg-cmd">hg
   3.167 +        log -r 4:2</command> affichera <literal>4, 3, 2</literal>.</para>
   3.168  
   3.169      </sect2>  
   3.170      <sect2>
   3.171 @@ -325,15 +325,15 @@
   3.172          est suffisant si vous savez déjà ce que vous cherchez. En 
   3.173          revanche, vous aurez probablement besoin de voir une description 
   3.174          complète du changement, ou une liste des fichiers modifiés si vous 
   3.175 -        cherchez à déterminer qu'un changeset est bien celui que vous
   3.176 -        recherchez. L'option \hgopt{-v} de la commande <command role="hg-cmd">hg 
   3.177 +        cherchez à déterminer qu'un <quote>changeset</quote> est bien celui que vous
   3.178 +        recherchez. L'option <option role="hg-opt-log">-v</option> de la commande <command role="hg-cmd">hg 
   3.179          log</command> (ou <option role="hp-opt-global">--verbose</option>) vous 
   3.180          donne ces informations supplémentaires.</para>
   3.181  
   3.182        &interaction.tour.log-v;
   3.183  
   3.184        <para id="x_2f">Si vous voulez voir à la fois la description 
   3.185 -        et le contenu d'une modification, ajouter l'option <option 
   3.186 +        et le contenu d'une modification, ajoutez l'option <option 
   3.187          role="hg-opt-log">-p</option> (ou <option role="hg-opt-log">
   3.188          --patch</option>). Ceci affiche le contenu d'une modification 
   3.189          comme un <emphasis>diff unifié</emphasis>
   3.190 @@ -370,7 +370,7 @@
   3.191        <listitem><para id="x_33">La plupart des options disposent de 
   3.192          noms abrégés. Aussi, au lieu d'utiliser <option role="hg-opt-log">--rev
   3.193          </option>, vous pouvez utiliser <option role="hg-opt-log">-r</option>. 
   3.194 -        (Les options qui  n'ont pas de noms abrégés sont généralement 
   3.195 +        (Les options qui n'ont pas de nom abrégé sont généralement 
   3.196          rarement utilisées).</para>
   3.197        </listitem>
   3.198        <listitem><para id="x_34">Les noms complets commencent par deux 
   3.199 @@ -380,7 +380,7 @@
   3.200        </listitem>
   3.201       <listitem><para id="x_35">Les noms des options sont cohérents 
   3.202         entre les commandes. Par exemple, chaque commande qui accepte 
   3.203 -       un changeset ID ou un numéro de révision accepte aussi <option 
   3.204 +       un <quote>changeset ID</quote> ou un numéro de révision accepte aussi <option 
   3.205         role="hg-opt-log">-r</option> et <option role="hg-opt-log">--rev
   3.206         </option> comme arguments.</para>
   3.207       </listitem>
   3.208 @@ -397,14 +397,14 @@
   3.209       <option role="hg-opt-global">--quiet</option>).</para>
   3.210  
   3.211      <note>
   3.212 -      <title>Option naming consistency</title>
   3.213 +      <title>Cohérence dans le nom des options</title>
   3.214        
   3.215        <para id="x_680">Presque toujours, les commandes de Mercurial utilisent
   3.216 -      des noms d'options cohérentes pour référer à des concepts identiques.
   3.217 -      Par exemple, si une commande concerne les changesets, vous les
   3.218 +      des noms d'options cohérentes pour se référer à des concepts identiques.
   3.219 +      Par exemple, si une commande concerne les <quote>changesets</quote>, vous les
   3.220        identifierez toujours avec l'option <option role="hg-opt-log">-r</option>.
   3.221        Cette utilisation cohérente des noms d'options permet de mémoriser plus
   3.222 -      facilement quelles options accepte une commande.</para>
   3.223 +      facilement quelles options acceptent une commande.</para>
   3.224     </note>
   3.225  
   3.226  
   3.227 @@ -416,8 +416,8 @@
   3.228        commandes pour consulter l'historique de Mercurial, regardons 
   3.229        comment faire des modifications et les examiner.</para>
   3.230       
   3.231 -    <para id="x_39">La première chose que nous allons faire c'est isoler notre
   3.232 -      expérience dans un dépôt à part. Nous allons utiliser la commande <command
   3.233 +    <para id="x_39">La première chose que nous allons faire est d'isoler notre
   3.234 +      exercice dans un dépôt à part. Nous allons utiliser la commande <command
   3.235          role="hg-cmd">hg clone</command>, mais nous n'avons pas besoin de faire
   3.236        une copie de dépôt distant. Comme nous avons déjà une copie locale, nous
   3.237        pouvons juste faire un clone de celle-ci à la place. C'est beaucoup plus
   3.238 @@ -428,7 +428,7 @@
   3.239          ce cas, Mercurial utilisera des liens physiques pour effectuer des partages
   3.240          copie-lors-des-écritures de ses métadonnées internes. Si cette explication
   3.241          ne signifie rien pour vous, ne vous inquietez pas : tout ceci se passe de
   3.242 -        manière transparente et automatiquement. Vous n'avez pas du tout besoin de
   3.243 +        manière transparente et automatique. Vous n'avez pas du tout besoin de
   3.244          comprendre ceci.</para></footnote>.</para>
   3.245    
   3.246      &interaction.tour.reclone;
   3.247 @@ -439,7 +439,7 @@
   3.248        copies locales temporaires pour créer des <quote>bacs à sable</quote> 
   3.249        pour chaque tâche sur laquelle vous souhaitez travailler. Ceci 
   3.250        vous permet de travailler sur plusieurs choses en parallèle, 
   3.251 -      chacune isolée les unes des autres en attendant que ces tâches 
   3.252 +      chacunes isolées les unes des autres en attendant que ces tâches 
   3.253        soient finies et que vous soyez prêt à les réintégrer. Parce 
   3.254        que les copies locales sont peu coûteuses, il est très rapide 
   3.255        de créer ou détruire des dépôts dès que vous n'en avez plus
   3.256 @@ -475,8 +475,8 @@
   3.257        <filename>hello.c</filename>. Nous n'avons pas besoin
   3.258        <emphasis>d'informer</emphasis> Mercurial que nous allons modifier un
   3.259        fichier avant de commencer à le faire, ou que nous avons modifié un
   3.260 -      fichier après avoir commencé à le faire, il est capable de découvrir ça
   3.261 -      tout seul. </para>
   3.262 +      fichier après avoir commencé à le faire, il est capable de le découvrir
   3.263 +      tout seul.</para>
   3.264  
   3.265      <para id="x_3f">C'est déjà pratique de savoir que nous avons modifié le
   3.266        fichier <filename>hello.c</filename>, mais nous préférerions savoir
   3.267 @@ -501,7 +501,7 @@
   3.268          status</command> et <command role="hg-cmd">hg diff</command> pour
   3.269        voir les modifications effectuées, jusqu'à ce que nous soyons assez
   3.270        satisfaits pour décider d'enregistrer notre travail dans un
   3.271 -      \textit{changeset}.</para>
   3.272 +      <quote>changeset</quote>.</para>
   3.273  
   3.274      <para id="x_41">La commande <command role="hg-cmd">hg commit</command>
   3.275        vous laisse créer une nouvelle révision, nous désignerons généralement
   3.276 @@ -516,9 +516,9 @@
   3.277          pas garanti qu'elle réussisse du premier coup. En effet, Mercurial
   3.278          enregistre votre nom et votre adresse avec chaque modification que
   3.279          vous effectuez, de manière à ce que vous soyez capable (ou d'autres
   3.280 -        le soient) de savoir qui a fait quelle modification. Mercurial essaye
   3.281 +        le soient) de savoir qui a fait telle modification. Mercurial essaye
   3.282          automatiquement de découvrir un nom d'utilisateur qui ait un minimum
   3.283 -        de sens pour effectuer l'opération de commit avec. Il va essayer
   3.284 +        de sens pour effectuer l'opération de <quote>commit</quote> avec. Il va essayer
   3.285          chacune des méthodes suivantes, dans l'ordre :</para>
   3.286  
   3.287        <orderedlist>
   3.288 @@ -544,14 +544,14 @@
   3.289          <listitem><para id="x_47">Enfin, Mercurial interrogera votre système
   3.290              pour trouver votre nom d'utilisateur local ainsi que le nom de la
   3.291              machine hôte, et il fabriquera un nom d'utilisateur à partir de
   3.292 -            ces données. Comme il arrive souvent que ce genre de noms soit
   3.293 +            ces données. Comme il arrive souvent que ce genre de nom soit
   3.294              totalement inutile, il vous préviendra en affichant un message
   3.295              d'avertissement.</para></listitem>
   3.296        </orderedlist>
   3.297     
   3.298        <para id="x_48">Si tous ces mécanismes échouent, Mercurial n'exécutera
   3.299          pas la commande, affichant un message d'erreur. Dans ce cas, il ne
   3.300 -        vous laissera pas effectuer de commit tant que vous n'aurez pas
   3.301 +        vous laissera pas effectuer de <quote>commit</quote> tant que vous n'aurez pas
   3.302          défini un nom d'utilisateur.</para>
   3.303     
   3.304        <para id="x_49">Vous devriez penser à utiliser la variable
   3.305 @@ -560,7 +560,7 @@
   3.306          <emphasis>changer</emphasis> le nom d'utilisateur par défaut. Pour
   3.307          une utilisation normale, la manière la plus simple et robuste
   3.308          d'opérer est de créer un fichier <filename
   3.309 -          role="special">.hgrc</filename>, voir ci-dessous pour  les détails
   3.310 +          role="special">.hgrc</filename>, voir ci-dessous pour les détails
   3.311          à ce sujet.</para>
   3.312  
   3.313        <sect3 id="sec:tour-basic:username">
   3.314 @@ -576,7 +576,7 @@
   3.315          <tip>
   3.316            <title><quote>Home directory</quote> sous Windows</title>
   3.317     
   3.318 -          <para id="x_716">Quand on parle de répertoire home, sur une version
   3.319 +          <para id="x_716">Quand on parle de répertoire <quote>home</quote>, sur une version
   3.320              anglaise d'une installation de Windows, il s'agira habituellement
   3.321              d'un répertoire nommée comme votre nom dans <filename>C:\Documents 
   3.322                and Settings</filename>. Vous pouvez trouver de quelle répertoire
   3.323 @@ -609,7 +609,7 @@
   3.324            pour votre <literal>username</literal>, car cette information 
   3.325            est destinée à d'autres personnes et non à être interprétée 
   3.326            par Mercurial. La convention que la plupart des personnes
   3.327 -          suivent est d'utiliser leurs noms suivies de leurs adresses emails,
   3.328 +          suivent est d'utiliser leur nom suivie de leur adresse email,
   3.329            comme montré ci-dessus :</para>
   3.330          <note>
   3.331            <para id="x_4d">Le mécanisme interne du serveur web intégré à Mercurial,
   3.332 @@ -621,9 +621,9 @@
   3.333        </sect3>
   3.334      </sect2>
   3.335      <sect2>
   3.336 -      <title>Rédiger un message de \textit{commit}</title>
   3.337 -  
   3.338 -      <para id="x_4e">Lorsqu'on effectue une opération de commit, Mercurial
   3.339 +        <title>Rédiger un message de <quote>commit</quote></title>
   3.340 +  
   3.341 +        <para id="x_4e">Lorsqu'on effectue une opération de <quote>commit</quote>, Mercurial
   3.342          lance automatiquement un éditeur de texte pour permettre de saisir
   3.343          un message qui décrira les modifications effectuées dans cette
   3.344          révision. Ce message est nommé le <emphasis>message de commit</emphasis>. 
   3.345 @@ -651,19 +651,19 @@
   3.346        <para id="x_50">Mercurial ignore les lignes qui commencent 
   3.347          avec <quote><literal>HG:</literal></quote>, il ne les 
   3.348          utilise que pour nous indiquer quels fichiers modifiés il se
   3.349 -        prépare à \textit{commiter}. Modifier ou effacer ces lignes n'a
   3.350 -        aucune conséquence sur l'opération de commit.
   3.351 +        prépare à <quote>commiter</quote>. Modifier ou effacer ces lignes n'a
   3.352 +        aucune conséquence sur l'opération de <quote>commit</quote>.
   3.353        </para>
   3.354  
   3.355      </sect2>
   3.356      <sect2>
   3.357 -      <title>Rédiger un message \textit{approprié}</title>
   3.358 +        <title>Rédiger un message approprié</title>
   3.359    
   3.360        <para id="x_51">Comme <command role="hg-cmd">hg log</command> n'affiche
   3.361 -        que la première ligne du message de commit par défaut, il est souvent
   3.362 -        considéré comme une bonne pratique de rédiger des messages de commit
   3.363 +          que la première ligne du message de <quote>commit</quote> par défaut, il est souvent
   3.364 +          considéré comme une bonne pratique de rédiger des messages de <quote>commit</quote>
   3.365          qui tiennent sur une seule ligne. Voilà un exemple concret de message 
   3.366 -        de commit qui <emphasis>ne suit pas</emphasis> cette directive, et
   3.367 +        de <quote>commit</quote> qui <emphasis>ne suit pas</emphasis> cette directive, et
   3.368          qui a donc un résumé peu lisible.</para>
   3.369  
   3.370        <programlisting>
   3.371 @@ -675,7 +675,7 @@
   3.372    
   3.373        <para id="x_52">A ce sujet, il faut noter qu'il n'existe pas de règle 
   3.374          absolue dans ce domaine. Mercurial lui-même n'interprète pas les 
   3.375 -        contenus des messages de commit, ainsi votre projet est libre de 
   3.376 +        contenus des messages de <quote>commit</quote>, ainsi votre projet est libre de 
   3.377          concevoir différentes politiques de mise en page des messages.</para>
   3.378        
   3.379        <para id="x_53">Ma préférence personnelle va au message court, mais 
   3.380 @@ -693,20 +693,20 @@
   3.381          <title>Une surprise pour les utilisateurs habitués à Subversion</title>
   3.382     
   3.383          <para id="x_717">Comme n'importe quel autre commande de Mercurial, si
   3.384 -          vous soumettez pas de manière explicite les noms des fichiers à
   3.385 -          committer à la commande <command role="hg-cmd">hg commit</command>, elle
   3.386 +          vous ne soumettez pas de manière explicite les noms des fichiers à
   3.387 +          <quote>committer</quote> à la commande <command role="hg-cmd">hg commit</command>, elle
   3.388            va travailler sur l'ensemble du répertoire de travail. Soyez conscient
   3.389            de ceci si vous venez du monde Subversion ou CVS, car vous pourriez
   3.390 -          attendre qu'elle opère uniquement le répertoire courant et ses sous
   3.391 +          vous attendre à ce qu'elle opère uniquement sur le répertoire courant et ses sous
   3.392            répertoires.</para>
   3.393        </note>
   3.394      </sect2>
   3.395      <sect2>
   3.396 -      <title>Annuler un \textit{commit}</title>
   3.397 +        <title>Annuler un <quote>commit</quote></title>
   3.398  
   3.399        <para id="x_54">Si, en rédigeant le message, vous décidez que 
   3.400 -        finalement vous ne voulez pas effectuer ce commit, il suffit 
   3.401 -        de quitter simplement l'éditeur sans sauver. Ceci n'aura aucune 
   3.402 +          finalement vous ne voulez pas effectuer ce <quote>commit</quote>, il suffit 
   3.403 +        de quitter simplement l'éditeur sans sauvegarder. Ceci n'aura aucune 
   3.404          conséquence sur le dépôt ou les fichiers du répertoire de 
   3.405          travail.</para>
   3.406      </sect2>
   3.407 @@ -714,10 +714,10 @@
   3.408      <sect2>
   3.409        <title>Admirer votre travail</title>
   3.410    
   3.411 -      <para id="x_56">Une fois que votre \textit{commit} est terminé, vous
   3.412 +      <para id="x_56">Une fois que votre <quote>commit</quote> est terminé, vous
   3.413          pouvez utiliser la commande <command role="hg-cmd">hg tip</command>
   3.414 -        pour afficher le \textit{changeset} que vous venez de créer. Cette
   3.415 -        commande produit  une sortie à l'écran qui est identique à celle du
   3.416 +        pour afficher le <quote>changeset</quote> que vous venez de créer. Cette
   3.417 +        commande produit une sortie à l'écran qui est identique à celle du
   3.418          <command role="hg-cmd">hg log</command>, mais qui n'affiche que la
   3.419          dernière révision du dépôt.</para>
   3.420   
   3.421 @@ -781,7 +781,7 @@
   3.422        <para id="x_5d">Comme vous le voyez avec une sortie avant et après de la
   3.423          commande <command role="hg-cmd">hg tip</command>, nous avons réussi à
   3.424          récupérer aisément les modifications dans notre dépôt. Il reste néanmoins
   3.425 -        quelque chose à faire avant de placer ces modifications dans l'espace de
   3.426 +        quelque chose à faire avant de retrouver ces modifications dans l'espace de
   3.427          travail.</para>
   3.428     
   3.429        <tip>
   3.430 @@ -796,14 +796,14 @@
   3.431            la commande <command role="hg-cmd">hg incoming</command>, et avant que
   3.432            vous ne décidiez de récupérer ces modifications, quelqu'un peut ajouter
   3.433            de nouvelles révisions dans le dépôt distant. Ce qui signifie que vous
   3.434 -          récupérez plus de révision que ce que vous aviez regardées en utilisant
   3.435 +          récupérez plus de révisions que ce que vous aviez regardées en utilisant
   3.436            la commande <command role="hg-cmd">hg incoming</command>.</para>
   3.437  
   3.438          <para id="x_718">Si vous voulez seulement récupérer ce que vous aviez
   3.439 -          vérifier à l'aide de la commande <command role="hg-cmd">hg
   3.440 -            incoming</command>, ou que pour d'autres raisons vous souhaitiez ne
   3.441 +          vérifié à l'aide de la commande <command role="hg-cmd">hg
   3.442 +            incoming</command>, ou que pour d'autres raisons vous ne souhaitiez
   3.443            récupérer qu'un sous ensemble des révisions supplémentaires
   3.444 -          disponibles, indiquant simplement les modifications que vous souhaitez
   3.445 +          disponibles, indiquez simplement les modifications que vous souhaitez
   3.446            récupérer par leurs ID de révision, soit <command>hg pull
   3.447              -r7e95bb</command>. </para>
   3.448        </tip>
   3.449 @@ -827,7 +827,7 @@
   3.450        <para id="x_5f">Il peut sembler un peu étrange que la commande <command
   3.451            role="hg-cmd">hg pull</command> ne mette pas à jour l'espace de travail
   3.452          automatiquement. Il y a en fait une très bonne raison à cela : vous
   3.453 -        pouvez utilisez la commande <command role="hg-cmd">hg update</command>
   3.454 +        pouvez utiliser la commande <command role="hg-cmd">hg update</command>
   3.455          pour mettre à jour votre espace de travail à l'état dans lequel il était 
   3.456          à <emphasis>n'importe quelle révision</emphasis> de l'historique du dépôt. 
   3.457          Si vous aviez un espace de travail contenant une ancienne
   3.458 @@ -862,15 +862,15 @@
   3.459          enfant.</para>
   3.460  
   3.461        <para id="x_64">Pour mettre à jour l'espace de travail d'une révision
   3.462 -        particulière, indiquez un numéro de révision ou un \textit{changeset
   3.463 -        ID} à la commande <command role="hg-cmd">hg update</command>.</para>
   3.464 +          particulière, indiquez un numéro de révision ou un <quote>changeset
   3.465 +              ID</quote à la commande <command role="hg-cmd">hg update</command>.</para>
   3.466    
   3.467        &interaction.tour.older;
   3.468     
   3.469        <para id="x_65">Si vous ne précisez pas de manière explicite de numéro 
   3.470          de révision la commande <command role="hg-cmd">hg update</command>
   3.471          mettra à jour votre espace de travail avec le contenu de la révison
   3.472 -        \textit{tip}, comme montré dans l'exemple ci dessus lors du second
   3.473 +        <quote>tip</quote>, comme montré dans l'exemple ci dessus lors du second
   3.474          appel à <command role="hg-cmd">hg update</command>.</para>
   3.475      
   3.476      </sect2>
   3.477 @@ -907,7 +907,7 @@
   3.478          répertoire de travail alors que quelqu'un d'autre travaille dessus,
   3.479          nous risquerions de perturber son travail.</para>
   3.480    
   3.481 -      <para id="x_6a">Qu'est ce qui se passe lorsque vous essayez de récupérer
   3.482 +      <para id="x_6a">Que se passe-t'il lorsque vous essayez de récupérer
   3.483          ou de transférer vos modifications et que le dépôt cible a déjà reçu
   3.484          ces modifications ? Rien de bien excitant.</para>
   3.485   
   3.486 @@ -959,7 +959,7 @@
   3.487        &interaction.tour.outgoing.net;
   3.488    
   3.489        <para id="x_6c">Dans cet exemple, nous allons voir quels changements 
   3.490 -        nous pourrions transférer vers le dépôt distant, mais le dépôt est, 
   3.491 +        nous pourrions transférer vers le dépôt distant, mais le dépôt n'est, 
   3.492          de manière tout à fait compréhensible, pas configuré pour accepter 
   3.493          des modifications d'utilisateurs anonymes.</para>
   3.494   
   3.495 @@ -1005,7 +1005,7 @@
   3.496        utiliser Mercurial sur un nouveau projet, ce qui fait aussi de ses
   3.497        points forts. Travailler avec une gestion de révision devient très
   3.498        facile, nous pouvons même l'utiliser pour les plus petits projets où
   3.499 -      nous aurions probablement jamais penser utiliser un outils aussi
   3.500 +      nous aurions probablement jamais pensé utiliser un outil aussi
   3.501        complexe.</para>
   3.502    </sect1>
   3.503  </chapter>

     4.1 --- a/fr/ch03-tour-merge.xml	Mon Sep 14 01:31:50 2009 +0200
     4.2 +++ b/fr/ch03-tour-merge.xml	Tue Sep 15 13:43:02 2009 +0200
     4.3 @@ -2,7 +2,7 @@
     4.4  
     4.5  <chapter id="chap:tour-merge">
     4.6    <?dbhtml filename="a-tour-of-mercurial-merging-work.html"?>
     4.7 -  <title>Un rapide tour de Mercurial: fusionner les travaux</title>
     4.8 +  <title>Un tour rapide de Mercurial : fusionner les travaux</title>
     4.9    
    4.10    <para id="x_338">Nous avons maintenant étudié comment cloner un dépôt, effectuer
    4.11      des changements dedans, et récupérer ou transférer depuis un
    4.12 @@ -11,8 +11,8 @@
    4.13  
    4.14    <sect1>
    4.15      <title>Fusionner différents travaux</title>
    4.16 -      <para id="x_339">La fusion  est un aspect fondamental lorsqu'on
    4.17 -      travaille iavec un gestionnaire de source distribué.</para>
    4.18 +      <para id="x_339">La fusion est un aspect fondamental lorsqu'on
    4.19 +      travaille avec un gestionnaire de révisions distribué.</para>
    4.20  
    4.21        <itemizedlist>
    4.22          <listitem>
    4.23 @@ -45,13 +45,13 @@
    4.24  
    4.25        &interaction.tour.merge.cat1;
    4.26       
    4.27 -     <para id="x_722">Et ici est notre légèrement différente version du
    4.28 +     <para id="x_722">Et ici se trouve notre version légèrement différente du
    4.29         dépôt.</para>
    4.30       
    4.31        &interaction.tour.merge.cat2;
    4.32       
    4.33       <figure id="fig:tour-merge:sep-repos">
    4.34 -       <title>Historique divergent des dépôts <filename
    4.35 +       <title>Historique divergeant des dépôts <filename
    4.36           class="directory">my-hello</filename> et <filename
    4.37           class="directory">my-new-hello</filename>.</title>
    4.38         <mediaobject>
    4.39 @@ -71,18 +71,18 @@
    4.40         <quote>heads</quote>.</para>
    4.41  
    4.42       <sect2>
    4.43 -       <title>Les révisions 'heads'</title>
    4.44 +         <title>Les révisions <quote>heads</quote></title>
    4.45  
    4.46         <para id="x_341">Rappellez vous que Mercurial enregistre quelle révision
    4.47           est le parent de chaque révision. Si une révision a un parent, nous
    4.48 -         l'appelons un enfant(child) ou un descendant de ce parent. Une
    4.49 -         "head" est une révision qui n'a donc pas d'enfant. La révision tip
    4.50 -         est donc une "head", car c'est la révision la plus récente du dépôt
    4.51 +         l'appelons un enfant <quote>child</quote> ou un descendant de ce parent. Une
    4.52 +         <quote>head</quote> est une révision qui n'a donc pas d'enfant. La révision <quote>tip</quote>
    4.53 +         est donc une <quote>head</quote>, car c'est la révision la plus récente du dépôt
    4.54           qui n'a pas d'enfant. Il y a des moments où un dépôt peut contenir
    4.55 -         plusieurs "head".</para>
    4.56 +         plusieurs <quote>heads</quote>.</para>
    4.57  
    4.58         <figure id="fig:tour-merge:pull">
    4.59 -         <title>Contenu du dépôt après une récupération ("pull") depuis le
    4.60 +           <title>Contenu du dépôt après une récupération (pull) depuis le
    4.61             dépôt <filename
    4.62             class="directory">my-hello</filename> vers le dépôt <filename
    4.63             class="directory">my-new-hello</filename></title>
    4.64 @@ -95,18 +95,18 @@
    4.65         </figure>
    4.66  
    4.67         <para id="x_343">Dans la figure <xref linkend="fig:tour-merge:pull"/>,
    4.68 -         vous pouvez constater l'effet d'un \textit{pull} depuis le dépôt
    4.69 +           vous pouvez constater l'effet d'un <quote>pull</quote> depuis le dépôt
    4.70           <filename class="directory">my-hello</filename> dans le dépôt
    4.71           <filename class="directory">my-new-hello</filename>. L'historique qui
    4.72           était déjà présent dans le dépôt <filename
    4.73           class="directory">my-new-hello</filename> reste intact, mais une
    4.74           nouvelle révision a été ajoutée. En vous reportant à la figure <xref
    4.75           linkend="fig:tour-merge:sep-repos"/>, vous pouvez voir que le
    4.76 -         <emphasis>ID de révision (changeset ID)</emphasis> reste le même dans
    4.77 +     <emphasis>ID de révision <quote>changeset ID</quote></emphasis> reste le même dans
    4.78           le nouveau dépôt, mais que le <emphasis>numéro de
    4.79           révision</emphasis> reste le même. (Ceci est un parfait exemple de
    4.80           pourquoi il n'est fiable d'utiliser les numéros de révision lorsque
    4.81 -         l'on discute d'un \textit{changeset}.) Vous pouvez voir les "heads"
    4.82 +         l'on discute d'un <quote>changeset</quote>.) Vous pouvez voir les <quote>heads</quote>
    4.83           présentes dans le dépôt en utilisant la commande <command
    4.84           role="hg-cmd">hg heads</command>.</para>
    4.85  
    4.86 @@ -118,7 +118,7 @@
    4.87  
    4.88          <para id="x_344">Que se passe-t-il quand vous essayez d'utiliser la
    4.89            commande <command role="hg-cmd">hg update</command> pour mettre à
    4.90 -          jour votre espace de travail au nouveau "tip"</para>
    4.91 +          jour votre espace de travail au nouveau <quote>tip</quote></para>
    4.92           
    4.93           &interaction.tour.merge.update;
    4.94  
    4.95 @@ -129,9 +129,9 @@
    4.96            estime que nous pourrions avoir besoin d'une fusion, à moins de lui
    4.97            forcer la main. À la place, il faut utiliser la commande <command
    4.98            role="hg-cmd">hg merge</command> pour fusionner les deux
    4.99 -          "heads".</para>
   4.100 -
   4.101 -       <para id="x_723">Pour commencer une fusion (merge) entre deux "heads",
   4.102 +          <quote>heads</quote>.</para>
   4.103 +
   4.104 +       <para id="x_723">Pour commencer une fusion (merge) entre deux <quote>heads</quote>,
   4.105         nous utilisons la commande <command role="hg-cmd">hg merge</command>.</para>
   4.106  
   4.107          &interaction.tour.merge.merge; 
   4.108 @@ -139,7 +139,7 @@
   4.109         <para id="x_347">Nous résolvons les conflits dans le fichier
   4.110           <filename>hello.c</filename>. Ceci met à jour le répertoire de travail
   4.111           de sorte qu'il ne contienne les modifications ne provenance des
   4.112 -         <emphasis>deux</emphasis> "heads", ce qui est indiqué par la
   4.113 +         <emphasis>deux</emphasis> <quote>heads</quote>, ce qui est indiqué par la
   4.114           la sortie de la commande <command role="hg-cmd">hg
   4.115           parents</command> et le contenu du fichier
   4.116           <filename>hello.c</filename>.</para>
   4.117 @@ -159,7 +159,7 @@
   4.118          &interaction.tour.merge.commit;
   4.119  
   4.120        <para id="x_349">Nous avons maintenant un nouveau tip, remarquer qu'il
   4.121 -        contient <emphasis>à la fois</emphasis> nos anciennes "heads" et leurs
   4.122 +        contient <emphasis>à la fois</emphasis> nos anciennes <quote>heads</quote> et leurs
   4.123          parents. Ce sont les mêmes révisions que nous avions affichées avec
   4.124          la commande <command role="hg-cmd">hg parents</command>.</para>
   4.125  
   4.126 @@ -168,13 +168,13 @@
   4.127        <para id="x_34a">Dans la figure <xref linkend="fig:tour-merge:merge"/>,
   4.128          vous pouvez voir une représentation de ce qui se passe dans l'espace
   4.129          de travail pendant la fusion, et comment ceci affecte le dépôt lors
   4.130 -        du "commit". Pendant la fusion, l'espace de travail, qui a deux
   4.131 +        du <quote>commit</quote>. Pendant la fusion, l'espace de travail, qui a deux
   4.132          révisions (changesets) comme parents, voit ces derniers devenir le parent
   4.133          d'une nouvelle révision (changeset).</para>
   4.134  
   4.135        <figure id="fig:tour-merge:merge">
   4.136 -        <title>Working directory and repository during merge, and
   4.137 -          following commit</title>
   4.138 +          <title>Répertoire de travail et dépôt pendant une fusion, 
   4.139 +              et le <quote>commit</quote> qui suit</title>
   4.140          <mediaobject>
   4.141            <imageobject>
   4.142              <imagedata fileref="figs/tour-merge-merge.png"/>
   4.143 @@ -189,12 +189,12 @@
   4.144    <sect1>
   4.145      <title>Fusionner les modifications en conflit</title>
   4.146  
   4.147 -    <para id="x_34b">La plupart des fusions sont assez simple à réaliser, mais 
   4.148 +    <para id="x_34b">La plupart des fusions sont assez simples à réaliser, mais 
   4.149        parfois vous vous retrouverez à fusionner des fichiers où la modification 
   4.150        touche la même portion de code, au sein d'un même fichier. À moins 
   4.151        que ces modification ne soient identiques, ceci aboutira à un 
   4.152        <emphasis>conflit</emphasis>, et vous devrez décider comment réconcilier 
   4.153 -      les différentes modifications dans un tout cohérent.</para>
   4.154 +      les différentes modifications dans un ensemble cohérent.</para>
   4.155  
   4.156      <figure id="fig:tour-merge:conflict">
   4.157        <title>Modifications en conflits dans un document</title>
   4.158 @@ -214,12 +214,12 @@
   4.159      <para id="x_34e">Mercurial n'a pas de mécanisme interne pour gérer 
   4.160        les conflits. À la place, il exécute un programme externe appelé 
   4.161        <command>hgmerge</command>. Il s'agit d'un script shell qui est 
   4.162 -      embarqué par Mercurial, vous pouvez le modifier si vous le voulez. 
   4.163 +      compris avec Mercurial, vous pouvez le modifier si vous voulez. 
   4.164        Ce qu'il fait par défaut est d'essayer de trouver un des différents 
   4.165        outils de fusion qui seront probablement installés sur le système. 
   4.166 -      Il commence par les outils totalement automatiques, et si ils 
   4.167 +      Il commence par les outils totalement automatiques, et s'ils 
   4.168        échouent (parce que la résolution du conflit nécessite une
   4.169 -      intervention humaine) ou si ils sont absents, le script tente
   4.170 +      intervention humaine) ou s'ils sont absents, le script tente
   4.171        d'exécuter certains outils graphiques de fusion.</para>
   4.172  
   4.173      <para id="x_34f">Il est aussi possible de demander à Mercurial d'exécuter
   4.174 @@ -235,22 +235,22 @@
   4.175          fonctionnalités classiques des outils graphiques de fusion. Vous pouvez
   4.176          voir une capture d'écran de l'utilisation de <command>kdiff3</command>
   4.177          dans la figure <xref linkend="fig:tour-merge:kdiff3"/>. Cet outil
   4.178 -        effectue une <emphasis>fusion \textit{three-way</emphasis>}, car il y a
   4.179 -        trois différentes versions du fichier qui nous intéresse. Le fichier
   4.180 -        découpe la partie supérieure de la fenêtre en trois panneaux:</para>
   4.181 +        effectue une <emphasis>fusion <quote>three-way</quote></emphasis>, car il y a
   4.182 +        trois différentes versions du fichier qui nous intéressent. Le fichier
   4.183 +        découpe la partie supérieure de la fenêtre en trois panneaux :</para>
   4.184        <itemizedlist>
   4.185 -        <listitem><para id="x_351">A gauche on la version de
   4.186 +        <listitem><para id="x_351">À gauche on trouve la version de
   4.187            <emphasis>base</emphasis> du fichier, soit la plus récente version
   4.188            des deux versions qu'on souhaite fusionner.</para></listitem>
   4.189          <listitem><para id="x_352">Au centre, il y a <quote>notre</quote>
   4.190            version du fichier, avec le contenu que nous avons modifié.</para></listitem>
   4.191          <listitem><para id="x_353">Sur la droite, on trouve
   4.192          <quote>leur</quote> version du fichier, celui qui contient la
   4.193 -        révision que nous souhaitons intégré.</para>
   4.194 +        révision que nous souhaitons intégrer.</para>
   4.195          </listitem></itemizedlist>
   4.196        <para id="x_354">Dans le panneau en dessous, on trouve le
   4.197          <emphasis>résultat</emphasis> actuel de notre fusion. Notre tâche
   4.198 -        consiste donc à remplacement tous les textes en rouges,
   4.199 +        consiste donc à remplacer tous les textes en rouges,
   4.200          qui indiquent des conflits non résolus, avec une fusion manuelle et 
   4.201          pertinente de <quote>notre</quote> version et de la <quote>leur</quote>.
   4.202        </para>
   4.203 @@ -274,14 +274,14 @@
   4.204  
   4.205         <para id="x_357">Pour chaque portion de fichier posant problème, nous
   4.206           pouvons choisir de résoudre le conflit en utilisant une combinaison de
   4.207 -         texte depuis la version de base, la notre, ou la leur. Nous pouvons
   4.208 +         touches depuis la version de base, la notre, ou la leur. Nous pouvons
   4.209           aussi éditer manuellement les fichiers à tout moment, si c'est nécessaire.</para>
   4.210  
   4.211         <para id="x_358">Il y a <emphasis>beaucoup</emphasis> d'outils de
   4.212 -         fusion disponibles, bien trop pour en parler de tous ici. Leurs
   4.213 -         disponibilités varient selon les plate formes  ainsi que leurs
   4.214 -         avantages et inconvénients. La plupart sont optimisé pour
   4.215 -         la fusion de fichier contenant un texte plat, certains sont spécialisé
   4.216 +         fusion disponibles, bien trop pour parler de tous ici. Leurs
   4.217 +         disponibilités varient selon les plateformes  ainsi que leurs
   4.218 +         avantages et inconvénients. La plupart sont optimisés pour
   4.219 +         la fusion de fichier contenant un texte plat, certains sont spécialisés
   4.220           dans un format de fichier précis (généralement XML).</para>
   4.221      </sect2>
   4.222  
   4.223 @@ -290,12 +290,12 @@
   4.224  
   4.225        <para id="x_359">Dans cet exemple, nous allons reproduire la
   4.226          modification de l'historique du fichier de la figure <xref
   4.227 -        linkend="fig:tour-merge:conflict"/> ci dessus. Commençons par créer
   4.228 +        linkend="fig:tour-merge:conflict"/> ci-dessus. Commençons par créer
   4.229          un dépôt avec une version de base de notre document.</para>
   4.230  
   4.231        &interaction.tour-merge-conflict.wife; 
   4.232  
   4.233 -      <para id="x_35a">Créons un clone de ce dépôt et faisons une
   4.234 +      <para id="x_35a">Créons un clone de ce dépôt et effectuons une
   4.235          modification dans le fichier.</para>
   4.236  
   4.237        &interaction.tour-merge-conflict.cousin;
   4.238 @@ -315,12 +315,12 @@
   4.239        &interaction.tour-merge-conflict.pull;
   4.240  
   4.241        <para id="x_35d">Dans cette exemple, je n'utiliserais pas la commande Mercurial
   4.242 -        habituelle <command>hgmerge</command> pour effectuer le
   4.243 +        habituelle <command>hgmerge</command> pour effectuer la
   4.244          fusion (merge), car il me faudrait abandonner ce joli petit exemple automatisé
   4.245          pour utiliser un outil graphique. À la place, je vais définir la
   4.246          variable d'environnement <envar>HGMERGE</envar> pour indiquer à
   4.247          Mercurial d'utiliser la commande non-interactive <command>merge</command>.
   4.248 -        Cette dernière est embarquée par de nombreux systèmes <quote>à la Unix</quote>.
   4.249 +        Cette dernière est comprise dans de nombreux systèmes <quote>à la Unix</quote>.
   4.250          Si vous exécutez cet exemple depuis votre ordinateur, ne vous
   4.251          occupez pas de définir <envar>HGMERGE</envar>.</para>
   4.252  
   4.253 @@ -344,7 +344,7 @@
   4.254  
   4.255       <para id="x_361">Si la fusion (merge) automatique ou manuelle échoue, 
   4.256         il n'y a rien pour nous empêcher de <quote>corriger le tir</quote> en
   4.257 -       modifiant nous même les fichiers, et enfin effectuer le "commit" du 
   4.258 +       modifiant nous même les fichiers, et enfin effectuer le <quote>commit</quote> du 
   4.259         fichier:</para>
   4.260  
   4.261       &interaction.tour-merge-conflict.commit;
   4.262 @@ -353,19 +353,19 @@
   4.263         <title>Où est la <command>hg resolve</command> ?</title>
   4.264         
   4.265         <para id="x_724">La commande <command>hg resolve</command> a été
   4.266 -         introduit dans la version 1.1 de Mercurial, qui a été publié en
   4.267 +         introduit dans la version 1.1 de Mercurial, qui a été publiée en
   4.268           décembre 2008. Si vous utilisez une version plus anciennne de
   4.269           Mercurial (exécutez la command <command>hg version</command> pour en
   4.270 -         avoir le coeur net), cette commande ne sera pas disponible. Si votre
   4.271 +         avoir le cœur net), cette commande ne sera pas disponible. Si votre
   4.272           version de Mercurial est plus ancienne que la 1.1, vous devriez très
   4.273 -         fortement considérer une mise à jour à une version plus récente avant
   4.274 +         fortement considérer une mise à jour vers une version plus récente avant
   4.275           d'essayer de régler des fusions complexes.</para>
   4.276         </note>
   4.277       </sect2>
   4.278     </sect1>
   4.279  
   4.280     <sect1 id="sec:tour-merge:fetch">
   4.281 -     <title>Simplification de la séquence pull-merge-commit</title>
   4.282 +       <title>Simplification de la séquence <quote>pull-merge-commit</quote></title>
   4.283  
   4.284       <para id="x_362">La procédure pour effectuer la fusion indiquée
   4.285         ci-dessus est simple, mais requiert le lancement de trois commandes à la
   4.286 @@ -375,39 +375,39 @@
   4.287  hg merge
   4.288  hg commit -m 'Merged remote changes'</programlisting>
   4.289  
   4.290 -     <para id="x_363">Lors du "commit" final, vous devez également saisir un
   4.291 +     <para id="x_363">Lors du <quote>commit</quote> final, vous devez également saisir un
   4.292         message, qui aura vraisemblablement assez peu d'intérêt.</para>
   4.293  
   4.294       <para id="x_364">Il serait assez sympathique de pouvoir réduire le
   4.295         nombre d'opérations nécessaire, si possible. De fait Mercurial est
   4.296 -       fourni avec une extension appelé <literal role="hg-ext">fetch</literal>
   4.297 +       fournit avec une extension appelée <literal role="hg-ext">fetch</literal>
   4.298         qui fait justement cela.</para>
   4.299  
   4.300 -     <para id="x_365">Mercurial fourni un mécanisme d'extension flexible qui permet à chacun
   4.301 +     <para id="x_365">Mercurial fournit un mécanisme d'extension flexible qui permet à chacun
   4.302         d'étendre ces fonctionnalités, tout en conservant le cœur de Mercurial
   4.303 -       léger et facile à utiliser. Certains extensions ajoutent de nouvelles
   4.304 +       léger et facile à utiliser. Certaines extensions ajoutent de nouvelles
   4.305         commandes que vous pouvez utiliser en ligne de commande, alors que
   4.306 -       d'autres travaillent <quote>en coulisse,</quote> par exemple en ajoutant des
   4.307 +       d'autres travaillent <quote>en coulisse</quote>, par exemple en ajoutant des
   4.308         possibilités au serveur.</para>
   4.309  
   4.310       <para id="x_366">L'extension <literal role="hg-ext">fetch</literal>
   4.311         ajoute une nouvelle commande nommée, sans surprise, <command
   4.312 -       role="hg-cmd">hg fetch</command>. Cette extension résulte en une
   4.313 +       role="hg-cmd">hg fetch</command>. Cette extension consiste en une
   4.314         combinaison de <command role="hg-cmd">hg pull</command>, <command
   4.315 -       role="hg-cmd">hg update</command> and <command role="hg-cmd">hg
   4.316 +       role="hg-cmd">hg update</command> et <command role="hg-cmd">hg
   4.317         merge</command>. Elle commence par récupérer les modifications d'un
   4.318         autre dépôt dans le dépôt courant. Si elle trouve que les
   4.319 -       modifications ajoutent une nouvelle "head", elle effectue un "merge",
   4.320 -       et ensuite "commit" le résultat du "merge" avec un message généré
   4.321 -       automatiquement. Si aucune "head" n'ont été ajouté, elle met à jour le
   4.322 -       répertoire de travail au niveau de la nouvelle révision tip.</para>
   4.323 +       modifications ajoutent une nouvelle <quote>head</quote>, elle effectue un <quote>merge</quote>,
   4.324 +       et ensuite <quote>commit</quote> le résultat du <quote>merge</quote> avec un message généré
   4.325 +       automatiquement. Si aucune <quote>head</quote> n'a été ajouté, elle met à jour le
   4.326 +       répertoire de travail au niveau de la nouvelle révision <quote>tip</quote>.</para>
   4.327       
   4.328       <para id="x_367">Activer l'extension <literal
   4.329         role="hg-ext">fetch</literal> est facile. Modifiez votre <filename
   4.330         role="special">.hgrc</filename>, et soit allez à la section <literal
   4.331 -       role="rc-extensions">extensions</literal> soit créer une section
   4.332 +       role="rc-extensions">extensions</literal> soit créez une section
   4.333         <literal role="rc-extensions">extensions</literal>. Ensuite ajoutez
   4.334 -       une ligne qui consiste simplement en <quote>\Verb+fetch =</quote>.</para>
   4.335 +       une ligne qui consiste simplement en <quote>fetch =</quote>.</para>
   4.336  
   4.337       <programlisting>[extensions]
   4.338  fetch =</programlisting>
   4.339 @@ -431,16 +431,16 @@
   4.340  
   4.341      <para id="x_72a">Mercurial permet de faire ce genre de modification de
   4.342        manière fluide, à condition de l'informer de ce que nous faisons. Si 
   4.343 -      vous voulez renommenr un ficher, vous devriez utiliser les commande
   4.344 +      vous voulez renommer un ficher, vous devriez utiliser la commande
   4.345        <command>hg rename</command><footnote>
   4.346 -        <para id="x_72b">Si vous un utilisateur de Unix, vous serez content
   4.347 -          de savoir que la commande  <command>hg rename</command> command 
   4.348 +        <para id="x_72b">Si vous êtes un utilisateur d'Unix, vous serez content
   4.349 +          de savoir que la commande  <command>hg rename</command>
   4.350            peut être abrégée en <command>hg mv</command>.</para>
   4.351        </footnote> pour changer son nom, ainsi Mercurial peut ensuite prendre
   4.352        la bonne décision, plus tard, en cas de fusionv (merge).</para>
   4.353  
   4.354 -    <para id="x_72c">Nous étudierojns en détail l'utilisation de ces commandes, 
   4.355 -      en détail, dans le chapitre <xref linkend="chap:daily.copy"/>.</para>
   4.356 +    <para id="x_72c">Nous étudierons, en détail, l'utilisation de ces commandes 
   4.357 +     dans le chapitre <xref linkend="chap:daily.copy"/>.</para>
   4.358    </sect1>
   4.359  </chapter>
   4.360