1.1 --- a/fr/ch01-intro.xml	Tue Sep 08 18:20:00 2009 +0200
     1.2 +++ b/fr/ch01-intro.xml	Sun Sep 13 14:08:00 2009 +0200
     1.3 @@ -5,17 +5,18 @@
     1.4    <title>Comment en est on arrivé là ?</title>
     1.5  
     1.6  <sect1>
     1.7 -<title>À propos de la gestion source</title>
     1.8 -
     1.9 -    <para id="x_6d">La gestion de sources est un processus permettant de gérer différentes
    1.10 +<title>À propos de la gestion de révisions. Pourquoi Mercurial ?</title>
    1.11 +
    1.12 +    <para id="x_6d">La gestion de révisions est un processus permettant de gérer différentes
    1.13  versions de la même information. Dans sa forme la plus simple, c'est
    1.14  ce que tout le monde fait manuellement : quand vous modifiez
    1.15  un fichier, vous le sauvegardez sous un nouveau nom contenant un numéro,
    1.16  à chaque fois plus grand que celui de la version précédente.</para>
    1.17  
    1.18 -    <para id="x_6e">Ce genre de gestion de version manuelle est cependant facilement sujette
    1.19 +    <para id="x_6e">Ce genre de gestion de révisions manuelle, ne serait-ce que 
    1.20 +        d'un seul fichier, est cependant facilement sujette
    1.21  aux erreurs, ainsi, depuis longtemps, des logiciels existent pour
    1.22 -résoudre cette problématique. Les premiers outils de gestion de sources
    1.23 +résoudre cette problématique. Les premiers outils de gestion de révisions
    1.24  étaient destinés à aider un seul utilisateur, à automatiser la gestion
    1.25  des versions d'un seul fichier. Dans les dernières décades, cette cible
    1.26  s'est largement agrandie, ils gèrent désormais de multiples fichiers, et
    1.27 @@ -24,23 +25,23 @@
    1.28  personnes travaillant ensemble sur des projets regroupant plusieurs
    1.29  centaines de milliers de fichiers.</para>
    1.30  
    1.31 -    <para id="x_6f">L'arrivée de la gestion de révision distribuée est
    1.32 +    <para id="x_6f">L'arrivée de la gestion de révisions distribuée est
    1.33      relativement récente, et, pour le moment, ce nouveau domaine a grandi
    1.34      grâce à la volonté des gens d'explorer ces territoires encore inconnus.
    1.35      </para>
    1.36  
    1.37 -    <para id="x_70">J'écris un livre sur la gestion de révision distribuée
    1.38 +    <para id="x_70">J'écris un livre sur la gestion de révisions distribuée
    1.39      parce que je pense qu'il s'agit d'un sujet important qui mérite un guide
    1.40 -    du terrain. J'ai choisi d'écrire un livre sur Mercurial car il est
    1.41 +    de terrain. J'ai choisi d'écrire un livre sur Mercurial car il est
    1.42      l'outil le plus facile pour découvrir ce nouveau domaine, tout en étant
    1.43      un outil efficace qui répond aux demandes d'environnements réels et
    1.44 -    difficiles, là où d'autres outils de gestions de versions s'effondrent.</para>
    1.45 +    difficiles, là où d'autres outils de gestion de révisions s'effondrent.</para>
    1.46  
    1.47      <sect2>
    1.48 -      <title>Pourquoi utiliser un gestionnaire de source ?</title>
    1.49 +      <title>Pourquoi utiliser un gestionnaire de révisions ?</title>
    1.50  
    1.51        <para id="x_71">Il y a de nombreuses raisons pour que vous ou votre équipe souhaitiez
    1.52 -utiliser un outil automatisant la gestion de version pour votre projet.</para>
    1.53 +utiliser un outil automatisant la gestion de révisions pour votre projet.</para>
    1.54  
    1.55        <itemizedlist>
    1.56  	<listitem><para id="x_72">L'outil se chargera de suivre l'évolution de votre projet, sans
    1.57 @@ -50,14 +51,14 @@
    1.58  <emphasis>ce</emphasis> qu'il a modifié.</para>
    1.59  </listitem>
    1.60  <listitem><para id="x_73">Quand vous travaillez avec d'autres personnes, les logiciels de
    1.61 -gestion de source facilitent le travail collaboratif. Par exemple, quand
    1.62 +gestion de révisions facilitent le travail collaboratif. Par exemple, quand
    1.63  plusieurs personnes font, plus ou moins simultanément, des modifications
    1.64  incompatibles, le logiciel vous aidera à identifier et à résoudre les conflits.</para>
    1.65  </listitem>
    1.66  <listitem><para id="x_74">L'outil vous aidera à réparer vos erreurs. Si vous effectuez un changement
    1.67  qui se révèle être une erreur, vous pourrez revenir à une version
    1.68  antérieure d'un fichier ou même d'un ensemble de fichiers. En fait, un outil de
    1.69 -gestion de source <emphasis>vraiment</emphasis> efficace vous permettra d'identifier à quel
    1.70 +gestion de révisions <emphasis>vraiment</emphasis> efficace vous permettra d'identifier à quel
    1.71  moment le problème est apparu (voir la section <xref linkend="sec:undo:bisect"/> pour plus
    1.72  de détails).</para>
    1.73  </listitem>
    1.74 @@ -65,27 +66,27 @@
    1.75  de votre projet et de gérer l'écart entre chacune.</para>
    1.76  </listitem></itemizedlist>
    1.77  <para id="x_76">La plupart de ces raisons ont autant d'importances &emdash;du
    1.78 -  moins en théorie&emdash; que vous travailliez sur un projet pour vous, ou
    1.79 +  moins en théorie&emdash; que vous travailliez seul sur un projet, ou
    1.80    avec une centaine d'autres personnes.
    1.81  </para>
    1.82  
    1.83  <para id="x_77">Une question fondamentale à propos des outils de gestion de
    1.84 -  source, qu'il s'agisse du projet d'une personne ou d'une grande équipe, est
    1.85 -  quels sont ses <emphasis>avantages</emphasis> par rapport à ses
    1.86 -  <emphasis>coûts</emphasis>. Un outil qui est difficile à utiliser ou à
    1.87 +  révisions, qu'il s'agisse du projet d'une personne ou d'une grande équipe, est
    1.88 +  quels sont ses <emphasis>gains</emphasis> par rapport à ses
    1.89 +  <emphasis>coût</emphasis>. Un outil qui est difficile à utiliser ou à
    1.90    comprendre exigera un lourd effort d'adaptation.
    1.91  </para>
    1.92  
    1.93 -<para id="x_78">)Un projet de cinq milles personnes s'effondrera très
    1.94 +<para id="x_78">Un projet de cinq milles personnes s'effondrera très
    1.95    certainement de lui même sans aucun processus et outil de gestion de
    1.96 -  source. Dans ce cas, le coût d'utilisation d'un logiciel de gestion de
    1.97 -  source est dérisoire puisque <emphasis>sans</emphasis>, l'échec est presque
    1.98 +  révisions. Dans ce cas, le coût d'utilisation d'un logiciel de gestion de
    1.99 +  révisions est dérisoire puisque <emphasis>sans</emphasis>, l'échec est presque
   1.100    garanti.
   1.101  </para>
   1.102  
   1.103  <para id="x_79">D'un autre coté, un <quote>rapide hack</quote> d'une personne
   1.104    peut sembler un contexte bien pauvre pour utiliser un outil de gestion de
   1.105 -  source, car, bien évidement le coût d'utilisation dépasse le coût total du
   1.106 +  révisions, car, bien évidement le coût d'utilisation dépasse le coût total du
   1.107    projet. N'est ce pas ?
   1.108  </para>
   1.109  
   1.110 @@ -93,7 +94,7 @@
   1.111          échelles de travail. Vous pouvez apprendre les bases en quelques
   1.112          minutes seulement, et, grâce à sa performance, vous pouvez l'utiliser
   1.113          avec facilité sur le plus petit des projets. Cette simplicité
   1.114 -        signifie que vous n'avez pas de concept obscurs ou de séquence de
   1.115 +        signifie que vous n'avez pas de concept obscur ou de séquence de
   1.116          commandes défiant l'imagination, sans aucune corrélation avec
   1.117          <emphasis>ce que vous êtes entrain de faire</emphasis>. En même
   1.118          temps, ces mêmes performances et sa nature
   1.119 @@ -101,7 +102,7 @@
   1.120          difficulté, son utilisation à de très grands projets.
   1.121  </para>
   1.122  
   1.123 -      <para id="x_7b">Aucun outil de gestion de source ne peut sauver un
   1.124 +      <para id="x_7b">Aucun outil de gestion de révisions ne peut sauver un
   1.125          projet mal mené, mais un bon outil peut rendre beaucoup plus fluide
   1.126          votre travail.
   1.127  </para>
   1.128 @@ -113,7 +114,7 @@
   1.129  
   1.130        <para id="x_7c">La gestion de source
   1.131          <!-- TODO:<footnote><J'ai utilisé systématiquement le terme
   1.132 -            <quote>gestion de source</quote> à travers tout l'ouvrage. Ce
   1.133 +            <quote>gestion de révisions</quote> à travers tout l'ouvrage. Ce
   1.134              n'est pas forcement la meilleure traduction, et ceci peut rendre
   1.135              la lecture un peu lourde, mais je pense que le document y gagne
   1.136              en clarté et en précision. -->
   1.137 @@ -148,13 +149,13 @@
   1.138  
   1.139    <sect1>
   1.140  
   1.141 -<title>A propos des exemples dans ce livre</title>
   1.142 -
   1.143 -    <para id="x_84">Ce livre prend une approche non usuel pour les exemples
   1.144 +<title>À propos des exemples dans ce livre</title>
   1.145 +
   1.146 +    <para id="x_84">Ce livre prend une approche non usuelle pour les exemples
   1.147        de code. Tous les exemples sont en <quote>live</quote> &emdash; Chacun
   1.148        est actuellement le résultat d'un script shell qui exécute les
   1.149        commandes Mercurial que vous voyez. A chaque fois qu'une image du livre
   1.150 -      est construite à partir des sources, tous les scripts d'exemple sont
   1.151 +      est construite à partir des sources, tous les scripts d'exemples sont
   1.152        lancés automatiquement, et leurs résultats effectifs sont comparés aux
   1.153        résultats attendus.</para>
   1.154  
   1.155 @@ -185,7 +186,7 @@
   1.156      <para id="x_88">Donc, lorsque vous lisez ces exemples, ne prêtez pas trop
   1.157        d'importance aux dates et heures que vous voyez dans la sortie des
   1.158        commandes. Cependant, <emphasis>soyez</emphasis> confiants que le
   1.159 -      comportement que vous voyez est consistent et reproductible 
   1.160 +      comportement que vous voyez est constant et reproductible 
   1.161      </para>
   1.162  
   1.163    </sect1>
   1.164 @@ -193,7 +194,7 @@
   1.165  <!-- The next section has disapper from this part of the book. it may be splaced somewhere else... t-->
   1.166  
   1.167    <sect1>
   1.168 -    <title>Tendances de la gestion de source</title>
   1.169 +    <title>Tendances de la gestion de révisions</title>
   1.170  
   1.171      <para id="x_89">Il y a eu une tendance évidente dans le développement et
   1.172        l'utilisation d'outils de gestion de source depuis les quatre dernières
   1.173 @@ -213,7 +214,7 @@
   1.174        adoptant une architecture réseau et centralisée, permettant de gérer
   1.175        plusieurs projets entiers en même temps. Alors que les projets
   1.176        grandirent en taille, ils rencontrèrent de nouveaux problèmes. Avec les
   1.177 -      clients discutant régulièrement avec le serveurs, la montée en charge
   1.178 +      clients discutant régulièrement avec le serveur, la montée en charge
   1.179        devint un réel problème sur les gros projets. Une connexion réseau peu
   1.180        fiable pouvait complètement empêcher les utilisateurs distants de
   1.181        dialoguer avec le serveur. Alors que les projets <emphasis
   1.182 @@ -224,10 +225,10 @@
   1.183        comme ils ne pouvaient pas non plus enregistrer leurs modifications.
   1.184      </para>
   1.185  
   1.186 -    <para id="x_8c">La génération actuelle des outils de gestion de source
   1.187 +    <para id="x_8c">La génération actuelle des outils de gestion de révisions
   1.188        est <quote>peer-to-peer</quote> par nature. Tous ces systèmes ont
   1.189 -      abandonné la dépendance à un serveur central, et ont permis à leur
   1.190 -      utilisateur de distribuer les données de leur gestion de source à qui
   1.191 +      abandonné la dépendance à un serveur central, et ont permis à leurs
   1.192 +      utilisateurs de distribuer les données de leur gestion de révisions à qui
   1.193        en a besoin. La collaboration à travers Internet a transformé la
   1.194        contrainte technologique en une simple question de choix et de
   1.195        consensus. Les outils modernes peuvent maintenant fonctionner en mode
   1.196 @@ -238,12 +239,12 @@
   1.197    </sect1>
   1.198      
   1.199    <sect1>
   1.200 -    <title>Quelques avantages des gestionnaires de source distribués</title>
   1.201 +    <title>Quelques avantages des gestionnaires de révisions distribués</title>
   1.202        
   1.203 -    <para id="x_8d">Même si les gestionnaire de source distribués sont depuis
   1.204 +    <para id="x_8d">Même si les gestionnaire de révisions distribués sont depuis
   1.205        plusieurs années assez robustes et aussi utilisables que leurs
   1.206        prédécesseurs, les utilisateurs d'autres outils n'y ont pas encore été
   1.207 -      sensibilisés. Les gestionnaires de source distribués se distinguent
   1.208 +      sensibilisés. Les gestionnaires de révisions distribués se distinguent
   1.209        particulièrement de leurs équivalents centralisés de nombreuses
   1.210        manières.
   1.211      </para>
   1.212 @@ -256,7 +257,7 @@
   1.213        stocke toute ses métadonnées localement. À tâche égale, effectuer un
   1.214        échange avec le réseau ajoute un délai aux outils centralisés. Ne
   1.215        sous-estimez pas la valeur d'un outil rapide : vous allez passer
   1.216 -      beaucoup de temps à interagir avec un logiciel de gestion de source.
   1.217 +      beaucoup de temps à interagir avec un logiciel de gestion de révisions.
   1.218      </para>
   1.219  
   1.220      <para id="x_8f">Les outils distribués sont complètement indépendants des
   1.221 @@ -264,7 +265,7 @@
   1.222        à beaucoup d'endroits. Si votre serveur central prend feu, vous avez
   1.223        intérêt à ce que les médias de sauvegardes soient fiables, et que votre
   1.224        dernier <quote>backup</quote> soit récent et fonctionne sans problème.
   1.225 -      Avec un outil distribué, vous avez autant de <quote>backup</quote> que
   1.226 +      Avec un outil distribué, vous avez autant de <quote>backups</quote> que
   1.227        de contributeurs.
   1.228      </para>
   1.229  
   1.230 @@ -275,7 +276,7 @@
   1.231        pendant que vous travaillez, vous pouvez ne même pas vous en rendre
   1.232        compte. La seule chose que vous ne serez pas capable de faire sera de
   1.233        communiquer avec des dépôts distants, opération somme toute assez rare
   1.234 -      en comparaison aux opérations locales. Si vous avez une équipe de
   1.235 +      en comparaison des opérations locales. Si vous avez une équipe de
   1.236        collaborateurs très dispersée ceci peut être significatif.
   1.237      </para>
   1.238  
   1.239 @@ -285,7 +286,7 @@
   1.240        <para id="x_91">Si vous prenez goût à un projet <emphasis
   1.241            remap="it">Open Source</emphasis> et que vous décidez de commencer
   1.242          à toucher à son code, et que le projet utilise un gestionnaire de
   1.243 -        source distribué, vous êtes immédiatement un "pair" avec les
   1.244 +        révisions distribué, vous êtes immédiatement un "pair" avec les
   1.245          personnes formant le <quote>cœur</quote> du projet. S'ils publient
   1.246          leurs dépôts, vous pouvez immédiatement copier leurs historiques de
   1.247          projet, faire des modifications, enregistrer votre travail en
   1.248 @@ -303,7 +304,7 @@
   1.249        <title>Le non-problème du "fork"</title>
   1.250        
   1.251        <para id="x_92">Il a été souvent suggéré que les gestionnaires de
   1.252 -        source distribués posent un risque pour les projets <emphasis
   1.253 +        révisions distribués posent un risque pour les projets <emphasis
   1.254            remap="it">Open Source</emphasis> car ils facilitent grandement la
   1.255          création de <quote>fork</quote>.
   1.256          <!--footnote{NdT:Création d'une <ulink url="version alternative du
   1.257 @@ -332,7 +333,7 @@
   1.258          probablement la <emphasis>meilleure</emphasis> façon de développer un
   1.259          projet. Chaque modification que vous effectuez est potentiellement un
   1.260          <quote>fork</quote>. La grande force de cette approche est que les
   1.261 -        gestionnaires de source distribués doivent être vraiment très
   1.262 +        gestionnaires de révisions distribués doivent être vraiment très
   1.263          efficaces pour <emphasis>fusionner (merge)</emphasis>
   1.264          <!-- TODO footnote{NdT:j'ai choisi de traduire ici <emphasis
   1.265            remap="it">merging</emphasis> par <quote>fusionner</quote> pour des
   1.266 @@ -345,7 +346,7 @@
   1.267          moment, est vue comme un <quote>fork</quote> à fusionner, alors ce
   1.268          que le monde de l'<emphasis remap="it">Open Source</emphasis> voit
   1.269          comme un <quote>fork</quote> devient <emphasis>uniquement</emphasis>
   1.270 -        une problématique sociale. En fait, les outils de gestions de source
   1.271 +        une problématique sociale. En fait, les outils de gestions de révisions
   1.272          distribués <emphasis>réduisent</emphasis> les chances de
   1.273          <quote>fork</quote> :
   1.274        </para>
   1.275 @@ -354,7 +355,7 @@
   1.276          <listitem>
   1.277          <para>Ils éliminent la distinction sociale qu'imposent les outils
   1.278            centralisés entre les membres du projets (ceux qui ont accès au
   1.279 -          <quote>commit</quote>) et ceux de l'extérieur (ce qui ne l'ont
   1.280 +          <quote>commit</quote>) et ceux de l'extérieur (qui ne l'ont
   1.281            pas).
   1.282          </para>
   1.283          <para>Ils rendent plus facile la réconciliation après un
   1.284 @@ -365,7 +366,7 @@
   1.285        </itemizedlist>
   1.286  
   1.287        <para id="x_98">Certaines personnes font de la résistance envers les
   1.288 -        gestionnaires de source distribués parce qu'ils veulent garder un
   1.289 +        gestionnaires de révisions distribués parce qu'ils veulent garder un
   1.290          contrôle ferme sur leur projet, et ils pensent que les outils
   1.291          centralisés leur fournissent ce contrôle. Néanmoins, si c'est votre
   1.292          cas, sachez que si vous publiez votre dépôt CVS ou Subversion de
   1.293 @@ -386,7 +387,7 @@
   1.294        <para id="x_99">Beaucoup de projets commerciaux sont réalisés par des
   1.295          équipes éparpillées à travers le globe. Les contributeurs qui sont
   1.296          loin du serveur central devront subir des commandes lentes et même
   1.297 -        parfois peu fiables. Les solutions propriétaires de gestion de source
   1.298 +        parfois peu fiables. Les solutions propriétaires de gestion de révisions
   1.299          tentent de palier ce problème avec des réplications de sites distants
   1.300          qui sont à la fois coûteuses à mettre en place et lourdes à
   1.301          administrer. Un système distribué ne souffre pas de ce genre de
   1.302 @@ -396,24 +397,24 @@
   1.303          connexion longue distance souvent onéreuse.
   1.304        </para>
   1.305  
   1.306 -      <para id="x_9a">Les systèmes de gestion de source supportent
   1.307 +      <para id="x_9a">Les systèmes de gestion de révisions supportent
   1.308          généralement assez mal la monté en charge. Il n'est pas rare pour un
   1.309 -        gestionnaire de source centralisé pourtant onéreux de s'effondrer
   1.310 +        gestionnaire de révisions centralisé pourtant onéreux de s'effondrer
   1.311          sous la charge combinée d'une douzaine d'utilisateurs concurrents
   1.312          seulement. Une fois encore, la réponse à cette problématique est
   1.313          généralement encore la mise en place d'un ensemble complexe de
   1.314          serveurs synchronisés par un mécanisme de réplication. Dans le cas
   1.315 -        d'un gestionnaire de source distribué, la charge du serveur central
   1.316 -        &emdash; si vous avez un&emdash; est plusieurs fois inférieure (car
   1.317 +        d'un gestionnaire de révisions distribué, la charge du serveur central
   1.318 +        &emdash; si vous en avez un&emdash; est largement inférieure (car
   1.319          toutes les données sont déjà répliquées ailleurs), un simple serveur,
   1.320 -        pas très cher, peut gérer les besoins d'une plus grande équipe, et la
   1.321 +        peu onéreux, peut gérer les besoins d'une plus grande équipe, et la
   1.322          réplication pour balancer la charge devient le travail d'un simple
   1.323          script.
   1.324        </para>
   1.325  
   1.326        <para id="x_9b">Si vous avez des employés sur le terrain, en train de
   1.327          chercher à résoudre un souci sur le site d'un client, ils
   1.328 -        bénéficieront aussi d'un gestionnaire de source distribué. Cet outil
   1.329 +        bénéficieront aussi d'un gestionnaire de révisions distribué. Cet outil
   1.330          leur permettra de générer des versions personnalisées, d'essayer
   1.331          différentes solutions, en les isolant aisément les unes des autres,
   1.332          et de rechercher efficacement à travers l'historique des sources, la
   1.333 @@ -427,7 +428,7 @@
   1.334        <title>Pourquoi choisir Mercurial?</title>
   1.335  
   1.336        <para id="x_9c">Mercurial a plusieurs caractéristiques qui en font un
   1.337 -        choix particulièrement pertinent pour la gestion de source :
   1.338 +        choix particulièrement pertinent pour la gestion de révisions :
   1.339        </para>
   1.340      <itemizedlist>
   1.341        <listitem><para id="x_9d">Il est simple à apprendre et à utiliser.</para></listitem>
   1.342 @@ -437,7 +438,7 @@
   1.343      </itemizedlist>
   1.344  
   1.345      <para id="x_a1">Si vous êtes déjà familier d'un outil de gestion de
   1.346 -      source, vous serez capable de l'utiliser en moins de 5 minutes. Sinon,
   1.347 +      révisions, vous serez capable de l'utiliser en moins de 5 minutes. Sinon,
   1.348        ça ne sera pas beaucoup plus long. Les commandes utilisées par
   1.349        Mercurial, comme ses fonctionnalités, sont généralement uniformes et
   1.350        cohérentes, et vous pouvez ainsi garder en tête simplement quelques
   1.351 @@ -448,7 +449,7 @@
   1.352        avec Mercurial en quelques instants. Ajouter des modifications ou des
   1.353        branches, transférer ces modifications (localement ou via le réseau),
   1.354        et les opérations d'historique ou de statut sont aussi très rapides.
   1.355 -      Mercurial reste hors de votre chemin grâce à sa simplicité
   1.356 +      Mercurial ne vous encombre pas grâce à sa simplicité
   1.357        d'utilisation et sa rapidité d'exécution.
   1.358      </para>
   1.359  
   1.360 @@ -481,7 +482,7 @@
   1.361      <sect2>
   1.362        <title>Subversion</title>
   1.363  
   1.364 -      <para id="x_a6">Subversion est un des outils de gestion de source les
   1.365 +      <para id="x_a6">Subversion est un des outils de gestion de révisions les
   1.366          plus populaire, il fût développé pour remplacer CVS. Il a une
   1.367          architecture client/server centralisée.
   1.368        </para>
   1.369 @@ -539,7 +540,7 @@
   1.370          vous suivez une cinquantaine de versions d'un fichier incompressible
   1.371          de 10MB, l'occupation disque coté client d'un projet sous Subversion
   1.372          restera à peu près constante. A l'inverse, l'occupation disque du
   1.373 -        même projet sous n'importe lequel des gestionnaires de source
   1.374 +        même projet sous n'importe lequel des gestionnaires de révisions
   1.375          distribués grandira rapidement, proportionnellement aux nombres de
   1.376          versions, car les différences entre chaque révisions seront très
   1.377          grandes.
   1.378 @@ -568,7 +569,7 @@
   1.379      <sect2>
   1.380        <title>Git</title>
   1.381  
   1.382 -      <para id="x_af">Git est un outil de gestion de source distribué qui fût
   1.383 +      <para id="x_af">Git est un outil de gestion de révisions distribué qui fût
   1.384          développé pour gérer le code source de noyau de Linux. Comme
   1.385          Mercurial, sa conception initiale a été inspirée par Monotone.
   1.386        </para>
   1.387 @@ -605,7 +606,7 @@
   1.388          Git sont implémentées sous forme de scripts Shell ou Perl, et la
   1.389          qualité de ces scripts varie grandement. J'ai plusieurs fois constaté
   1.390          que certains de ces scripts étaient chargés en mémoire aveuglément et
   1.391 -        que la présence d'erreurs pouvait s'avérer fatal.
   1.392 +        que la présence d'erreurs pouvait s'avérer fatale.
   1.393        </para>
   1.394  
   1.395        <para id="x_b4">Mercurial peut importer l'historique d'un dépôt Git.</para>
   1.396 @@ -614,7 +615,7 @@
   1.397      <sect2>
   1.398        <title>CVS</title>
   1.399  
   1.400 -      <para id="x_b5">CVS est probablement l'outil de gestion de source le
   1.401 +      <para id="x_b5">CVS est probablement l'outil de gestion de révisions le
   1.402          plus utilisé aujourd'hui dans le monde. À cause de son manque de
   1.403          clarté interne, il n'est plus maintenu depuis plusieurs années.
   1.404        </para>
   1.405 @@ -622,8 +623,8 @@
   1.406        <para id="x_b6">Il a une architecture client/serveur centralisée. Il ne
   1.407          regroupe pas les modifications de fichiers dans une opération de
   1.408          <quote>commit</quote> atomique, ce qui permet à ses utilisateurs de
   1.409 -        <quote>casser le <emphasis>build</emphasis></quote> assez facilement
   1.410 -        : une personne peut effectuer une opération de <quote>commit</quote>
   1.411 +        <quote>casser le <emphasis>build</emphasis></quote> assez facilement :
   1.412 +        une personne peut effectuer une opération de <quote>commit</quote>
   1.413          sans problème puis être bloquée par besoin de fusion, avec comme
   1.414          conséquence néfaste, que les autres utilisateurs ne récupèreront
   1.415          qu'une partie de ses modifications. Ce problème affecte aussi la
   1.416 @@ -647,7 +648,7 @@
   1.417        <para id="x_b8">Mercurial peut importer l'historique d'un projet CVS.
   1.418          Néanmoins, il y a quelques principes à respecter; ce qui est vrai
   1.419          aussi pour les autres outils d'import de projet CVS. À cause de
   1.420 -        l'absence de <quote>commit</quote> atomique et gestion de version de
   1.421 +        l'absence de <quote>commit</quote> atomique et gestion de versions de
   1.422          l'arborescence, il n'est pas possible de reconstruire de manière
   1.423          précise l'ensemble de l'historique. Un travail de
   1.424          <quote>devinette</quote> est donc nécessaire, et les fichiers
   1.425 @@ -670,7 +671,7 @@
   1.426  
   1.427        <para id="x_ba">Perforce a une architecture client/serveur centralisée,
   1.428          sans aucun mécanisme de mise en cache de données coté client.
   1.429 -        Contrairement à la plupart des outils modernes de gestion de source,
   1.430 +        Contrairement à la plupart des outils modernes de gestion de révisions,
   1.431          Perforce exige de ses utilisateurs d'exécuter une commande pour
   1.432          informer le serveur central de tout fichier qu'ils souhaitent
   1.433          modifier.
   1.434 @@ -685,12 +686,12 @@
   1.435  
   1.436      </sect2>
   1.437      <sect2>
   1.438 -      <title>Choisir un outil de gestion de source</title>
   1.439 +      <title>Choisir un outil de gestion de révisions</title>
   1.440  
   1.441        <para id="x_bc">A l'exception de CVS, tous les outils listés ci-dessus
   1.442 -        ont des forces qui leur sont propres et qui correspondent à certaines
   1.443 +        ont des forces qui leurs sont propres et qui correspondent à certaines
   1.444          formes de projet. Il n'y a pas un seul meilleur outil de gestion de
   1.445 -        source qui correspondrait le mieux à toutes les situations.
   1.446 +        révisions qui correspondrait le mieux à toutes les situations.
   1.447        </para>
   1.448  
   1.449        <para id="x_bd">En guise exemple, Subversion est un très bon choix
   1.450 @@ -718,7 +719,7 @@
   1.451        effectuées depuis votre import initial.
   1.452      </para>
   1.453  
   1.454 -    <para id="x_c0">Les outils de gestion de source supportés par <literal
   1.455 +    <para id="x_c0">Les outils de gestion de révisions supportés par <literal
   1.456          role="hg-ext">convert</literal> sont :
   1.457      </para>
   1.458      <itemizedlist>
   1.459 @@ -745,9 +746,9 @@
   1.460    </sect1>
   1.461  
   1.462    <sect1>
   1.463 -    <title>Une courte histoire de la gestion de source</title>
   1.464 -
   1.465 -    <para id="x_c7">Le plus célèbre des anciens outils de gestion de source
   1.466 +    <title>Une courte histoire de la gestion de révisions</title>
   1.467 +
   1.468 +    <para id="x_c7">Le plus célèbre des anciens outils de gestion de révisions
   1.469        est <emphasis remap="it">SCCS</emphasis> (Source Code Control System)},
   1.470        que Marc Rochkind conçu dans les laboratoires de recherche de Bell
   1.471        (<emphasis remap="it">Bell Labs</emphasis>), dans le début des années
   1.472 @@ -796,12 +797,12 @@
   1.473        l'historique du projet. L'espace de travail client ne contient qu'une
   1.474        copie de la dernière version du projet, et quelques métadonnées pour
   1.475        indiquer où le serveur se trouve. CVS a été un grand succès,
   1.476 -      aujourd'hui il est probablement l'outil de gestion de contrôle le plus
   1.477 +      aujourd'hui il est probablement l'outil de gestion de révisions le plus
   1.478        utilisé au monde.
   1.479      </para>
   1.480      
   1.481      <para>Au début des années 1990, Sun Microsystems développa un premier
   1.482 -      outil de gestion de source distribué, nommé TeamWare. Un espace de
   1.483 +      outil de gestion de révisions distribué, nommé TeamWare. Un espace de
   1.484        travail TeamWare contient une copie complète de l'historique du projet.
   1.485        TeamWare n'a pas de notion de dépôt central. (CVS utilisait RCS pour le
   1.486        stockage de l'historique, TeamWare utilisait SCCS).
   1.487 @@ -831,10 +832,10 @@
   1.488      </para>
   1.489      
   1.490      <para>Plus ou moins simultanément, Graydon Hoare a commencé sur
   1.491 -      l'ambitieux système de gestion distribué Monotone. Bien que Monotone
   1.492 +      l'ambitieux système de gestion distribuée Monotone. Bien que Monotone
   1.493        corrige plusieurs défauts de CVS tout en offrant une architecture
   1.494        <quote>peer-to-peer</quote>, il va aussi plus loin que la plupart des
   1.495 -      outils de révision de manière assez innovante. Il utilise des
   1.496 +      outils de gestion de révisions de manière assez innovante. Il utilise des
   1.497        <quote>hashs</quote> cryptographiques comme identifiants, et il a une
   1.498        notion complète de <quote>confiance</quote> du code issu des
   1.499        différentes sources.
   1.500 @@ -842,7 +843,7 @@
   1.501      
   1.502      <para>Mercurial est né en 2005. Bien que très influencé par Monotone,
   1.503        Mercurial se concentre sur la facilité d'utilisation, les performances
   1.504 -      et la capacité à monter en charge pour de très gros projets.
   1.505 +      et la capacité à monter en charge sur de très gros projets.
   1.506      </para>
   1.507    
   1.508    </sect1>