Commits

André Sintzoff committed 4650cdd

some typo and better french translation

Comments (0)

Files changed (1)

fr/ch01-intro.xml

 
 <chapter id="chap:intro">
   <?dbhtml filename="how-did-we-get-here.html"?>
-  <title>Comment en est on arrivé là ?</title>
+  <title>Comment en est-on arrivé là ?</title>
 
 <sect1>
 <title>À propos de la gestion de révisions. Pourquoi Mercurial ?</title>
 aux erreurs, ainsi, depuis longtemps, des logiciels existent pour
 résoudre cette problématique. Les premiers outils de gestion de révisions
 étaient destinés à aider un seul utilisateur, à automatiser la gestion
-des versions d'un seul fichier. Dans les dernières décades, cette cible
+des versions d'un seul fichier. Durant les dernières décennies, cette cible
 s'est largement agrandie, ils gèrent désormais de multiples fichiers, et
 aident un grand nombre de personnes à travailler ensemble. Les outils les
 plus modernes n'ont aucune difficulté à gérer plusieurs milliers de
 <para id="x_77">Une question fondamentale à propos des outils de gestion de
   révisions, qu'il s'agisse du projet d'une personne ou d'une grande équipe, est
   quels sont ses <emphasis>gains</emphasis> par rapport à ses
-  <emphasis>coût</emphasis>. Un outil qui est difficile à utiliser ou à
+  <emphasis>coûts</emphasis>. Un outil qui est difficile à utiliser ou à
   comprendre exigera un lourd effort d'adaptation.
 </para>
 
-<para id="x_78">Un projet de cinq milles personnes s'effondrera très
+<para id="x_78">Un projet de cinq mille personnes s'effondrera très
   certainement de lui même sans aucun processus et outil de gestion de
   révisions. Dans ce cas, le coût d'utilisation d'un logiciel de gestion de
-  révisions est dérisoire puisque <emphasis>sans</emphasis>, l'échec est presque
+  révisions est dérisoire puisque <emphasis>sans</emphasis> celui-ci, l'échec est presque
   garanti.
 </para>
 
 <para id="x_79">D'un autre coté, un <quote>rapide hack</quote> d'une personne
   peut sembler un contexte bien pauvre pour utiliser un outil de gestion de
   révisions, car, bien évidement le coût d'utilisation dépasse le coût total du
-  projet. N'est ce pas ?
+  projet. N'est-ce pas ?
 </para>
 
       <para id="x_7a">Mercurial supporte ces <emphasis>deux</emphasis>
         avec facilité sur le plus petit des projets. Cette simplicité
         signifie que vous n'avez pas de concept obscur ou de séquence de
         commandes défiant l'imagination, sans aucune corrélation avec
-        <emphasis>ce que vous êtes entrain de faire</emphasis>. En même
-        temps, ces mêmes performances et sa nature
+        ce que vous êtes <emphasis>réellement</emphasis> en train de faire. En même
+        temps, ses mêmes performances et sa nature
         <quote>peer-to-peer</quote> vous permettent d'adapter, sans
         difficulté, son utilisation à de très grands projets.
 </para>
 <title>À propos des exemples dans ce livre</title>
 
     <para id="x_84">Ce livre prend une approche non usuelle pour les exemples
-      de code. Tous les exemples sont en <quote>live</quote> &emdash; Chacun
+      de code. Tous les exemples sont en <quote>live</quote> &emdash; chacun
       est actuellement le résultat d'un script shell qui exécute les
-      commandes Mercurial que vous voyez. A chaque fois qu'une image du livre
+      commandes Mercurial que vous voyez. Chaque fois qu'une image du livre
       est construite à partir des sources, tous les scripts d'exemples sont
       lancés automatiquement, et leurs résultats effectifs sont comparés aux
       résultats attendus.</para>
 
-    <para id="x_85">L'avantage de dette approche est que les exemples sont
+    <para id="x_85">L'avantage de cette approche est que les exemples sont
       toujours précis ; ils décrivent <emphasis>exactement</emphasis> la
