1.1 --- a/fr/ch01-intro.xml	Sun Sep 13 14:08:00 2009 +0200
     1.2 +++ b/fr/ch01-intro.xml	Sun Dec 13 16:35:56 2009 +0900
     1.3 @@ -2,7 +2,7 @@
     1.4  
     1.5  <chapter id="chap:intro">
     1.6    <?dbhtml filename="how-did-we-get-here.html"?>
     1.7 -  <title>Comment en est on arrivé là ?</title>
     1.8 +  <title>Comment en est-on arrivé là ?</title>
     1.9  
    1.10  <sect1>
    1.11  <title>À propos de la gestion de révisions. Pourquoi Mercurial ?</title>
    1.12 @@ -18,7 +18,7 @@
    1.13  aux erreurs, ainsi, depuis longtemps, des logiciels existent pour
    1.14  résoudre cette problématique. Les premiers outils de gestion de révisions
    1.15  étaient destinés à aider un seul utilisateur, à automatiser la gestion
    1.16 -des versions d'un seul fichier. Dans les dernières décades, cette cible
    1.17 +des versions d'un seul fichier. Durant les dernières décennies, cette cible
    1.18  s'est largement agrandie, ils gèrent désormais de multiples fichiers, et
    1.19  aident un grand nombre de personnes à travailler ensemble. Les outils les
    1.20  plus modernes n'ont aucune difficulté à gérer plusieurs milliers de
    1.21 @@ -73,21 +73,21 @@
    1.22  <para id="x_77">Une question fondamentale à propos des outils de gestion de
    1.23    révisions, qu'il s'agisse du projet d'une personne ou d'une grande équipe, est
    1.24    quels sont ses <emphasis>gains</emphasis> par rapport à ses
    1.25 -  <emphasis>coût</emphasis>. Un outil qui est difficile à utiliser ou à
    1.26 +  <emphasis>coûts</emphasis>. Un outil qui est difficile à utiliser ou à
    1.27    comprendre exigera un lourd effort d'adaptation.
    1.28  </para>
    1.29  
    1.30 -<para id="x_78">Un projet de cinq milles personnes s'effondrera très
    1.31 +<para id="x_78">Un projet de cinq mille personnes s'effondrera très
    1.32    certainement de lui même sans aucun processus et outil de gestion de
    1.33    révisions. Dans ce cas, le coût d'utilisation d'un logiciel de gestion de
    1.34 -  révisions est dérisoire puisque <emphasis>sans</emphasis>, l'échec est presque
    1.35 +  révisions est dérisoire puisque <emphasis>sans</emphasis> celui-ci, l'échec est presque
    1.36    garanti.
    1.37  </para>
    1.38  
    1.39  <para id="x_79">D'un autre coté, un <quote>rapide hack</quote> d'une personne
    1.40    peut sembler un contexte bien pauvre pour utiliser un outil de gestion de
    1.41    révisions, car, bien évidement le coût d'utilisation dépasse le coût total du
    1.42 -  projet. N'est ce pas ?
    1.43 +  projet. N'est-ce pas ?
    1.44  </para>
    1.45  
    1.46        <para id="x_7a">Mercurial supporte ces <emphasis>deux</emphasis>
    1.47 @@ -96,8 +96,8 @@
    1.48          avec facilité sur le plus petit des projets. Cette simplicité
    1.49          signifie que vous n'avez pas de concept obscur ou de séquence de
    1.50          commandes défiant l'imagination, sans aucune corrélation avec
    1.51 -        <emphasis>ce que vous êtes entrain de faire</emphasis>. En même
    1.52 -        temps, ces mêmes performances et sa nature
    1.53 +        ce que vous êtes <emphasis>réellement</emphasis> en train de faire. En même
    1.54 +        temps, ses mêmes performances et sa nature
    1.55          <quote>peer-to-peer</quote> vous permettent d'adapter, sans
    1.56          difficulté, son utilisation à de très grands projets.
    1.57  </para>
    1.58 @@ -152,17 +152,17 @@
    1.59  <title>À propos des exemples dans ce livre</title>
    1.60  
    1.61      <para id="x_84">Ce livre prend une approche non usuelle pour les exemples
    1.62 -      de code. Tous les exemples sont en <quote>live</quote> &emdash; Chacun
    1.63 +      de code. Tous les exemples sont en <quote>live</quote> &emdash; chacun
    1.64        est actuellement le résultat d'un script shell qui exécute les
    1.65 -      commandes Mercurial que vous voyez. A chaque fois qu'une image du livre
    1.66 +      commandes Mercurial que vous voyez. Chaque fois qu'une image du livre
    1.67        est construite à partir des sources, tous les scripts d'exemples sont
    1.68        lancés automatiquement, et leurs résultats effectifs sont comparés aux
    1.69        résultats attendus.</para>
    1.70  
    1.71 -    <para id="x_85">L'avantage de dette approche est que les exemples sont
    1.72 +    <para id="x_85">L'avantage de cette approche est que les exemples sont
    1.73        toujours précis ; ils décrivent <emphasis>exactement</emphasis> la
    1.74 -      conduite de la version de Mercurial qui est mentionnée en entête du
    1.75 -      livre. Si je met à jour la version de Mercurial que je suis en train de
    1.76 +      comportement de la version de Mercurial qui est mentionnée en entête du
    1.77 +      livre. Si je mets à jour la version de Mercurial que je suis en train de
    1.78        documenter, et que la sortie de certaines commandes change, la
    1.79        construction du livre échoue.</para>
    1.80  
    1.81 @@ -171,12 +171,12 @@
    1.82        heures que vous verrez dans les exemples tendent à être
    1.83        <quote>écrasés</quote> ensemble, dans le sens où elles ne sont pas
    1.84        celles qu'elles auraient été si un humain avait tapé les commandes. En
    1.85 -      effet, humain ne peut pas taper plus d'une commande toutes les quelques
    1.86 +      effet, un humain ne peut pas taper plus d'une commande toutes les quelques
    1.87        secondes, avec le temps qui s'écoule, mes scripts d'exemples exécutent
    1.88        plusieurs commandes en une seconde.
    1.89      </para>
    1.90  
    1.91 -    <para id="x_87">Une circonstance de ceci est que plusieurs commits
    1.92 +    <para id="x_87">Comme exemple de ceci, plusieurs commits
    1.93        consécutifs dans un exemple peuvent apparaître comme ayant eu lieu
    1.94        durant la même seconde.
    1.95        Vous pouvez observer le phénomène dans l'exemple <literal
    1.96 @@ -186,7 +186,7 @@
    1.97      <para id="x_88">Donc, lorsque vous lisez ces exemples, ne prêtez pas trop
    1.98        d'importance aux dates et heures que vous voyez dans la sortie des
    1.99        commandes. Cependant, <emphasis>soyez</emphasis> confiants que le
   1.100 -      comportement que vous voyez est constant et reproductible 
   1.101 +      comportement que vous voyez est cohérent et reproductible. 
   1.102      </para>
   1.103  
   1.104    </sect1>
   1.105 @@ -198,7 +198,7 @@
   1.106  
   1.107      <para id="x_89">Il y a eu une tendance évidente dans le développement et
   1.108        l'utilisation d'outils de gestion de source depuis les quatre dernières
   1.109 -      décades, au fur et à mesure que les utilisateurs se sont habitués à
   1.110 +      décennies, au fur et à mesure que les utilisateurs se sont habitués à
   1.111        leur outils et se sont sentis contraints par leurs limitations.
   1.112      </para>
   1.113  
   1.114 @@ -398,9 +398,9 @@
   1.115        </para>
   1.116  
   1.117        <para id="x_9a">Les systèmes de gestion de révisions supportent
   1.118 -        généralement assez mal la monté en charge. Il n'est pas rare pour un
   1.119 +        généralement assez mal la montée en charge. Il n'est pas rare pour un
   1.120          gestionnaire de révisions centralisé pourtant onéreux de s'effondrer
   1.121 -        sous la charge combinée d'une douzaine d'utilisateurs concurrents
   1.122 +        sous la charge combinée de quelques dizaines d'utilisateurs concurrents
   1.123          seulement. Une fois encore, la réponse à cette problématique est
   1.124          généralement encore la mise en place d'un ensemble complexe de
   1.125          serveurs synchronisés par un mécanisme de réplication. Dans le cas
   1.126 @@ -408,7 +408,7 @@
   1.127          &emdash; si vous en avez un&emdash; est largement inférieure (car
   1.128          toutes les données sont déjà répliquées ailleurs), un simple serveur,
   1.129          peu onéreux, peut gérer les besoins d'une plus grande équipe, et la
   1.130 -        réplication pour balancer la charge devient le travail d'un simple
   1.131 +        réplication pour répartir la charge devient le travail d'un simple
   1.132          script.
   1.133        </para>
   1.134  
   1.135 @@ -419,7 +419,7 @@
   1.136          différentes solutions, en les isolant aisément les unes des autres,
   1.137          et de rechercher efficacement à travers l'historique des sources, la
   1.138          cause des bugs ou des régressions, tout ceci sans avoir besoin de la
   1.139 -        moindre connexion au réseau de votre compagnie.
   1.140 +        moindre connexion au réseau de votre société.
   1.141        </para>
   1.142  
   1.143      </sect2>
   1.144 @@ -442,7 +442,7 @@
   1.145        ça ne sera pas beaucoup plus long. Les commandes utilisées par
   1.146        Mercurial, comme ses fonctionnalités, sont généralement uniformes et
   1.147        cohérentes, et vous pouvez ainsi garder en tête simplement quelques
   1.148 -      règles générales, plutôt qu'un lot complexe d'exceptions.
   1.149 +      règles générales, plutôt que de nombreuses exceptions.
   1.150      </para>
   1.151  
   1.152      <para id="x_a2">Sur un petit projet, vous pouvez commencer à travailler
   1.153 @@ -454,7 +454,7 @@
   1.154      </para>
   1.155  
   1.156      <para id="x_a3">L'utilité de Mercurial ne se limite pas à de petits
   1.157 -      projets: il est aussi utilisé par des projets ayant des centaines ou
   1.158 +      projets : il est aussi utilisé par des projets ayant des centaines ou
   1.159        même des milliers de contributeurs, avec plusieurs dizaines de milliers
   1.160        de fichiers, et des centaines de méga octets de code source.
   1.161      </para>
   1.162 @@ -483,14 +483,14 @@
   1.163        <title>Subversion</title>
   1.164  
   1.165        <para id="x_a6">Subversion est un des outils de gestion de révisions les
   1.166 -        plus populaire, il fût développé pour remplacer CVS. Il a une
   1.167 -        architecture client/server centralisée.
   1.168 +        plus populaire, développé pour remplacer CVS. Il a une
   1.169 +        architecture client/serveur centralisée.
   1.170        </para>
   1.171  
   1.172        <para id="x_a7">Subversion et Mercurial ont des noms de commandes très
   1.173          similaires pour les mêmes opérations, ainsi si vous êtes familier
   1.174          avec l'un, c'est facile d'apprendre l'autre. Ces deux outils sont
   1.175 -        portables sur les systèmes d'exploitation les plus populaires.
   1.176 +        portables sur tous les systèmes d'exploitation populaires.
   1.177        </para>
   1.178  
   1.179        <para id="x_a8">Avant la version 1.5, Subversion n'offrait aucune forme
   1.180 @@ -527,7 +527,7 @@
   1.181        </para>
   1.182  
   1.183        <para id="x_ab">Subversion est largement supporté par les outils
   1.184 -        tierces. Mercurial est actuellement encore en retrait de ce point de
   1.185 +        tiers. Mercurial est actuellement encore en retrait de ce point de
   1.186          vue. L'écart se réduit néanmoins, en effet, certains des outils
   1.187          graphiques sont maintenant supérieurs à leurs équivalents Subversion.
   1.188          Comme Mercurial, Subversion dispose d'un excellent manuel
   1.189 @@ -539,10 +539,10 @@
   1.190          doivent suivre un ensemble de larges fichiers binaires et opaques. Si
   1.191          vous suivez une cinquantaine de versions d'un fichier incompressible
   1.192          de 10MB, l'occupation disque coté client d'un projet sous Subversion
   1.193 -        restera à peu près constante. A l'inverse, l'occupation disque du
   1.194 +        restera à peu près constante. À l'inverse, l'occupation disque du
   1.195          même projet sous n'importe lequel des gestionnaires de révisions
   1.196          distribués grandira rapidement, proportionnellement aux nombres de
   1.197 -        versions, car les différences entre chaque révisions seront très
   1.198 +        versions, car les différences entre chaque révision seront très
   1.199          grandes.
   1.200        </para>
   1.201  
   1.202 @@ -569,7 +569,7 @@
   1.203      <sect2>
   1.204        <title>Git</title>
   1.205  
   1.206 -      <para id="x_af">Git est un outil de gestion de révisions distribué qui fût
   1.207 +      <para id="x_af">Git est un outil de gestion de révisions distribué qui a été
   1.208          développé pour gérer le code source de noyau de Linux. Comme
   1.209          Mercurial, sa conception initiale a été inspirée par Monotone.
   1.210        </para>
   1.211 @@ -646,7 +646,7 @@
   1.212        </para>
   1.213  
   1.214        <para id="x_b8">Mercurial peut importer l'historique d'un projet CVS.
   1.215 -        Néanmoins, il y a quelques principes à respecter; ce qui est vrai
   1.216 +        Néanmoins, il y a quelques principes à respecter ; ce qui est vrai
   1.217          aussi pour les autres outils d'import de projet CVS. À cause de
   1.218          l'absence de <quote>commit</quote> atomique et gestion de versions de
   1.219          l'arborescence, il n'est pas possible de reconstruire de manière
   1.220 @@ -670,7 +670,7 @@
   1.221        <title>Outils propriétaires</title>
   1.222  
   1.223        <para id="x_ba">Perforce a une architecture client/serveur centralisée,
   1.224 -        sans aucun mécanisme de mise en cache de données coté client.
   1.225 +        sans aucun mécanisme de mise en cache de données côté client.
   1.226          Contrairement à la plupart des outils modernes de gestion de révisions,
   1.227          Perforce exige de ses utilisateurs d'exécuter une commande pour
   1.228          informer le serveur central de tout fichier qu'ils souhaitent
   1.229 @@ -679,7 +679,7 @@
   1.230  
   1.231        <para id="x_bb">Les performances de Perforce sont plutôt bonnes pour
   1.232          des petites équipes, mais elles s'effondrent rapidement lorsque le
   1.233 -        nombre d'utilisateurs augmente au delà de la douzaine. Des
   1.234 +        nombre d'utilisateurs augmente au delà de quelques dizaines. Des
   1.235          installations de Perforce assez larges nécessitent le déploiement de
   1.236          proxies pour supporter la montée en charge associée.
   1.237        </para>
   1.238 @@ -688,7 +688,7 @@
   1.239      <sect2>
   1.240        <title>Choisir un outil de gestion de révisions</title>
   1.241  
   1.242 -      <para id="x_bc">A l'exception de CVS, tous les outils listés ci-dessus
   1.243 +      <para id="x_bc">À l'exception de CVS, tous les outils listés ci-dessus
   1.244          ont des forces qui leurs sont propres et qui correspondent à certaines
   1.245          formes de projet. Il n'y a pas un seul meilleur outil de gestion de
   1.246          révisions qui correspondrait le mieux à toutes les situations.
   1.247 @@ -708,7 +708,7 @@
   1.248      </sect2>
   1.249    </sect1>
   1.250    <sect1>
   1.251 -    <title>Migrer depuis un outil à Mercurial</title>
   1.252 +    <title>Migrer depuis un outil vers Mercurial</title>
   1.253  
   1.254      <para id="x_bf">Mercurial est livré avec une extension nommée <literal
   1.255          role="hg-ext">convert</literal>, qui peut, de manière incrémentale
   1.256 @@ -789,7 +789,7 @@
   1.257        central.
   1.258      </para>
   1.259      
   1.260 -    <para>Brian Berliner reprit les scripts de Grune's et les réécrit en C,
   1.261 +    <para id="x_ca">Brian Berliner reprit les scripts de Grune's et les réécrit en C,
   1.262        qu'il publia en 1989. Depuis, ce code a été modifié jusqu'à devenir la
   1.263        version moderne de CVS. CVS a acquis ainsi la capacité de fonctionner
   1.264        en réseau, transformant son architecture en client/serveur.
   1.265 @@ -801,37 +801,37 @@
   1.266        utilisé au monde.
   1.267      </para>
   1.268      
   1.269 -    <para>Au début des années 1990, Sun Microsystems développa un premier
   1.270 +    <para id="x_cb">Au début des années 1990, Sun Microsystems développa un premier
   1.271        outil de gestion de révisions distribué, nommé TeamWare. Un espace de
   1.272        travail TeamWare contient une copie complète de l'historique du projet.
   1.273        TeamWare n'a pas de notion de dépôt central. (CVS utilisait RCS pour le
   1.274        stockage de l'historique, TeamWare utilisait SCCS).
   1.275      </para>
   1.276      
   1.277 -    <para>Alors que les années 1990 avançaient, les utilisateurs ont pris
   1.278 +    <para id="x_cc">Alors que les années 1990 avançaient, les utilisateurs ont pris
   1.279        conscience d'un certain nombre de problèmes avec CVS. Il enregistrait
   1.280        simultanément des modifications sur différents fichiers
   1.281        individuellement, au lieu de les regrouper dans une seule opération
   1.282 -      cohérente et atomique. Il ne gère pas bien sa hiérarchie de fichier, il
   1.283 +      cohérente et atomique. Il ne gère pas bien sa hiérarchie de fichiers, il
   1.284        est donc assez aisé de créer le chaos en renommant les fichiers et les
   1.285        répertoires. Pire encore, son code source est difficile à lire et à
   1.286 -      maintenir, ce qui agrandit largement le <quote>niveau de
   1.287 +      maintenir, ce qui augmente largement le <quote>niveau de
   1.288          souffrance</quote> associé à la réparation de ces problèmes
   1.289        d'architecture de manière prohibitive.
   1.290      </para>
   1.291      
   1.292 -    <para>En 2001, Jim Blandy et Karl Fogel, deux développeurs qui avaient
   1.293 +    <para id="x_cd">En 2001, Jim Blandy et Karl Fogel, deux développeurs qui avaient
   1.294        travaillé sur CVS, initièrent un projet pour le remplacer par un outil
   1.295        qui aurait une meilleure architecture et un code plus propre. Le
   1.296        résultat, Subversion, ne quitte pas le modèle centralisé et
   1.297 -      client/server de CVS, mais ajoute les opérations de
   1.298 +      client/serveur de CVS, mais ajoute les opérations de
   1.299        <quote>commit</quote> atomique sur de multiples fichiers, une meilleure
   1.300        gestion des espaces de noms, et d'autres fonctionnalités qui en font un
   1.301        meilleur outil que CVS. Depuis sa première publication, il est
   1.302        rapidement devenu très populaire.
   1.303      </para>
   1.304      
   1.305 -    <para>Plus ou moins simultanément, Graydon Hoare a commencé sur
   1.306 +    <para id="x_ce">Plus ou moins simultanément, Graydon Hoare a commencé sur
   1.307        l'ambitieux système de gestion distribuée Monotone. Bien que Monotone
   1.308        corrige plusieurs défauts de CVS tout en offrant une architecture
   1.309        <quote>peer-to-peer</quote>, il va aussi plus loin que la plupart des
   1.310 @@ -841,7 +841,7 @@
   1.311        différentes sources.
   1.312      </para>
   1.313      
   1.314 -    <para>Mercurial est né en 2005. Bien que très influencé par Monotone,
   1.315 +    <para id="x_cf">Mercurial est né en 2005. Bien que très influencé par Monotone,
   1.316        Mercurial se concentre sur la facilité d'utilisation, les performances
   1.317        et la capacité à monter en charge sur de très gros projets.
   1.318      </para>