1.1 --- a/fr/ch01-intro.xml	Sun Aug 16 04:58:01 2009 +0200
     1.2 +++ b/fr/ch01-intro.xml	Tue Sep 01 17:00:12 2009 +0200
     1.3 @@ -1,19 +1,19 @@
     1.4  <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
     1.5  
     1.6 -<chapter>
     1.7 -<title>Introduction</title>
     1.8 -<para>\label{chap:intro}</para>
     1.9 +<chapter id="chap:intro">
    1.10 +  <?dbhtml filename="how-did-we-get-here.html"?>
    1.11 +  <title>Comment en est on arrivé là ?</title>
    1.12  
    1.13  <sect1>
    1.14  <title>À propos de la gestion source</title>
    1.15  
    1.16 -<para>La gestion de sources est un processus permettant de gérer différentes
    1.17 +    <para id="x_6d">La gestion de sources est un processus permettant de gérer différentes
    1.18  versions de la même information. Dans sa forme la plus simple, c'est
    1.19  ce que tout le monde fait manuellement : quand vous modifiez
    1.20  un fichier, vous le sauvegardez sous un nouveau nom contenant un numéro,
    1.21  à chaque fois plus grand que celui de la version précédente.</para>
    1.22  
    1.23 -<para>Ce genre de gestion de version manuelle est cependant facilement sujette
    1.24 +    <para id="x_6e">Ce genre de gestion de version manuelle est cependant facilement sujette
    1.25  à des erreurs, ainsi, depuis longtemps, des logiciels existent pour
    1.26  résoudre cette problématique. Les premiers outils de gestion de sources
    1.27  étaient destinés à aider un seul utilisateur, à automatiser la gestion
    1.28 @@ -24,230 +24,194 @@
    1.29  personnes travaillant ensemble sur des projets regroupant plusieurs
    1.30  centaines de milliers de fichiers.</para>
    1.31  
    1.32 -<sect2>
    1.33 -<title>Pourquoi utiliser un gestionnaire de source ?</title>
    1.34 -
    1.35 -<para>Il y a de nombreuses raisons pour que vous ou votre équipe souhaitiez
    1.36 +    <para id="x_6f">L'arrivée de la gestion de révision distribuée est
    1.37 +    relativement récente, et, pour le moment, ce nouveau domaine a grandi
    1.38 +    grâce à la volonté des gens d'explorer ces territoires encores inconnues.
    1.39 +    </para>
    1.40 +
    1.41 +    <para id="x_70">J'écris un livre sur la gestion de révision distribuée
    1.42 +    parce que je pense qu'il s'agit d'un sujet important qui mérite un guide
    1.43 +    du terrain. J'ai choisi d'écrire un livre sur Mercurial car il est
    1.44 +    l'outil le plus facile pour découvrir ce nouveau domaine, tout en étant
    1.45 +    un outil efficase qui répond aux demandes d'environement réel et
    1.46 +    difficile, là où d'autres outils de révisions s'effondre.</para>
    1.47 +
    1.48 +    <sect2>
    1.49 +      <title>Pourquoi utiliser un gestionnaire de source ?</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 -<itemizedlist>
    1.54 -<listitem><para>L'outil se chargera de suivre l'évolution de votre projet, sans
    1.55 +
    1.56 +      <itemizedlist>
    1.57 +	<listitem><para id="x_72">L'outil se chargera de suivre l'évolution de votre projet, sans
    1.58  que vous n'ayez à le faire. Pour chaque modification, vous aurez à votre
    1.59  disposition un journal indiquant <emphasis>qui</emphasis> a fait quoi, <emphasis>pourquoi</emphasis>
    1.60  ils l'ont fait, <emphasis>quand</emphasis> ils l'ont fait, et <emphasis>ce</emphasis> qu'ils ont
    1.61  modifiés.</para>
    1.62  </listitem>
    1.63 -<listitem><para>Quand vous travaillez avec d'autres personnes, les logiciels de
    1.64 +<listitem><para id="x_73">Quand vous travaillez avec d'autres personnes, les logiciels de
    1.65  gestion de source facilitent le travail collaboratif. Par exemple, quand
    1.66  plusieurs personnes font, plus ou moins simultanément, des modifications
    1.67  incompatibles, le logiciel vous aidera à identifier et à résoudre les conflits.</para>
    1.68  </listitem>
    1.69 -<listitem><para>L'outil vous aidera à réparer vos erreurs. Si vous effectuez un changement
    1.70 +<listitem><para id="x_74">L'outil vous aidera à réparer vos erreurs. Si vous effectuez un changement
    1.71  qui se révèle être une erreur, vous pourrez revenir à une version
    1.72  antérieure d'un fichier ou même d'un ensemble de fichiers. En fait, un outil de
    1.73  gestion de source <emphasis>vraiment</emphasis> efficace vous permettra d'identifier à quel
    1.74  moment le problème est apparu (voir la section <xref linkend="sec:undo:bisect"/> pour plus
    1.75  de détails).</para>
    1.76  </listitem>
    1.77 -<listitem><para>L'outil vous permettra aussi de travailler sur plusieurs versions différentes
    1.78 +<listitem><para id="x_75">L'outil vous permettra aussi de travailler sur plusieurs versions différentes
    1.79  de votre projet et à gérer l'écart entre chacune.</para>
    1.80  </listitem></itemizedlist>
    1.81 -<para>La plupart de ces raisons ont autant d'importances &emdash;du moins en théorie&emdash; que
    1.82 +<para id="x_76">La plupart de ces raisons ont autant d'importances &emdash;du moins en théorie&emdash; que
    1.83  vous travailliez sur un projet pour vous, ou avec une centaine d'autres
    1.84  personnes.
    1.85  </para>
    1.86  
    1.87 -<para>Une question fondamentale à propos des outils de gestion de source, qu'il s'agisse
    1.88 +<para id="x_77">Une question fondamentale à propos des outils de gestion de source, qu'il s'agisse
    1.89  du projet d'une personne ou d'une grande équipe, est quels sont ses
    1.90  <emphasis>avantages</emphasis> par rapport à ses <emphasis>coûts</emphasis>. Un outil qui est difficile à
    1.91  utiliser ou à comprendre exigera un lourd effort d'adaptation.
    1.92  </para>
    1.93  
    1.94 -<para>Un projet de cinq milles personnes s'effondrera très certainement de lui même
    1.95 +<para id="x_78">)Un projet de cinq milles personnes s'effondrera très certainement de lui même
    1.96  sans aucun processus et outil de gestion de source. Dans ce cas, le coût
    1.97  d'utilisation d'un logiciel de gestion de source est dérisoire puisque
    1.98  <emphasis>sans</emphasis>, l'échec est presque garanti.
    1.99  </para>
   1.100  
   1.101 -<para>D'un autre coté, un <quote>rapide hack</quote> d'une personne peut sembler un contexte
   1.102 +<para id="x_79">D'un autre coté, un <quote>rapide hack</quote> d'une personne peut sembler un contexte
   1.103  bien pauvre pour utiliser un outil de gestion de source, car, bien évidement
   1.104  le coût d'utilisation dépasse le coût total du projet. N'est ce pas ?
   1.105  </para>
   1.106  
   1.107 -<para>Mercurial supporte ces <emphasis>deux</emphasis> échelles de travail. Vous pouvez apprendre
   1.108 +      <para id="x_7a">Mercurial supporte ces <emphasis>deux</emphasis> échelles de travail. Vous pouvez apprendre
   1.109  les bases en quelques minutes seulement, et, grâce à sa performance, vous pouvez
   1.110  l'utiliser avec facilité sur le plus petit des projets. Cette simplicité
   1.111  signifie que vous n'avez pas de concept obscurs ou de séquence de commandes
   1.112 -défiant l'imagination, sans aucune corrélation avec \emph{ce que vous êtes
   1.113 -vraiment en train de faire}. En même temps, ces mêmes performances et sa
   1.114 +défiant l'imagination, sans aucune corrélation avec <emphasis>ce que vous
   1.115 +êtes entrain de faire</emphasis>. En même temps, ces mêmes performances et sa
   1.116  nature <quote>peer-to-peer</quote> vous permettent d'augmenter, sans difficulté, son
   1.117  utilisation à de très grands projets.
   1.118  </para>
   1.119  
   1.120 -<para>Aucun outil de gestion de source ne peut sauver un projet mal mené, mais un
   1.121 +      <para id="x_7b">Aucun outil de gestion de source ne peut sauver un projet mal mené, mais un
   1.122  bon outil peut rendre beaucoup plus fluide votre travail.
   1.123  </para>
   1.124  
   1.125 -</sect2>
   1.126 -<sect2>
   1.127 -<title>Les multiples noms de la gestion de source</title>
   1.128 -
   1.129 -<para>La gestion de source\footnote{NdT: J'ai utilisé systématiquement le terme
   1.130 +    </sect2>
   1.131 +
   1.132 +    <sect2>
   1.133 +      <title>Les multiples noms de la gestion de source</title>
   1.134 +
   1.135 +      <para id="x_7c">La gestion de source<!--
   1.136 +      TODO:<footnote><J'ai utilisé systématiquement le terme
   1.137  <quote>gestion de source</quote> à travers tout l'ouvrage. Ce n'est pas forcement la
   1.138  meilleure traduction, et ceci peut rendre la lecture un peu lourde, mais je
   1.139 -pense que le document y gagne en clarté et en précision.} est un domaine
   1.140 +pense que le document y gagne en clarté et en précision. --> est un domaine
   1.141  divers, tellement qu'il n'existe pas une seul nom ou acronyme pour le désigner.
   1.142  Voilà quelqu'uns des noms ou
   1.143 -acronymes que vous rencontrerez le plus souvent\footnote{NdT: J'ai conservé la
   1.144 +acronymes que vous rencontrerez le plus souvent <!-- TODO:<footnote> J'ai conservé la
   1.145  liste des noms en anglais pour des raisons de commodité (ils sont plus
   1.146  <quote>googelable</quote>). En outre, j'ai opté  pour conserver l'ensemble des opérations de
   1.147  Mercurial (\textit{commit},\textit{push}, \textit{pull},...) en anglais, là
   1.148  aussi pour faciliter la lecture d'autres documents en anglais, ainsi que
   1.149 -l'utilisation de Mercurial}.
   1.150 +l'utilisation de Mercurial. -->
   1.151  </para>
   1.152  
   1.153  <para>:
   1.154  </para>
   1.155 -<itemizedlist>
   1.156 -<listitem><para>\textit{Revision control (RCS)} ;
   1.157 -</para>
   1.158 -</listitem>
   1.159 -<listitem><para>Software configuration management (SCM), ou \textit{configuration management} ;
   1.160 -</para>
   1.161 -</listitem>
   1.162 -<listitem><para>\textit{Source code management} ;
   1.163 -</para>
   1.164 -</listitem>
   1.165 -<listitem><para>\textit{Source code control}, ou \textit{source control} ;
   1.166 -</para>
   1.167 -</listitem>
   1.168 -<listitem><para>\textit{Version control (VCS)}.
   1.169 -</para>
   1.170 -</listitem></itemizedlist>
   1.171 -
   1.172 -<para>Certaines personnes prétendent que ces termes ont en fait des sens
   1.173 +
   1.174 +      <itemizedlist>
   1.175 +	<listitem><para id="x_7d">Revision control (RCS)</para></listitem>
   1.176 +	<listitem><para id="x_7e">Software configuration management (SCM), or
   1.177 +	    configuration management</para></listitem>
   1.178 +	<listitem><para id="x_7f">Source code management</para></listitem>
   1.179 +	<listitem><para id="x_80">Source code control, or source
   1.180 +	    control</para></listitem>
   1.181 +	<listitem><para id="x_81">Version control
   1.182 +	    (VCS)</para></listitem></itemizedlist>
   1.183 +
   1.184 + <para id="x_82">Certaines personnes prétendent que ces termes ont en fait des sens
   1.185  différents mais en pratique ils se recouvrent tellement qu'il n'y a pas
   1.186  réellement de manière pertinente de les distinguer.
   1.187  </para>
   1.188  
   1.189 -</sect2>
   1.190 -</sect1>
   1.191 -<sect1>
   1.192 -<title>Une courte histoire de la gestion de source</title>
   1.193 -
   1.194 -<para>Le plus célèbre des anciens outils de gestion de source est \textit{SCCS
   1.195 -(Source Code Control System)}, que Marc Rochkind conçu dans les laboratoires de
   1.196 -recherche de Bell (\textit{Bell Labs}), dans le début des années 70.
   1.197 -\textit{SCCS} ne fonctionnait que sur des fichiers individuels, et obligeait chaque
   1.198 -personne travaillant sur le projet d'avoir un accès à un répertoire de
   1.199 -travail commun, sur le même système. Seulement une seule personne pouvait
   1.200 -modifier un fichier au même moment, ce fonctionnement était assuré par
   1.201 -l'utilisation de verrou (<quote>lock</quote>). Il était courant que des personnes
   1.202 -verrouillent des fichiers, et plus tard, oublient de le déverrouiller;
   1.203 -empêchant n'importe qui d'autre de travailler sur ces fichiers sans l'aide de
   1.204 -l'administrateur...
   1.205 -</para>
   1.206 -
   1.207 -<para>Walter Tichy a développé une alternative libre à \textit{SCCS} au début des
   1.208 -années 80, qu'il nomma \textit{RSC (Revison Control System)}.  Comme
   1.209 -\textit{SCCS}, \textit{RCS} demandait aux développeurs de travailler sur le même
   1.210 -répertoire partagé, et de verrouiller les
   1.211 -fichiers pour se prémunir de tout conflit issu de modifications concurrentes.
   1.212 -</para>
   1.213 -
   1.214 -<para>Un peu plus tard dans les années 1980, Dick Grune utilisa \textit{RCS} comme
   1.215 -une brique de base pour un ensemble de scripts \textit{shell} qu'il intitula
   1.216 -cmt, avant de la renommer en \textit{CVS (Concurrent Versions System)}.  La
   1.217 -grande innovation de CVS était que les développeurs pouvaient travailler
   1.218 -simultanément et indépendamment dans leur propre espace de travail. Ces espaces
   1.219 -de travail privés assuraient que les développeurs ne se marchent pas
   1.220 -mutuellement sur les pieds, comme c'était souvent le cas avec RCS et SCCS.
   1.221 -Chaque développeur disposait donc de sa copie de tous les fichiers du projet,
   1.222 -et ils pouvaient donc librement les modifier. Ils devaient néanmoins effectuer
   1.223 -la <quote>fusion</quote> (\textit{<quote>merge</quote>}) de leurs fichiers, avant d'effectuer le
   1.224 -<quote>commit</quote> de leur modifications sur le dépôt central.
   1.225 -</para>
   1.226 -
   1.227 -<para>Brian Berliner reprit les scripts de Grune's et les réécrit en C, qu'il publia
   1.228 -en 1989. Depuis, ce code a été modifié jusqu'à devenir la version moderne de
   1.229 -CVS. CVS a acquis ainsi la capacité de fonctionner en réseau, transformant son
   1.230 -architecture en client/serveur. L'architecture de CVS est centralisée, seul le
   1.231 -serveur a une copie de l'historique du projet. L'espace de travail client ne
   1.232 -contient qu'une copie de la dernière version du projet, et quelques métadonnées
   1.233 -pour indiquer où le serveur se trouve. CVS a été un grand succès, aujourd'hui
   1.234 -il est probablement l'outil de gestion de contrôle le plus utilisé au monde.
   1.235 -</para>
   1.236 -
   1.237 -<para>Au début des années 1990, Sun Microsystmes développa un premier outil de
   1.238 -gestion de source distribué, nommé TeamWare. Un espace de travail TeamWare
   1.239 -contient une copie complète de l'historique du projet. TeamWare n'a pas de
   1.240 -notion de dépôt central. (CVS utilisait RCS pour le stockage de l'historique,
   1.241 -TeamWare utilisait SCCS).
   1.242 -</para>
   1.243 -
   1.244 -<para>Alors que les années 1990 avançaient, les utilisateurs ont pris conscience d'un
   1.245 -certain nombre de problèmes avec CVS. Il enregistrait simultanément des
   1.246 -modifications sur différents fichiers individuellement, au lieu de les
   1.247 -regrouper dans une seule opération cohérente et atomique. Il ne gère pas bien
   1.248 -sa hiérarchie de fichier, il est donc assez aisé de créer le chaos en renommant
   1.249 -les fichiers et les répertoires. Pire encore, son code source est difficile à
   1.250 -lire et à maintenir, ce qui agrandit largement le <quote>niveau de souffrance</quote>
   1.251 -associé à la réparation de ces problèmes d'architecture de manière prohibitive.
   1.252 -</para>
   1.253 -
   1.254 -<para>En 2001, Jim Blandy et Karl Fogel, deux développeurs qui avaient travaillé sur
   1.255 -CVS, initièrent un projet pour le remplacer par un outil qui aurait une
   1.256 -meilleure architecture et un code plus propre. Le résultat, Subversion, ne
   1.257 -quitte pas le modèle centralisé et client/server de CVS, mais ajoute les
   1.258 -opérations de <quote>commit</quote> atomique sur de multiples fichiers, une meilleure
   1.259 -gestion des espaces de noms, et d'autres fonctionnalités qui en font un
   1.260 -meilleur outil que CVS. Depuis sa première publication, il est rapidement
   1.261 -devenu très populaire.
   1.262 -</para>
   1.263 -
   1.264 -<para>Plus ou moins simultanément, Graydon Hoare a commencé sur l'ambitieux
   1.265 -système de gestion distribué Monotone. Bien que Monotone corrige plusieurs
   1.266 -défauts de CVS's tout en offrant une architecture <quote>peer-to-peer</quote>, il va aussi
   1.267 -plus loin que la plupart des outils de révision de manière assez innovante. Il
   1.268 -utilise des <quote>hash</quote> cryptographiques comme identifiants, et il a une notion
   1.269 -complète de <quote>confiance</quote> du code issu des différentes sources.
   1.270 -</para>
   1.271 -
   1.272 -<para>Mercurial est né en 2005. Bien que très influencé par Monotone, Mercurial se
   1.273 -concentre sur la facilité d'utilisation, les performances et la capacité à
   1.274 -monter en charge pour de très gros projets.
   1.275 -</para>
   1.276 -
   1.277 -</sect1>
   1.278 -<sect1>
   1.279 -<title>Tendances de la gestion de source</title>
   1.280 -
   1.281 -<para>Il y a eu une tendance évidente dans le développement et l'utilisation d'outils
   1.282 +    </sect2>
   1.283 +  </sect1>
   1.284 +
   1.285 +  <sect1>
   1.286 +
   1.287 +<title>About the examples in this book</title>
   1.288 +
   1.289 +    <para id="x_84">This book takes an unusual approach to code samples.  Every
   1.290 +      example is <quote>live</quote>&emdash;each one is actually the result
   1.291 +      of a shell script that executes the Mercurial commands you see.
   1.292 +      Every time an image of the book is built from its sources, all
   1.293 +      the example scripts are automatically run, and their current
   1.294 +      results compared against their expected results.</para>
   1.295 +
   1.296 +    <para id="x_85">The advantage of this approach is that the examples are
   1.297 +      always accurate; they describe <emphasis>exactly</emphasis> the
   1.298 +      behavior of the version of Mercurial that's mentioned at the
   1.299 +      front of the book.  If I update the version of Mercurial that
   1.300 +      I'm documenting, and the output of some command changes, the
   1.301 +      build fails.</para>
   1.302 +
   1.303 +    <para id="x_86">There is a small disadvantage to this approach, which is
   1.304 +      that the dates and times you'll see in examples tend to be
   1.305 +      <quote>squashed</quote> together in a way that they wouldn't be
   1.306 +      if the same commands were being typed by a human.  Where a human
   1.307 +      can issue no more than one command every few seconds, with any
   1.308 +      resulting timestamps correspondingly spread out, my automated
   1.309 +      example scripts run many commands in one second.</para>
   1.310 +
   1.311 +    <para id="x_87">As an instance of this, several consecutive commits in an
   1.312 +      example can show up as having occurred during the same second.
   1.313 +      You can see this occur in the <literal
   1.314 +	role="hg-ext">bisect</literal> example in <xref
   1.315 +	linkend="sec:undo:bisect"/>, for instance.</para>
   1.316 +
   1.317 +    <para id="x_88">So when you're reading examples, don't place too much weight
   1.318 +      on the dates or times you see in the output of commands.  But
   1.319 +      <emphasis>do</emphasis> be confident that the behavior you're
   1.320 +      seeing is consistent and reproducible.</para>
   1.321 +
   1.322 +  </sect1>
   1.323 +
   1.324 +<!-- The next section has disapper from this part of the book. it may be splaced somewhere else... t-->
   1.325 +
   1.326 +  <sect1>
   1.327 +    <title>Tendances de la gestion de source</title>
   1.328 +
   1.329 +    <para id="x_89">Il y a eu une tendance évidente dans le développement et l'utilisation d'outils
   1.330  de gestion de source depuis les quatre dernières décades, au fur et à mesure
   1.331  que les utilisateurs se sont habitués à leur outils et se sont sentis contraints
   1.332  par leurs limitations.
   1.333  </para>
   1.334  
   1.335 -<para>La première génération commença simplement par gérer un fichier unique sur un
   1.336 +    <para id="x_8a">La première génération commença simplement par gérer un fichier unique sur un
   1.337  ordinateur individuel. Cependant, même si ces outils présentaient une grande
   1.338  avancée par rapport à la gestion manuelle des versions, leur modèle de
   1.339  verrouillage et leur utilisation limitée à un seul ordinateur rendaient leur
   1.340  utilisation possible uniquement dans une très petite équipe.
   1.341  </para>
   1.342  
   1.343 -<para>La seconde génération a assoupli ces contraintes en adoptant une architecture
   1.344 +    <para id="x_8b">La seconde génération a assoupli ces contraintes en adoptant une architecture
   1.345  réseau et centralisée, permettant de gérer plusieurs projets entiers en même
   1.346  temps. Alors que les projets grandirent en taille, ils rencontrèrent de nouveaux
   1.347  problèmes. Avec les clients discutant régulièrement avec le serveurs, la montée
   1.348  en charge devint un réel problème sur les gros projets. Une connexion réseau
   1.349  peu fiable pouvait complètement empêcher les utilisateurs distants de dialoguer
   1.350 -avec le serveur. Alors que les projets \textit{Open Source} commencèrent à
   1.351 +avec le serveur. Alors que les projets <emphasis remap="it">Open Source</emphasis> commencèrent à
   1.352  mettre en place des accès en lecture seule disponible anonymement, les
   1.353  utilisateurs sans les privilèges de <quote>commit</quote> réalisèrent qu'ils ne pouvaient
   1.354  pas utiliser les outils pour collaborer naturellement avec le projet, comme ils
   1.355  ne pouvaient pas non plus enregistrer leurs modifications.
   1.356  </para>
   1.357  
   1.358 -<para>La génération actuelle des outils de gestion de source est <quote>peer-to-peer</quote> par
   1.359 +    <para id="x_8c">La génération actuelle des outils de gestion de source est <quote>peer-to-peer</quote> par
   1.360  nature. Tout ces systèmes ont abandonné la dépendance à un serveur central, et
   1.361  ont permis à leur utilisateur de distribuer les données de leur gestion de
   1.362  source à qui en a besoin. La collaboration à travers Internet a transformé la
   1.363 @@ -257,18 +221,18 @@
   1.364  synchroniser les modifications avec les autres dépôts.
   1.365  </para>
   1.366  
   1.367 -</sect1>
   1.368 -<sect1>
   1.369 -<title>Quelques avantages des gestionnaires de source distribués</title>
   1.370 -
   1.371 -<para>Même si les gestionnaire de source distribués sont depuis plusieurs années
   1.372 +  </sect1>
   1.373 +  <sect1>
   1.374 +    <title>Quelques avantages des gestionnaires de source distribués</title>
   1.375 +
   1.376 +<para id="x_8d">Même si les gestionnaire de source distribués sont depuis plusieurs années
   1.377  assez robustes et aussi utilisables que leurs prédécesseurs, les utilisateurs
   1.378  d'autres outils n'y ont pas encore été sensibilisés. Les gestionnaires
   1.379  de source distribués se distinguent particulièrement de leurs équivalents
   1.380  centralisés de nombreuses manières.
   1.381  </para>
   1.382  
   1.383 -<para>Pour un développeur individuel, ils restent beaucoup plus rapides que les
   1.384 +    <para id="x_8e">Pour un développeur individuel, ils restent beaucoup plus rapides que les
   1.385  outils centralisés. Cela pour une raison simple : un outil centralisé doit
   1.386  toujours dialoguer à travers le réseau pour la plupart des opérations, car
   1.387  presque toutes les métadonnées sont stockées sur la seule copie du serveur
   1.388 @@ -278,7 +242,7 @@
   1.389  passer beaucoup de temps à interagir avec un logiciel de gestion de source.
   1.390  </para>
   1.391  
   1.392 -<para>Les outils distribués sont complètement indépendants des aléas de votre serveur,
   1.393 +    <para id="x_8f">Les outils distribués sont complètement indépendants des aléas de votre serveur,
   1.394  d'autant plus qu'ils répliquent les métadonnées à beaucoup d'endroits. Si
   1.395  votre serveur central prend feu, vous avez intérêt à ce que les médias de
   1.396  sauvegardes soient fiables, et que votre dernier <quote>backup</quote> soit récent et
   1.397 @@ -286,7 +250,7 @@
   1.398  <quote>backup</quote> que de contributeurs.
   1.399  </para>
   1.400  
   1.401 -<para>En outre, la fiabilité de votre réseau affectera beaucoup moins les
   1.402 +    <para id="x_90">En outre, la fiabilité de votre réseau affectera beaucoup moins les
   1.403  outils distribués. Vous ne pouvez même pas utiliser un outil centralisé
   1.404  sans connexion réseau, à l'exception de quelques commandes, très limitées.
   1.405  Avec un outil distribué, si votre connexion réseau tombe pendant que vous
   1.406 @@ -297,10 +261,11 @@
   1.407  être significatif.
   1.408  </para>
   1.409  
   1.410 -<sect2>
   1.411 -<title>Avantages pour les projets \textit{Open Source}</title>
   1.412 -
   1.413 -<para>Si vous prenez goût à un projet \textit{Open Source} et que vous
   1.414 +
   1.415 +    <sect2>
   1.416 +      <title>Avantages pour les projets Open Source</title>
   1.417 +
   1.418 +      <para id="x_91">Si vous prenez goût à un projet <emphasis remap="it">Open Source</emphasis> et que vous
   1.419  décidez de commencer à toucher à son code, et que le projet utilise
   1.420  un gestionnaire de source distribué, vous êtes immédiatement un "pair"
   1.421  avec les personnes formant le <quote>cœur</quote> du projet. Si ils publient
   1.422 @@ -315,21 +280,23 @@
   1.423  espace de travail avec le serveur central.
   1.424  </para>
   1.425  
   1.426 -<sect3>
   1.427 -<title>Le non-problème du \textit{fork}</title>
   1.428 -
   1.429 -<para>Il a été souvent suggéré que les gestionnaires de source distribués
   1.430 -posent un risque pour les projets \textit{Open Source} car ils
   1.431 -facilitent grandement la création de <quote>fork</quote>\footnote{NdT:Création
   1.432 +      <sect3>
   1.433 +	<title>Le non-problème du "fork"</title>
   1.434 +
   1.435 +	<para id="x_92">Il a été souvent suggéré que les gestionnaires de source distribués
   1.436 +posent un risque pour les projets <emphasis remap="it">Open Source</emphasis> car ils
   1.437 +facilitent grandement la création de <quote>fork</quote>.<!-- footnote{NdT:Création
   1.438  d'une
   1.439 -<ulink url="version alternative du logiciel">version alternative du logiciel</ulink>{http://fr.wikipedia.org/wiki/Fork#Embranchement_d.27un_projet_informatique}.}
   1.440 +<ulink url="version alternative du logiciel">version alternative du
   1.441 +logiciel</ulink>{http://fr.wikipedia.org/wiki/Fork#Embranchement_d.27un_projet_informatique}
   1.442 +-->
   1.443  Un <quote>fork</quote> apparait quand il y des divergences d'opinion ou d'attitude
   1.444  au sein d'un groupe de développeurs qui aboutissent à la décision de ne
   1.445  plus travailler ensemble. Chaque parti s'empare d'une copie plus ou moins
   1.446  complète du code source du projet et continue dans sa propre direction.
   1.447  </para>
   1.448  
   1.449 -<para>Parfois ces différents partis décident de se réconcilier. Avec un
   1.450 +	<para id="x_93">Parfois ces différents partis décident de se réconcilier. Avec un
   1.451  serveur central, l'aspect <emphasis>technique</emphasis> de cette réconciliation
   1.452  est un processus douloureux, et essentiellement manuel. Vous devez
   1.453  décider quelle modification est <quote>la gagnante</quote>, et replacer, par un
   1.454 @@ -338,32 +305,33 @@
   1.455  d'un des partis, ou même des deux.
   1.456  </para>
   1.457  
   1.458 -<para>Ce que les outils distribués permettent à ce sujet est probablement
   1.459 +	<para id="x_94">Ce que les outils distribués permettent à ce sujet est probablement
   1.460  la <emphasis>meilleure</emphasis> façon de développer un projet. Chaque modification
   1.461  que vous effectuez est potentiellement un <quote>fork</quote>. La grande force de
   1.462  cette approche est que les gestionnaires de source distribués doivent être
   1.463 -vraiment très efficaces pour <emphasis>fusionner</emphasis>\footnote{NdT:j'ai choisi de
   1.464 -traduire ici \textit{merging} par <quote>fusionner</quote> pour des raisons de clarté}
   1.465 -des <quote>forks</quote>, car les <quote>forks</quote>, dans ce contexte, arrivent tout le
   1.466 -temps.
   1.467 -</para>
   1.468 -
   1.469 -<para>Si chaque altération que n'importe qui effectue, à tout moment, est vue
   1.470 -comme un <quote>fork</quote> à fusionner, alors ce que le monde de l'\textit{Open
   1.471 +vraiment très efficaces pour <emphasis>fusionner</emphasis><!-- TODO footnote{NdT:j'ai choisi de
   1.472 +traduire ici <emphasis remap="it">merging</emphasis> par <quote>fusionner</quote> pour des raisons 
   1.473 +de clarté} --> des <quote>forks</quote>, car les <quote>forks</quote>, dans ce contexte, arrivent 
   1.474 +tout le temps.</para>
   1.475 +
   1.476 +	<para id="x_95">Si chaque altération que n'importe qui effectue, à tout moment, est vue
   1.477 +comme un <quote>fork</quote> à fusionner, alors ce que le monde de
   1.478 +l'<emphasis remap="it">Open Source</emphasis>
   1.479  Source} voit comme un <quote>fork</quote> devient <emphasis>uniquement</emphasis> une problématique
   1.480  sociale. En fait, les outils de gestions de source distribués <emphasis>réduisent</emphasis>
   1.481  les chances de <quote>fork</quote>:
   1.482  </para>
   1.483  <itemizedlist>
   1.484 -<listitem><para>Ils éliminent la distinction sociale qu'imposent les outils centralisés
   1.485 -    entre les membres du projets (ceux qui ont accès au <quote>commit</quote>) et ceux de
   1.486 -    l'extérieur (ce qui ne l'ont pas).  \item Ils rendent plus facile la
   1.487 -    réconciliation après un <quote>fork</quote> social, car
   1.488 -	tout ce qu'elle implique est une simple fusion.
   1.489 -</para>
   1.490 -</listitem></itemizedlist>
   1.491 -
   1.492 -<para>Certaines personnes font de la résistance envers les gestionnaires de source
   1.493 +    <listitem>
   1.494 +        <para>Ils éliminent la distinction sociale qu'imposent les outils centralisés
   1.495 +        entre les membres du projets (ceux qui ont accès au <quote>commit</quote>) et ceux de
   1.496 +        l'extérieur (ce qui ne l'ont pas).</para>
   1.497 +        <para>rendent plus facile la réconciliation après un <quote>fork</quote> social, car tout ce 
   1.498 +         qu'elle implique est une simple fusion.</para>
   1.499 +    </listitem>
   1.500 +</itemizedlist>
   1.501 +
   1.502 +	<para id="x_98">Certaines personnes font de la résistance envers les gestionnaires de source
   1.503  distribués parce qu'ils veulent garder un contrôle ferme sur leur projet, et
   1.504  ils pensent que les outils centralisés leur fournissent ce contrôle. Néanmoins,
   1.505  si c'est votre cas, sachez que si vous publiez votre dépôt CVS ou Subversion
   1.506 @@ -383,12 +351,12 @@
   1.507  %compelled to mirror and fork your history.
   1.508  </para>
   1.509  
   1.510 -</sect3>
   1.511 -</sect2>
   1.512 -<sect2>
   1.513 -<title>Avantages pour les projets commerciaux</title>
   1.514 -
   1.515 -<para>Beaucoup de projets commerciaux sont réalisés par des équipes éparpillées
   1.516 +      </sect3>
   1.517 +    </sect2>
   1.518 +    <sect2>
   1.519 +      <title>Avantages pour les projets commerciaux</title>
   1.520 +
   1.521 +      <para id="x_99">Beaucoup de projets commerciaux sont réalisés par des équipes éparpillées
   1.522  à travers le globe. Les contributeurs qui sont loin du serveur central
   1.523  devront subir des commandes lentes et même parfois peu fiables. Les
   1.524  solutions propriétaires de gestion de source tentent de palier ce problème
   1.525 @@ -400,7 +368,7 @@
   1.526  longue distance souvent onéreuse.
   1.527  </para>
   1.528  
   1.529 -<para>Les systèmes de gestion de source supportent généralement assez mal la
   1.530 +      <para id="x_9a">Les systèmes de gestion de source supportent généralement assez mal la
   1.531  montée en charge. Ce n'est pas rare pour un gestionnaire de source centralisé
   1.532  pourtant onéreux de s'effondrer sous la charge combinée d'une douzaine
   1.533  d'utilisateurs concurrents seulement. Une fois encore, la réponse à cette problématique
   1.534 @@ -413,7 +381,7 @@
   1.535  travail d'un simple script.
   1.536  </para>
   1.537  
   1.538 -<para>Si vous avez des employés sur le terrain, en train de chercher à résoudre un souci sur
   1.539 +      <para id="x_9b">Si vous avez des employés sur le terrain, en train de chercher à résoudre un souci sur
   1.540  le site d'un client, ils bénéficieront aussi d'un gestionnaire de source
   1.541  distribué. Cet outil leur permettra de générer des versions personnalisées,
   1.542  d'essayer différentes solutions, en les isolant aisément les unes des autres,
   1.543 @@ -422,60 +390,43 @@
   1.544  connexion au réseau de votre compagnie.
   1.545  </para>
   1.546  
   1.547 -</sect2>
   1.548 -</sect1>
   1.549 -<sect1>
   1.550 -<title>Pourquoi choisir Mercurial?</title>
   1.551 -
   1.552 -<para>Mercurial a plusieurs caractéristiques qui en font un choix particulièrement
   1.553 +    </sect2>
   1.554 +  </sect1>
   1.555 +  <sect1>
   1.556 +    <title>Pourquoi choisir Mercurial?</title>
   1.557 +
   1.558 +    <para id="x_9c">Mercurial a plusieurs caractéristiques qui en font un choix particulièrement
   1.559  pertinent pour la gestion de source:
   1.560  </para>
   1.561 -<itemizedlist>
   1.562 -<listitem><para>	\item Il est facile à apprendre et à utiliser ;
   1.563 -	\item Il est léger et performant ;
   1.564 -	\item Il monte facilement en charge ;
   1.565 -	\item Il est facile à personnaliser ;
   1.566 -</para>
   1.567 -</listitem></itemizedlist>
   1.568 -
   1.569 -<para>Si vous êtes déjà familier d'un outil de gestion de source, vous serez
   1.570 +    <itemizedlist>
   1.571 +      <listitem><para id="x_9d">It is easy to learn and use.</para></listitem>
   1.572 +      <listitem><para id="x_9e">It is lightweight.</para></listitem>
   1.573 +      <listitem><para id="x_9f">It scales excellently.</para></listitem>
   1.574 +      <listitem><para id="x_a0">It is easy to
   1.575 +	  customise.</para></listitem></itemizedlist>
   1.576 +
   1.577 +    <para id="x_a1">Si vous êtes déjà familier d'un outil de gestion de source, vous serez
   1.578  capable de l'utiliser en moins de 5 minutes. Sinon, ça ne sera pas beaucoup
   1.579 -plus long\footnote{NdT: Pour appuyer le propos de l'auteur, je signale que
   1.580 -j'utilise Mercurial comme outil d'initiation à la gestion de contrôle dans
   1.581 -des travaux pratiques à l'ESME Sudria (<ulink url="http://www.esme.fr">http://www.esme.fr</ulink>) et que les
   1.582 -élèves le prennent en main sans difficulté majeure malgré l'approche distribuée.}.
   1.583 +plus long.
   1.584  Les commandes utilisées par Mercurial, comme ses fonctionnalités, sont
   1.585  généralement uniformes et cohérentes, et vous pouvez donc ainsi garder en tête
   1.586  simplement quelques règles générales, plutôt qu'un lot complexe d'exceptions.
   1.587  </para>
   1.588  
   1.589 -<para>Sur un petit projet, vous pouvez commencer à travailler avec Mercurial en
   1.590 +    <para id="x_a2">Sur un petit projet, vous pouvez commencer à travailler avec Mercurial en
   1.591  quelques instants. Ajouter des modifications ou des branches, transférer
   1.592  ces modifications (localement ou via le réseau), et les opérations
   1.593  d'historique ou de statut sont aussi très rapides. Mercurial reste hors de
   1.594  votre chemin grâce à sa simplicité d'utilisation et sa rapidité d'exécution.
   1.595  </para>
   1.596  
   1.597 -<para>L'utilité de Mercurial ne se limite pas à de petits projets: il est
   1.598 +    <para id="x_a3">L'utilité de Mercurial ne se limite pas à de petits projets: il est
   1.599  aussi utilisé par des projets ayant des centaines ou même des milliers
   1.600  de contributeurs, avec plusieurs dizaines de milliers de fichiers, et des
   1.601  centaines de méga de code source.
   1.602  </para>
   1.603  
   1.604 -<para>Voici une liste non exhaustive des projets complexes ou critiques utilisant
   1.605 -Mercurial :
   1.606 -%TODO
   1.607 -% For both spanish and english version, add the following examples:
   1.608 -</para>
   1.609 -<itemizedlist>
   1.610 -<listitem><para>	\item <ulink url="Firefox">Firefox</ulink>{https://developer.mozilla.org/en/Mozilla_Source_Code_(Mercurial)} ;
   1.611 -	\item <ulink url="OpenSolaris">OpenSolaris</ulink>{http://opensolaris.org/os/community/tools/scm/hg_help/} ;
   1.612 -	\item <ulink url="OpenJDK">OpenJDK</ulink>{http://hg.openjdk.java.net/} (utilisant en outre l'extension
   1.613 -	<quote>forest</quote> pour gérer ses sous modules);
   1.614 -</para>
   1.615 -</listitem></itemizedlist>
   1.616 -
   1.617 -<para>Si les fonctionnalités cœur de Mercurial ne sont pas suffisantes pour vous,
   1.618 +    <para id="x_a4">Si les fonctionnalités cœur de Mercurial ne sont pas suffisantes pour vous,
   1.619  il est très aisé d'en construire d'autres. Mercurial est adapté à l'utilisation
   1.620  de scripts, et son implémentation interne en Python, propre et claire,
   1.621  rend encore plus facile l'ajout de fonctionnalités sous forme d'extensions. Il
   1.622 @@ -483,40 +434,38 @@
   1.623  dont le périmètre va de la recherche de bugs à l'amélioration des performances.
   1.624  </para>
   1.625  
   1.626 -</sect1>
   1.627 -<sect1>
   1.628 -<title>Mercurial comparé aux autres outils</title>
   1.629 -
   1.630 -<para>Avant que vous n'alliez plus loin, comprenez bien que cette section
   1.631 +  </sect1>
   1.632 +  <sect1>
   1.633 +    <title>Mercurial comparé aux autres outils</title>
   1.634 +
   1.635 +    <para id="x_a5">Avant que vous n'alliez plus loin, comprenez bien que cette section
   1.636  reflète mes propres expériences, et elle est donc (j'ose le dire)
   1.637  peu objective. Néanmoins, j'ai utilisé les outils de gestion de source
   1.638  listés ci dessous, dans la plupart des cas, pendant plusieurs années.
   1.639  %% TODO: Fussy translation.
   1.640  </para>
   1.641  
   1.642 -<sect2>
   1.643 -<title>Subversion</title>
   1.644 -
   1.645 -<para>Subversion est un des outils de gestion de source les plus populaire, il fût
   1.646 +
   1.647 +    <sect2>
   1.648 +      <title>Subversion</title>
   1.649 +
   1.650 +      <para id="x_a6">Subversion est un des outils de gestion de source les plus populaire, il fût
   1.651  développé pour remplacer CVS. Il a une architecture client/server centralisée.
   1.652  </para>
   1.653  
   1.654 -<para>Subversion et Mercurial ont des noms de commandes très similaires pour
   1.655 +    <para id="x_a7">Subversion et Mercurial ont des noms de commandes très similaires pour
   1.656  les mêmes opérations, ainsi si vous êtes familier avec l'un, c'est facile
   1.657  d'apprendre l'autre. Ces deux outils sont portables sur les systèmes
   1.658 -d'exploitation les plus populaires\footnote{NdT:Mercurial fonctionne sans problème
   1.659 -sur OpenVMS à l'ESME Sudria <ulink url="http://www.esme.fr">http://www.esme.fr</ulink>, compte tenu que Subversion a été
   1.660 -développé en C, je ne suis pas sûr que son portage aurait été aussi aisé.}.
   1.661 -%TODO: Backport this statement in english and spanish
   1.662 -</para>
   1.663 -
   1.664 -<para>Avant la version 1.5, Subversion n'offrait aucune forme de support pour les fusions. Lors
   1.665 +d'exploitation les plus populaires
   1.666 +</para>
   1.667 +
   1.668 +      <para id="x_a8">Avant la version 1.5, Subversion n'offrait aucune forme de support pour les fusions. Lors
   1.669  de l'écriture de ce livre, ses capacités de fusion étaient nouvelles, et réputées pour être
   1.670 -\href{http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword}{complexes
   1.671 -et bugguées}.
   1.672 -</para>
   1.673 -
   1.674 -<para>Mercurial dispose d'un avantage substantiel en terme de performance par rapport à
   1.675 +<ulink url="http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword">
   1.676 +complexes et boguées</ulink>.
   1.677 +</para>
   1.678 +
   1.679 +      <para id="x_a9">Mercurial dispose d'un avantage substantiel en terme de performance par rapport à
   1.680  Subversion sur la plupart des opérations que j'ai pu tester. J'ai mesuré
   1.681  une différence de performance allant de deux à six fois plus rapide avec
   1.682  le système de stockage de fichier local de Subversion 1.4.3
   1.683 @@ -528,7 +477,7 @@
   1.684  goulots d'étranglement pour les projets de taille moyenne ou grande.
   1.685  </para>
   1.686  
   1.687 -<para>En outre, Subversion implique une surcharge substantielle dans le stockage local
   1.688 +      <para id="x_aa">En outre, Subversion implique une surcharge substantielle dans le stockage local
   1.689  de certaines données, pour éviter des transactions avec le serveur, pour
   1.690  certaines opérations communes, telles que la recherche des fichiers modifiés
   1.691  (<literal>status</literal>) et l'affichage des modifications par rapport à la révision
   1.692 @@ -538,14 +487,14 @@
   1.693  de l'historique.
   1.694  </para>
   1.695  
   1.696 -<para>Subversion est largement supporté par les outils tierces. Mercurial est
   1.697 +      <para id="x_ab">Subversion est largement supporté par les outils tierces. Mercurial est
   1.698  actuellement encore en retrait de ce point de vue. L'écart se réduit, néanmoins,
   1.699  et en effet certains des outils graphiques sont maintenant supérieurs à leurs
   1.700  équivalents Subversion. Comme Mercurial, Subversion dispose d'un excellent
   1.701  manuel utilisateur.
   1.702  </para>
   1.703  
   1.704 -<para>Parce que Subversion ne stocke pas l'historique chez ses clients, il est
   1.705 +      <para id="x_ac">Parce que Subversion ne stocke pas l'historique chez ses clients, il est
   1.706  parfaitement adapté à la gestion de projets qui doivent suivre un ensemble
   1.707  de larges fichiers binaires et opaques. Si vous suivez une cinquantaine de
   1.708  versions d'un fichier incompressible de 10MB, l'occupation disque coté client
   1.709 @@ -555,14 +504,14 @@
   1.710  de versions, car les différences entre chaque révisions seront très grandes.
   1.711  </para>
   1.712  
   1.713 -<para>En outre, c'est souvent difficile ou, généralement, impossible de fusionner
   1.714 +      <para id="x_ad">En outre, c'est souvent difficile ou, généralement, impossible de fusionner
   1.715  des différences dans un fichier binaire. La capacité de Subversion de
   1.716  verrouiller des fichiers, pour permettre à l'utilisateur d'être le seul
   1.717  à le mettre à jour (<quote>commit</quote>) temporairement, est un avantage significatif
   1.718  dans un projet doté de beaucoup de fichiers binaires.
   1.719  </para>
   1.720  
   1.721 -<para>Mercurial peut importer l'historique depuis un dépôt Subversion. Il peut
   1.722 +      <para id="x_ae">Mercurial peut importer l'historique depuis un dépôt Subversion. Il peut
   1.723  aussi exporter l'ensemble des révisions d'un projet vers un dépôt Subversion.
   1.724  Ceci rend très facile de <quote>prendre la température</quote> et d'utiliser Mercurial et Subversion
   1.725  en parallèle, avant de décider de migrer vers Mercurial. La conversion de
   1.726 @@ -571,29 +520,30 @@
   1.727  modifications.
   1.728  </para>
   1.729  
   1.730 -</sect2>
   1.731 -<sect2>
   1.732 -<title>Git</title>
   1.733 -
   1.734 -<para>Git est un outil de gestion de source distribué qui fût développé pour gérer
   1.735 +
   1.736 +    </sect2>
   1.737 +    <sect2>
   1.738 +      <title>Git</title>
   1.739 +
   1.740 +      <para id="x_af">Git est un outil de gestion de source distribué qui fût développé pour gérer
   1.741  le code source de noyau de Linux. Comme Mercurial, sa conception initiale a
   1.742  été inspirée par Monotone.
   1.743  </para>
   1.744  
   1.745 -<para>Git dispose d'un ensemble conséquent de commandes, avec plus de 139 commandes
   1.746 +      <para id="x_b0">Git dispose d'un ensemble conséquent de commandes, avec plus de 139 commandes
   1.747  individuelles pour la version 1.5.0. Il a aussi la réputation d'être difficile
   1.748  à apprendre. Comparé à Git, le point fort de Mercurial est clairement sa
   1.749  simplicité.
   1.750  </para>
   1.751  
   1.752 -<para>En terme de performance, Git est extrêmement rapide. Dans la plupart des
   1.753 +      <para id="x_b1">En terme de performance, Git est extrêmement rapide. Dans la plupart des
   1.754  cas, il est plus rapide que Mercurial, tout du moins sur Linux, alors que
   1.755  Mercurial peut être plus performant sur d'autres opérations. Néanmoins, sur
   1.756  Windows, les performances et le niveau de support général fourni par Git,
   1.757  au moment de l'écriture de cet ouvrage, est bien derrière celui de Mercurial.
   1.758  </para>
   1.759  
   1.760 -<para>Alors que le dépôt Mercurial ne demande aucune maintenance, un dépôt Git
   1.761 +      <para id="x_b2">Alors que le dépôt Mercurial ne demande aucune maintenance, un dépôt Git
   1.762  exige d'exécuter manuellement et régulièrement la commande <quote>repacks</quote> sur
   1.763  ces métadonnées. Sans ceci, les performances de git se dégradent et la
   1.764  consommation de l'espace disque augmente rapidement. Un serveur qui contient
   1.765 @@ -604,39 +554,42 @@
   1.766  mais un dépôt non <quote>repacked</quote> est beaucoup plus grand.
   1.767  </para>
   1.768  
   1.769 -<para>Le cœur de Git est écrit en C. La plupart des commandes Git sont implémentées
   1.770 +      <para id="x_b3">Le cœur de Git est écrit en C. La plupart des commandes Git sont implémentées
   1.771  sous forme de scripts Shell ou Perl, et la qualité de ces scripts varie
   1.772  grandement. J'ai plusieurs fois constaté que certains de ces scripts étaient
   1.773  chargés en mémoire aveuglément et que la présence d'erreurs pouvait s'avérer
   1.774  fatal.
   1.775  </para>
   1.776  
   1.777 -<para>Mercurial peut importer l'historique d'un dépôt Git.
   1.778 -</para>
   1.779 -
   1.780 -</sect2>
   1.781 -<sect2>
   1.782 -<title>CVS</title>
   1.783 -
   1.784 -<para>CVS est probablement l'outil de gestion de source le plus utilisé aujourd'hui
   1.785 +      <para id="x_b4">Mercurial peut importer l'historique d'un dépôt Git.
   1.786 +</para>
   1.787 +
   1.788 +
   1.789 +
   1.790 +    </sect2>
   1.791 +    <sect2>
   1.792 +      <title>CVS</title>
   1.793 +
   1.794 +      <para id="x_b5">CVS est probablement l'outil de gestion de source le plus utilisé aujourd'hui
   1.795  dans le monde. À cause de son manque de clarté interne, il n'est plus
   1.796  maintenu depuis plusieurs années.
   1.797  </para>
   1.798  
   1.799 -<para>Il a une architecture client/serveur centralisée. Il ne regroupe pas les
   1.800 +      <para id="x_b6">Il a une architecture client/serveur centralisée. Il ne regroupe pas les
   1.801  modifications de fichiers dans une opération de <quote>commit</quote> atomique, ce
   1.802 -qui permet à ses utilisateurs de <quote>casser le \textit{build}</quote> assez
   1.803 +qui permet à ses utilisateurs de <quote>casser le <emphasis>build</emphasis></quote> assez
   1.804  facilement : une personne peut effectuer une opération de <quote>commit</quote>
   1.805  sans problème puis être bloquée par besoin de fusion, avec comme conséquence
   1.806  néfaste, que les autres utilisateurs ne récupèreront qu'une partie de ses
   1.807  modifications. Ce problème affecte aussi la manière de travailler avec
   1.808  l'historique du projet. Si vous voulez voir toutes les modifications d'une
   1.809  personne du projet, vous devrez injecter manuellement les descriptions et les
   1.810 -\textit{timestamps} des modifications de chacun des fichiers impliqués (si
   1.811 +<emphasis remap="it">timestamps</emphasis> des modifications de chacun des fichiers impliqués (si
   1.812  vous savez au moins quels sont ces fichiers).
   1.813  </para>
   1.814  
   1.815 -<para>CVS a une notion étrange des \textit{tags} et des branches que je n'essayerai
   1.816 +      <para id="x_b7">CVS a une notion étrange des <emphasis
   1.817 +      remap="it">tags</emphasis> et des branches que je n'essayerai
   1.818  même pas de décrire ici. Il ne supporte pas bien les opérations de renommage d'un
   1.819  fichier ou d'un répertoire, ce qui facilite la corruption de son dépôt. Il n'a
   1.820  presque pas pour ainsi dire de contrôle de cohérence interne, il est donc
   1.821 @@ -644,7 +597,7 @@
   1.822  ne recommanderai pas CVS pour un projet existant ou nouveau.
   1.823  </para>
   1.824  
   1.825 -<para>Mercurial peut importer l'historique d'un projet CVS. Néanmoins, il y a
   1.826 +      <para id="x_b8">Mercurial peut importer l'historique d'un projet CVS. Néanmoins, il y a
   1.827  quelques principes à respecter; ce qui est vrai aussi pour les autres
   1.828  outils d'import de projet CVS. À cause de l'absence de <quote>commit</quote> atomique
   1.829  et gestion de version de l'arborescence, il n'est pas possible de reconstruire
   1.830 @@ -652,58 +605,62 @@
   1.831  est donc nécessaire, et les fichiers renommés ne sont pas détectés. Parce
   1.832  qu'une bonne part de l'administration d'un dépôt CVS est effectuée manuellement,
   1.833  et est donc, sujette à erreur, il est courant que les imports CVS rencontrent
   1.834 -de nombreux problèmes avec les dépôt corrompus (des \textit{timestamps}
   1.835 -de révision complètement buggés et des fichiers verrouillés depuis des années
   1.836 -sont deux des problèmes les moins intéressants dont je me souvienne).
   1.837 -</para>
   1.838 -
   1.839 -<para>Mercurial peut importer l'historique depuis un dépôt CVS.
   1.840 -</para>
   1.841 -
   1.842 -</sect2>
   1.843 -<sect2>
   1.844 -<title>Outils propriétaires</title>
   1.845 -
   1.846 -<para>Perforce a une architecture client/serveur centralisée, sans aucun
   1.847 +de nombreux problèmes avec les dépôt corrompus (des <emphasis
   1.848 +remap="it">timestamps</emphasis> de révision complètement buggés et des fichiers 
   1.849 +verrouillés depuis des années sont deux des problèmes les moins intéressants dont 
   1.850 +je me souvienne).
   1.851 +</para>
   1.852 +
   1.853 +      <para id="x_b9">Mercurial peut importer l'historique depuis un dépôt CVS.
   1.854 +</para>
   1.855 +
   1.856 +
   1.857 +    </sect2>
   1.858 +    <sect2>
   1.859 +      <title>Outils propriétaires</title>
   1.860 +
   1.861 +      <para id="x_ba">Perforce a une architecture client/serveur centralisée, sans aucun
   1.862  mécanisme de mise en cache de données coté client. Contrairement à la plupart
   1.863  des outils modernes de gestion de source, Perforce exige de ses
   1.864  utilisateurs d'exécuter une commande pour informer le serveur
   1.865  central de tout fichier qu'ils souhaitent modifier.
   1.866  </para>
   1.867  
   1.868 -<para>Les performances de Perforce sont plutôt bonnes pour des petites
   1.869 +      <para id="x_bb">Les performances de Perforce sont plutôt bonnes pour des petites
   1.870  équipes, mais elles s'effondrent rapidement lorsque le nombre
   1.871  d'utilisateurs augmente au delà de la douzaine. Des installations
   1.872  de Perforce assez larges nécessitent le déploiement de proxies pour
   1.873  supporter la montée en charge associée.
   1.874  </para>
   1.875  
   1.876 -</sect2>
   1.877 -<sect2>
   1.878 -<title>Choisir un outil de gestion de source</title>
   1.879 -
   1.880 -<para>A l'exception de CVS, tous les outils listés ci-dessus ont des
   1.881 +
   1.882 +    </sect2>
   1.883 +    <sect2>
   1.884 +      <title>Choisir un outil de gestion de source</title>
   1.885 +
   1.886 +      <para id="x_bc">A l'exception de CVS, tous les outils listés ci-dessus ont des
   1.887  forces qui leur sont propres et qui correspondent à certaines
   1.888  formes de projet. Il n'y a pas un seul meilleur outil de gestion
   1.889  de source qui correspondrait le mieux à toutes les situations.
   1.890  </para>
   1.891  
   1.892 -<para>Par exemple, Subversion est un très bon choix lorsqu'on travaille
   1.893 +      <para id="x_bd">En guise exemple, Subversion est un très bon choix lorsqu'on travaille
   1.894  avec beaucoup de fichiers binaires, qui évoluent régulièrement, grâce
   1.895  à sa nature centralisée et sa capacité à verrouiller des fichiers.
   1.896  </para>
   1.897  
   1.898 -<para>Personnellement, je préfère Mercurial pour sa simplicité, ses
   1.899 +      <para id="x_be">Personnellement, je préfère Mercurial pour sa simplicité, ses
   1.900  performances et sa bonne capacité de fusion, et il m'a très bien rendu service
   1.901  de plusieurs années maintenant.
   1.902  </para>
   1.903  
   1.904 -</sect2>
   1.905 -</sect1>
   1.906 -<sect1>
   1.907 -<title>Migrer depuis un outil à Mercurial</title>
   1.908 -
   1.909 -<para>Mercurial est livré avec une extension nommée <literal role="hg-ext">convert</literal>, qui
   1.910 +
   1.911 +    </sect2>
   1.912 +  </sect1>
   1.913 +  <sect1>
   1.914 +    <title>Migrer depuis un outil à Mercurial</title>
   1.915 +
   1.916 +    <para id="x_bf">Mercurial est livré avec une extension nommée <literal role="hg-ext">convert</literal>, qui
   1.917  peut de manière incrémentale importer des révisions depuis différents
   1.918  autres outils de gestion de source. Par <quote>incrémental</quote>, j'entends que
   1.919  vous pouvez convertir l'historique entier du projet en une seule fois,
   1.920 @@ -711,34 +668,126 @@
   1.921  effectuées depuis votre import initial.
   1.922  </para>
   1.923  
   1.924 -<para>Les outils de gestion de source supportés par <literal role="hg-ext">convert</literal> sont :
   1.925 -</para>
   1.926 -<itemizedlist>
   1.927 -<listitem><para>	\item Subversion
   1.928 -	\item CVS
   1.929 -	\item Git
   1.930 -	\item Darcs
   1.931 -</para>
   1.932 -</listitem></itemizedlist>
   1.933 -
   1.934 -<para>En outre, <literal role="hg-ext">convert</literal> peut exporter les modifications depuis Mercurial
   1.935 +    <para id="x_c0">Les outils de gestion de source supportés par <literal role="hg-ext">convert</literal> sont :
   1.936 +</para>
   1.937 +    <itemizedlist>
   1.938 +      <listitem><para id="x_c1">Subversion</para></listitem>
   1.939 +      <listitem><para id="x_c2">CVS</para></listitem>
   1.940 +      <listitem><para id="x_c3">Git</para></listitem>
   1.941 +      <listitem><para id="x_c4">Darcs</para></listitem></itemizedlist>
   1.942 +
   1.943 +    <para id="x_c5">En outre, <literal role="hg-ext">convert</literal> peut exporter les modifications depuis Mercurial
   1.944  vers Subversion. Ceci rend possible d'essayer Subversion en parallèle
   1.945  avant de choisir une solution définitive, sans aucun risque de perte de
   1.946  données.
   1.947  </para>
   1.948  
   1.949 -<para>La commande <command role="hg-ext-conver">convert</command> est très simple à utiliser. Simplement,
   1.950 +    <para id="x_c6">La commande <command role="hg-ext-conver">convert</command> est très simple à utiliser. Simplement,
   1.951  indiquez le chemin ou l'URL du dépôt de source, en lui indiquant éventuellement
   1.952  le nom du chemin de destination, et la conversion se met en route. Après cet
   1.953  import initial, il suffit de relancer la commande encore une fois pour
   1.954  importer les modifications effectuées depuis.
   1.955  </para>
   1.956 +  </sect1>
   1.957 +
   1.958 +  <sect1>
   1.959 +    <title>Une courte histoire de la gestion de source</title>
   1.960 +
   1.961 +    <para id="x_c7">Le plus célèbre des anciens outils de gestion de source
   1.962 +    est <emphasis remap="it">SCCS</emphasis>
   1.963 +(Source Code Control System)}, que Marc Rochkind conçu dans les laboratoires de
   1.964 +recherche de Bell (<emphasis remap="it">Bell Labs</emphasis>), dans le début des années 70.
   1.965 +<emphasis remap="it">SCCS</emphasis> ne fonctionnait que sur des fichiers individuels, et obligeait chaque
   1.966 +personne travaillant sur le projet d'avoir un accès à un répertoire de
   1.967 +travail commun, sur le même système. Seulement une seule personne pouvait
   1.968 +modifier un fichier au même moment, ce fonctionnement était assuré par
   1.969 +l'utilisation de verrou (<quote>lock</quote>). Il était courant que des personnes
   1.970 +verrouillent des fichiers, et plus tard, oublient de le déverrouiller;
   1.971 +empêchant n'importe qui d'autre de travailler sur ces fichiers sans l'aide de
   1.972 +l'administrateur...
   1.973 +</para>
   1.974 +
   1.975 +    <para id="x_c8">Walter Tichy a développé une alternative libre à
   1.976 +    <emphasis remap="it">SCCS</emphasis> au début des
   1.977 +années 80, qu'il nomma <emphasis remap="it">RCS (Revision Control System)</emphasis>.  Comme
   1.978 +<emphasis remap="it">SCCS</emphasis>, <emphasis remap="it">RCS</emphasis> demandait aux développeurs de travailler sur le même
   1.979 +répertoire partagé, et de verrouiller les
   1.980 +fichiers pour se prémunir de tout conflit issu de modifications concurrentes.
   1.981 +</para>
   1.982 +
   1.983 +    <para id="x_c9">Un peu plus tard dans les années 1980, Dick Grune utilisa <emphasis remap="it">RCS</emphasis> comme
   1.984 +une brique de base pour un ensemble de scripts <emphasis
   1.985 +remap="it">shell</emphasis> qu'il intitula
   1.986 +cmt, avant de la renommer en <emphasis remap="it">CVS (Concurrent Versions System)</emphasis>.  La
   1.987 +grande innovation de CVS était que les développeurs pouvaient travailler
   1.988 +simultanément et indépendamment dans leur propre espace de travail. Ces espaces
   1.989 +de travail privés assuraient que les développeurs ne se marchent pas
   1.990 +mutuellement sur les pieds, comme c'était souvent le cas avec RCS et SCCS.
   1.991 +Chaque développeur disposait donc de sa copie de tous les fichiers du projet,
   1.992 +et ils pouvaient donc librement les modifier. Ils devaient néanmoins effectuer
   1.993 +la <quote>fusion</quote> (<emphasis
   1.994 +remap="it"><quote>merge</quote></emphasis>) de leurs fichiers, avant d'effectuer le
   1.995 +<quote>commit</quote> de leur modifications sur le dépôt central.
   1.996 +</para>
   1.997 +
   1.998 +<para>Brian Berliner reprit les scripts de Grune's et les réécrit en C, qu'il publia
   1.999 +en 1989. Depuis, ce code a été modifié jusqu'à devenir la version moderne de
  1.1000 +CVS. CVS a acquis ainsi la capacité de fonctionner en réseau, transformant son
  1.1001 +architecture en client/serveur. L'architecture de CVS est centralisée, seul le
  1.1002 +serveur a une copie de l'historique du projet. L'espace de travail client ne
  1.1003 +contient qu'une copie de la dernière version du projet, et quelques métadonnées
  1.1004 +pour indiquer où le serveur se trouve. CVS a été un grand succès, aujourd'hui
  1.1005 +il est probablement l'outil de gestion de contrôle le plus utilisé au monde.
  1.1006 +</para>
  1.1007 +
  1.1008 +<para>Au début des années 1990, Sun Microsystmes développa un premier outil de
  1.1009 +gestion de source distribué, nommé TeamWare. Un espace de travail TeamWare
  1.1010 +contient une copie complète de l'historique du projet. TeamWare n'a pas de
  1.1011 +notion de dépôt central. (CVS utilisait RCS pour le stockage de l'historique,
  1.1012 +TeamWare utilisait SCCS).
  1.1013 +</para>
  1.1014 +
  1.1015 +<para>Alors que les années 1990 avançaient, les utilisateurs ont pris conscience d'un
  1.1016 +certain nombre de problèmes avec CVS. Il enregistrait simultanément des
  1.1017 +modifications sur différents fichiers individuellement, au lieu de les
  1.1018 +regrouper dans une seule opération cohérente et atomique. Il ne gère pas bien
  1.1019 +sa hiérarchie de fichier, il est donc assez aisé de créer le chaos en renommant
  1.1020 +les fichiers et les répertoires. Pire encore, son code source est difficile à
  1.1021 +lire et à maintenir, ce qui agrandit largement le <quote>niveau de souffrance</quote>
  1.1022 +associé à la réparation de ces problèmes d'architecture de manière prohibitive.
  1.1023 +</para>
  1.1024 +
  1.1025 +<para>En 2001, Jim Blandy et Karl Fogel, deux développeurs qui avaient travaillé sur
  1.1026 +CVS, initièrent un projet pour le remplacer par un outil qui aurait une
  1.1027 +meilleure architecture et un code plus propre. Le résultat, Subversion, ne
  1.1028 +quitte pas le modèle centralisé et client/server de CVS, mais ajoute les
  1.1029 +opérations de <quote>commit</quote> atomique sur de multiples fichiers, une meilleure
  1.1030 +gestion des espaces de noms, et d'autres fonctionnalités qui en font un
  1.1031 +meilleur outil que CVS. Depuis sa première publication, il est rapidement
  1.1032 +devenu très populaire.
  1.1033 +</para>
  1.1034 +
  1.1035 +<para>Plus ou moins simultanément, Graydon Hoare a commencé sur l'ambitieux
  1.1036 +système de gestion distribué Monotone. Bien que Monotone corrige plusieurs
  1.1037 +défauts de CVS's tout en offrant une architecture <quote>peer-to-peer</quote>, il va aussi
  1.1038 +plus loin que la plupart des outils de révision de manière assez innovante. Il
  1.1039 +utilise des <quote>hash</quote> cryptographiques comme identifiants, et il a une notion
  1.1040 +complète de <quote>confiance</quote> du code issu des différentes sources.
  1.1041 +</para>
  1.1042 +
  1.1043 +<para>Mercurial est né en 2005. Bien que très influencé par Monotone, Mercurial se
  1.1044 +concentre sur la facilité d'utilisation, les performances et la capacité à
  1.1045 +monter en charge pour de très gros projets.
  1.1046 +</para>
  1.1047  
  1.1048  </sect1>
  1.1049 +
  1.1050 +
  1.1051 +
  1.1052  </chapter>
  1.1053  
  1.1054  <!--
  1.1055  local variables: 
  1.1056  sgml-parent-document: ("00book.xml" "book" "chapter")
  1.1057  end:
  1.1058 --->
  1.1059 \ No newline at end of file
  1.1060 +-->