-      conduite de la version de Mercurial qui est mentionnée en entête du
-      livre. Si je met à jour la version de Mercurial que je suis en train de
+      comportement de la version de Mercurial qui est mentionnée en entête du
+      livre. Si je mets à jour la version de Mercurial que je suis en train de
       documenter, et que la sortie de certaines commandes change, la
       construction du livre échoue.</para>
 
       heures que vous verrez dans les exemples tendent à être
       <quote>écrasés</quote> ensemble, dans le sens où elles ne sont pas
       celles qu'elles auraient été si un humain avait tapé les commandes. En
-      effet, humain ne peut pas taper plus d'une commande toutes les quelques
+      effet, un humain ne peut pas taper plus d'une commande toutes les quelques
       secondes, avec le temps qui s'écoule, mes scripts d'exemples exécutent
       plusieurs commandes en une seconde.
     </para>
 
-    <para id="x_87">Une circonstance de ceci est que plusieurs commits
+    <para id="x_87">Comme exemple de ceci, plusieurs commits
       consécutifs dans un exemple peuvent apparaître comme ayant eu lieu
       durant la même seconde.
       Vous pouvez observer le phénomène dans l'exemple <literal
     <para id="x_88">Donc, lorsque vous lisez ces exemples, ne prêtez pas trop
       d'importance aux dates et heures que vous voyez dans la sortie des
       commandes. Cependant, <emphasis>soyez</emphasis> confiants que le
-      comportement que vous voyez est constant et reproductible 
+      comportement que vous voyez est cohérent et reproductible. 
     </para>
 
   </sect1>
 
     <para id="x_89">Il y a eu une tendance évidente dans le développement et
       l'utilisation d'outils de gestion de source depuis les quatre dernières
-      décades, au fur et à mesure que les utilisateurs se sont habitués à
+      décennies, au fur et à mesure que les utilisateurs se sont habitués à
       leur outils et se sont sentis contraints par leurs limitations.
     </para>
 
       </para>
 
       <para id="x_9a">Les systèmes de gestion de révisions supportent
-        généralement assez mal la monté en charge. Il n'est pas rare pour un
+        généralement assez mal la montée en charge. Il n'est pas rare pour un
         gestionnaire de révisions centralisé pourtant onéreux de s'effondrer
-        sous la charge combinée d'une douzaine d'utilisateurs concurrents
+        sous la charge combinée de quelques dizaines d'utilisateurs concurrents
         seulement. Une fois encore, la réponse à cette problématique est
         généralement encore la mise en place d'un ensemble complexe de
         serveurs synchronisés par un mécanisme de réplication. Dans le cas
         &emdash; si vous en avez un&emdash; est largement inférieure (car
         toutes les données sont déjà répliquées ailleurs), un simple serveur,
         peu onéreux, peut gérer les besoins d'une plus grande équipe, et la
-        réplication pour balancer la charge devient le travail d'un simple
+        réplication pour répartir la charge devient le travail d'un simple
         script.
       </para>
 
         différentes solutions, en les isolant aisément les unes des autres,
         et de rechercher efficacement à travers l'historique des sources, la
         cause des bugs ou des régressions, tout ceci sans avoir besoin de la
-        moindre connexion au réseau de votre compagnie.
+        moindre connexion au réseau de votre société.
       </para>
 
     </sect2>
       ça ne sera pas beaucoup plus long. Les commandes utilisées par
       Mercurial, comme ses fonctionnalités, sont généralement uniformes et
       cohérentes, et vous pouvez ainsi garder en tête simplement quelques
-      règles générales, plutôt qu'un lot complexe d'exceptions.
+      règles générales, plutôt que de nombreuses exceptions.
     </para>
 
     <para id="x_a2">Sur un petit projet, vous pouvez commencer à travailler
     </para>
 
     <para id="x_a3">L'utilité de Mercurial ne se limite pas à de petits
-      projets: il est aussi utilisé par des projets ayant des centaines ou
+      projets : il est aussi utilisé par des projets ayant des centaines ou
       même des milliers de contributeurs, avec plusieurs dizaines de milliers
       de fichiers, et des centaines de méga octets de code source.
     </para>
       <title>Subversion</title>
 
       <para id="x_a6">Subversion est un des outils de gestion de révisions les
-        plus populaire, il fût développé pour remplacer CVS. Il a une
-        architecture client/server centralisée.
+        plus populaire, développé pour remplacer CVS. Il a une
+        architecture client/serveur centralisée.
       </para>
 
       <para id="x_a7">Subversion et Mercurial ont des noms de commandes très
         similaires pour les mêmes opérations, ainsi si vous êtes familier
         avec l'un, c'est facile d'apprendre l'autre. Ces deux outils sont
-        portables sur les systèmes d'exploitation les plus populaires.
+        portables sur tous les systèmes d'exploitation populaires.
       </para>
 
       <para id="x_a8">Avant la version 1.5, Subversion n'offrait aucune forme
       </para>
 
       <para id="x_ab">Subversion est largement supporté par les outils
-        tierces. Mercurial est actuellement encore en retrait de ce point de
+        tiers. Mercurial est actuellement encore en retrait de ce point de
         vue. L'écart se réduit néanmoins, en effet, certains des outils
         graphiques sont maintenant supérieurs à leurs équivalents Subversion.
         Comme Mercurial, Subversion dispose d'un excellent manuel
         doivent suivre un ensemble de larges fichiers binaires et opaques. Si
         vous suivez une cinquantaine de versions d'un fichier incompressible
         de 10MB, l'occupation disque coté client d'un projet sous Subversion
-        restera à peu près constante. A l'inverse, l'occupation disque du
+        restera à peu près constante. À l'inverse, l'occupation disque du
         même projet sous n'importe lequel des gestionnaires de révisions
         distribués grandira rapidement, proportionnellement aux nombres de
-        versions, car les différences entre chaque révisions seront très
+        versions, car les différences entre chaque révision seront très
         grandes.
       </para>
 
     <sect2>
       <title>Git</title>
 
-      <para id="x_af">Git est un outil de gestion de révisions distribué qui fût
+      <para id="x_af">Git est un outil de gestion de révisions distribué qui a été
         développé pour gérer le code source de noyau de Linux. Comme
         Mercurial, sa conception initiale a été inspirée par Monotone.
       </para>
       </para>
 
       <para id="x_b8">Mercurial peut importer l'historique d'un projet CVS.
-        Néanmoins, il y a quelques principes à respecter; ce qui est vrai
+        Néanmoins, il y a quelques principes à respecter ; ce qui est vrai
         aussi pour les autres outils d'import de projet CVS. À cause de
         l'absence de <quote>commit</quote> atomique et gestion de versions de
         l'arborescence, il n'est pas possible de reconstruire de manière
       <title>Outils propriétaires</title>
 
       <para id="x_ba">Perforce a une architecture client/serveur centralisée,
-        sans aucun mécanisme de mise en cache de données coté client.
+        sans aucun mécanisme de mise en cache de données côté client.
         Contrairement à la plupart des outils modernes de gestion de révisions,
         Perforce exige de ses utilisateurs d'exécuter une commande pour
         informer le serveur central de tout fichier qu'ils souhaitent
 
       <para id="x_bb">Les performances de Perforce sont plutôt bonnes pour
         des petites équipes, mais elles s'effondrent rapidement lorsque le
-        nombre d'utilisateurs augmente au delà de la douzaine. Des
+        nombre d'utilisateurs augmente au delà de quelques dizaines. Des
         installations de Perforce assez larges nécessitent le déploiement de
         proxies pour supporter la montée en charge associée.
       </para>
     <sect2>
       <title>Choisir un outil de gestion de révisions</title>
 
-      <para id="x_bc">A l'exception de CVS, tous les outils listés ci-dessus
+      <para id="x_bc">À l'exception de CVS, tous les outils listés ci-dessus
         ont des forces qui leurs sont propres et qui correspondent à certaines
         formes de projet. Il n'y a pas un seul meilleur outil de gestion de
         révisions qui correspondrait le mieux à toutes les situations.
     </sect2>
   </sect1>
   <sect1>
-    <title>Migrer depuis un outil à Mercurial</title>
+    <title>Migrer depuis un outil vers Mercurial</title>
 
     <para id="x_bf">Mercurial est livré avec une extension nommée <literal
         role="hg-ext">convert</literal>, qui peut, de manière incrémentale
       central.
     </para>
     
-    <para>Brian Berliner reprit les scripts de Grune's et les réécrit en C,
+    <para id="x_ca">Brian Berliner reprit les scripts de Grune's et les réécrit en C,
       qu'il publia en 1989. Depuis, ce code a été modifié jusqu'à devenir la
       version moderne de CVS. CVS a acquis ainsi la capacité de fonctionner
       en réseau, transformant son architecture en client/serveur.
       utilisé au monde.
     </para>
     
-    <para>Au début des années 1990, Sun Microsystems développa un premier
+    <para id="x_cb">Au début des années 1990, Sun Microsystems développa un premier
       outil de gestion de révisions distribué, nommé TeamWare. Un espace de
       travail TeamWare contient une copie complète de l'historique du projet.
       TeamWare n'a pas de notion de dépôt central. (CVS utilisait RCS pour le
       stockage de l'historique, TeamWare utilisait SCCS).
     </para>
     
-    <para>Alors que les années 1990 avançaient, les utilisateurs ont pris
+    <para id="x_cc">Alors que les années 1990 avançaient, les utilisateurs ont pris
       conscience d'un certain nombre de problèmes avec CVS. Il enregistrait
       simultanément des modifications sur différents fichiers
       individuellement, au lieu de les regrouper dans une seule opération
-      cohérente et atomique. Il ne gère pas bien sa hiérarchie de fichier, il
+      cohérente et atomique. Il ne gère pas bien sa hiérarchie de fichiers, il
       est donc assez aisé de créer le chaos en renommant les fichiers et les
       répertoires. Pire encore, son code source est difficile à lire et à
-      maintenir, ce qui agrandit largement le <quote>niveau de
+      maintenir, ce qui augmente largement le <quote>niveau de
         souffrance</quote> associé à la réparation de ces problèmes
       d'architecture de manière prohibitive.
     </para>
     
-    <para>En 2001, Jim Blandy et Karl Fogel, deux développeurs qui avaient
+    <para id="x_cd">En 2001, Jim Blandy et Karl Fogel, deux développeurs qui avaient
       travaillé sur CVS, initièrent un projet pour le remplacer par un outil
       qui aurait une meilleure architecture et un code plus propre. Le
       résultat, Subversion, ne quitte pas le modèle centralisé et
-      client/server de CVS, mais ajoute les opérations de
+      client/serveur de CVS, mais ajoute les opérations de
       <quote>commit</quote> atomique sur de multiples fichiers, une meilleure
       gestion des espaces de noms, et d'autres fonctionnalités qui en font un
       meilleur outil que CVS. Depuis sa première publication, il est
       rapidement devenu très populaire.
     </para>
     
-    <para>Plus ou moins simultanément, Graydon Hoare a commencé sur
+    <para id="x_ce">Plus ou moins simultanément, Graydon Hoare a commencé sur
       l'ambitieux système de gestion distribuée Monotone. Bien que Monotone
       corrige plusieurs défauts de CVS tout en offrant une architecture
       <quote>peer-to-peer</quote>, il va aussi plus loin que la plupart des
       différentes sources.
     </para>
     
-    <para>Mercurial est né en 2005. Bien que très influencé par Monotone,
+    <para id="x_cf">Mercurial est né en 2005. Bien que très influencé par Monotone,
       Mercurial se concentre sur la facilité d'utilisation, les performances
       et la capacité à monter en charge sur de très gros projets.
     </para>