1.1 --- /dev/null	Thu Jan 01 00:00:00 1970 +0000
     1.2 +++ b/fr/ch01-intro.xml	Sun Aug 16 04:58:01 2009 +0200
     1.3 @@ -0,0 +1,744 @@
     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 +
    1.10 +<sect1>
    1.11 +<title>À propos de la gestion source</title>
    1.12 +
    1.13 +<para>La gestion de sources est un processus permettant de gérer différentes
    1.14 +versions de la même information. Dans sa forme la plus simple, c'est
    1.15 +ce que tout le monde fait manuellement : quand vous modifiez
    1.16 +un fichier, vous le sauvegardez sous un nouveau nom contenant un numéro,
    1.17 +à chaque fois plus grand que celui de la version précédente.</para>
    1.18 +
    1.19 +<para>Ce genre de gestion de version manuelle est cependant facilement sujette
    1.20 +à des erreurs, ainsi, depuis longtemps, des logiciels existent pour
    1.21 +résoudre cette problématique. Les premiers outils de gestion de sources
    1.22 +étaient destinés à aider un seul utilisateur, à automatiser la gestion
    1.23 +des versions d'un seul fichier. Dans les dernières décades, cette cible
    1.24 +s'est largement agrandie, ils gèrent désormais de multiples fichiers, et
    1.25 +aident un grand nombre de personnes à travailler ensemble. Les outils les
    1.26 +plus modernes n'ont aucune difficulté à gérer plusieurs milliers de
    1.27 +personnes travaillant ensemble sur des projets regroupant plusieurs
    1.28 +centaines de milliers de fichiers.</para>
    1.29 +
    1.30 +<sect2>
    1.31 +<title>Pourquoi utiliser un gestionnaire de source ?</title>
    1.32 +
    1.33 +<para>Il y a de nombreuses raisons pour que vous ou votre équipe souhaitiez
    1.34 +utiliser un outil automatisant la gestion de version pour votre projet.</para>
    1.35 +<itemizedlist>
    1.36 +<listitem><para>L'outil se chargera de suivre l'évolution de votre projet, sans
    1.37 +que vous n'ayez à le faire. Pour chaque modification, vous aurez à votre
    1.38 +disposition un journal indiquant <emphasis>qui</emphasis> a fait quoi, <emphasis>pourquoi</emphasis>
    1.39 +ils l'ont fait, <emphasis>quand</emphasis> ils l'ont fait, et <emphasis>ce</emphasis> qu'ils ont
    1.40 +modifiés.</para>
    1.41 +</listitem>
    1.42 +<listitem><para>Quand vous travaillez avec d'autres personnes, les logiciels de
    1.43 +gestion de source facilitent le travail collaboratif. Par exemple, quand
    1.44 +plusieurs personnes font, plus ou moins simultanément, des modifications
    1.45 +incompatibles, le logiciel vous aidera à identifier et à résoudre les conflits.</para>
    1.46 +</listitem>
    1.47 +<listitem><para>L'outil vous aidera à réparer vos erreurs. Si vous effectuez un changement
    1.48 +qui se révèle être une erreur, vous pourrez revenir à une version
    1.49 +antérieure d'un fichier ou même d'un ensemble de fichiers. En fait, un outil de
    1.50 +gestion de source <emphasis>vraiment</emphasis> efficace vous permettra d'identifier à quel
    1.51 +moment le problème est apparu (voir la section <xref linkend="sec:undo:bisect"/> pour plus
    1.52 +de détails).</para>
    1.53 +</listitem>
    1.54 +<listitem><para>L'outil vous permettra aussi de travailler sur plusieurs versions différentes
    1.55 +de votre projet et à gérer l'écart entre chacune.</para>
    1.56 +</listitem></itemizedlist>
    1.57 +<para>La plupart de ces raisons ont autant d'importances &emdash;du moins en théorie&emdash; que
    1.58 +vous travailliez sur un projet pour vous, ou avec une centaine d'autres
    1.59 +personnes.
    1.60 +</para>
    1.61 +
    1.62 +<para>Une question fondamentale à propos des outils de gestion de source, qu'il s'agisse
    1.63 +du projet d'une personne ou d'une grande équipe, est quels sont ses
    1.64 +<emphasis>avantages</emphasis> par rapport à ses <emphasis>coûts</emphasis>. Un outil qui est difficile à
    1.65 +utiliser ou à comprendre exigera un lourd effort d'adaptation.
    1.66 +</para>
    1.67 +
    1.68 +<para>Un projet de cinq milles personnes s'effondrera très certainement de lui même
    1.69 +sans aucun processus et outil de gestion de source. Dans ce cas, le coût
    1.70 +d'utilisation d'un logiciel de gestion de source est dérisoire puisque
    1.71 +<emphasis>sans</emphasis>, l'échec est presque garanti.
    1.72 +</para>
    1.73 +
    1.74 +<para>D'un autre coté, un <quote>rapide hack</quote> d'une personne peut sembler un contexte
    1.75 +bien pauvre pour utiliser un outil de gestion de source, car, bien évidement
    1.76 +le coût d'utilisation dépasse le coût total du projet. N'est ce pas ?
    1.77 +</para>
    1.78 +
    1.79 +<para>Mercurial supporte ces <emphasis>deux</emphasis> échelles de travail. Vous pouvez apprendre
    1.80 +les bases en quelques minutes seulement, et, grâce à sa performance, vous pouvez
    1.81 +l'utiliser avec facilité sur le plus petit des projets. Cette simplicité
    1.82 +signifie que vous n'avez pas de concept obscurs ou de séquence de commandes
    1.83 +défiant l'imagination, sans aucune corrélation avec \emph{ce que vous êtes
    1.84 +vraiment en train de faire}. En même temps, ces mêmes performances et sa
    1.85 +nature <quote>peer-to-peer</quote> vous permettent d'augmenter, sans difficulté, son
    1.86 +utilisation à de très grands projets.
    1.87 +</para>
    1.88 +
    1.89 +<para>Aucun outil de gestion de source ne peut sauver un projet mal mené, mais un
    1.90 +bon outil peut rendre beaucoup plus fluide votre travail.
    1.91 +</para>
    1.92 +
    1.93 +</sect2>
    1.94 +<sect2>
    1.95 +<title>Les multiples noms de la gestion de source</title>
    1.96 +
    1.97 +<para>La gestion de source\footnote{NdT: J'ai utilisé systématiquement le terme
    1.98 +<quote>gestion de source</quote> à travers tout l'ouvrage. Ce n'est pas forcement la
    1.99 +meilleure traduction, et ceci peut rendre la lecture un peu lourde, mais je
   1.100 +pense que le document y gagne en clarté et en précision.} est un domaine
   1.101 +divers, tellement qu'il n'existe pas une seul nom ou acronyme pour le désigner.
   1.102 +Voilà quelqu'uns des noms ou
   1.103 +acronymes que vous rencontrerez le plus souvent\footnote{NdT: J'ai conservé la
   1.104 +liste des noms en anglais pour des raisons de commodité (ils sont plus
   1.105 +<quote>googelable</quote>). En outre, j'ai opté  pour conserver l'ensemble des opérations de
   1.106 +Mercurial (\textit{commit},\textit{push}, \textit{pull},...) en anglais, là
   1.107 +aussi pour faciliter la lecture d'autres documents en anglais, ainsi que
   1.108 +l'utilisation de Mercurial}.
   1.109 +</para>
   1.110 +
   1.111 +<para>:
   1.112 +</para>
   1.113 +<itemizedlist>
   1.114 +<listitem><para>\textit{Revision control (RCS)} ;
   1.115 +</para>
   1.116 +</listitem>
   1.117 +<listitem><para>Software configuration management (SCM), ou \textit{configuration management} ;
   1.118 +</para>
   1.119 +</listitem>
   1.120 +<listitem><para>\textit{Source code management} ;
   1.121 +</para>
   1.122 +</listitem>
   1.123 +<listitem><para>\textit{Source code control}, ou \textit{source control} ;
   1.124 +</para>
   1.125 +</listitem>
   1.126 +<listitem><para>\textit{Version control (VCS)}.
   1.127 +</para>
   1.128 +</listitem></itemizedlist>
   1.129 +
   1.130 +<para>Certaines personnes prétendent que ces termes ont en fait des sens
   1.131 +différents mais en pratique ils se recouvrent tellement qu'il n'y a pas
   1.132 +réellement de manière pertinente de les distinguer.
   1.133 +</para>
   1.134 +
   1.135 +</sect2>
   1.136 +</sect1>
   1.137 +<sect1>
   1.138 +<title>Une courte histoire de la gestion de source</title>
   1.139 +
   1.140 +<para>Le plus célèbre des anciens outils de gestion de source est \textit{SCCS
   1.141 +(Source Code Control System)}, que Marc Rochkind conçu dans les laboratoires de
   1.142 +recherche de Bell (\textit{Bell Labs}), dans le début des années 70.
   1.143 +\textit{SCCS} ne fonctionnait que sur des fichiers individuels, et obligeait chaque
   1.144 +personne travaillant sur le projet d'avoir un accès à un répertoire de
   1.145 +travail commun, sur le même système. Seulement une seule personne pouvait
   1.146 +modifier un fichier au même moment, ce fonctionnement était assuré par
   1.147 +l'utilisation de verrou (<quote>lock</quote>). Il était courant que des personnes
   1.148 +verrouillent des fichiers, et plus tard, oublient de le déverrouiller;
   1.149 +empêchant n'importe qui d'autre de travailler sur ces fichiers sans l'aide de
   1.150 +l'administrateur...
   1.151 +</para>
   1.152 +
   1.153 +<para>Walter Tichy a développé une alternative libre à \textit{SCCS} au début des
   1.154 +années 80, qu'il nomma \textit{RSC (Revison Control System)}.  Comme
   1.155 +\textit{SCCS}, \textit{RCS} demandait aux développeurs de travailler sur le même
   1.156 +répertoire partagé, et de verrouiller les
   1.157 +fichiers pour se prémunir de tout conflit issu de modifications concurrentes.
   1.158 +</para>
   1.159 +
   1.160 +<para>Un peu plus tard dans les années 1980, Dick Grune utilisa \textit{RCS} comme
   1.161 +une brique de base pour un ensemble de scripts \textit{shell} qu'il intitula
   1.162 +cmt, avant de la renommer en \textit{CVS (Concurrent Versions System)}.  La
   1.163 +grande innovation de CVS était que les développeurs pouvaient travailler
   1.164 +simultanément et indépendamment dans leur propre espace de travail. Ces espaces
   1.165 +de travail privés assuraient que les développeurs ne se marchent pas
   1.166 +mutuellement sur les pieds, comme c'était souvent le cas avec RCS et SCCS.
   1.167 +Chaque développeur disposait donc de sa copie de tous les fichiers du projet,
   1.168 +et ils pouvaient donc librement les modifier. Ils devaient néanmoins effectuer
   1.169 +la <quote>fusion</quote> (\textit{<quote>merge</quote>}) de leurs fichiers, avant d'effectuer le
   1.170 +<quote>commit</quote> de leur modifications sur le dépôt central.
   1.171 +</para>
   1.172 +
   1.173 +<para>Brian Berliner reprit les scripts de Grune's et les réécrit en C, qu'il publia
   1.174 +en 1989. Depuis, ce code a été modifié jusqu'à devenir la version moderne de
   1.175 +CVS. CVS a acquis ainsi la capacité de fonctionner en réseau, transformant son
   1.176 +architecture en client/serveur. L'architecture de CVS est centralisée, seul le
   1.177 +serveur a une copie de l'historique du projet. L'espace de travail client ne
   1.178 +contient qu'une copie de la dernière version du projet, et quelques métadonnées
   1.179 +pour indiquer où le serveur se trouve. CVS a été un grand succès, aujourd'hui
   1.180 +il est probablement l'outil de gestion de contrôle le plus utilisé au monde.
   1.181 +</para>
   1.182 +
   1.183 +<para>Au début des années 1990, Sun Microsystmes développa un premier outil de
   1.184 +gestion de source distribué, nommé TeamWare. Un espace de travail TeamWare
   1.185 +contient une copie complète de l'historique du projet. TeamWare n'a pas de
   1.186 +notion de dépôt central. (CVS utilisait RCS pour le stockage de l'historique,
   1.187 +TeamWare utilisait SCCS).
   1.188 +</para>
   1.189 +
   1.190 +<para>Alors que les années 1990 avançaient, les utilisateurs ont pris conscience d'un
   1.191 +certain nombre de problèmes avec CVS. Il enregistrait simultanément des
   1.192 +modifications sur différents fichiers individuellement, au lieu de les
   1.193 +regrouper dans une seule opération cohérente et atomique. Il ne gère pas bien
   1.194 +sa hiérarchie de fichier, il est donc assez aisé de créer le chaos en renommant
   1.195 +les fichiers et les répertoires. Pire encore, son code source est difficile à
   1.196 +lire et à maintenir, ce qui agrandit largement le <quote>niveau de souffrance</quote>
   1.197 +associé à la réparation de ces problèmes d'architecture de manière prohibitive.
   1.198 +</para>
   1.199 +
   1.200 +<para>En 2001, Jim Blandy et Karl Fogel, deux développeurs qui avaient travaillé sur
   1.201 +CVS, initièrent un projet pour le remplacer par un outil qui aurait une
   1.202 +meilleure architecture et un code plus propre. Le résultat, Subversion, ne
   1.203 +quitte pas le modèle centralisé et client/server de CVS, mais ajoute les
   1.204 +opérations de <quote>commit</quote> atomique sur de multiples fichiers, une meilleure
   1.205 +gestion des espaces de noms, et d'autres fonctionnalités qui en font un
   1.206 +meilleur outil que CVS. Depuis sa première publication, il est rapidement
   1.207 +devenu très populaire.
   1.208 +</para>
   1.209 +
   1.210 +<para>Plus ou moins simultanément, Graydon Hoare a commencé sur l'ambitieux
   1.211 +système de gestion distribué Monotone. Bien que Monotone corrige plusieurs
   1.212 +défauts de CVS's tout en offrant une architecture <quote>peer-to-peer</quote>, il va aussi
   1.213 +plus loin que la plupart des outils de révision de manière assez innovante. Il
   1.214 +utilise des <quote>hash</quote> cryptographiques comme identifiants, et il a une notion
   1.215 +complète de <quote>confiance</quote> du code issu des différentes sources.
   1.216 +</para>
   1.217 +
   1.218 +<para>Mercurial est né en 2005. Bien que très influencé par Monotone, Mercurial se
   1.219 +concentre sur la facilité d'utilisation, les performances et la capacité à
   1.220 +monter en charge pour de très gros projets.
   1.221 +</para>
   1.222 +
   1.223 +</sect1>
   1.224 +<sect1>
   1.225 +<title>Tendances de la gestion de source</title>
   1.226 +
   1.227 +<para>Il y a eu une tendance évidente dans le développement et l'utilisation d'outils
   1.228 +de gestion de source depuis les quatre dernières décades, au fur et à mesure
   1.229 +que les utilisateurs se sont habitués à leur outils et se sont sentis contraints
   1.230 +par leurs limitations.
   1.231 +</para>
   1.232 +
   1.233 +<para>La première génération commença simplement par gérer un fichier unique sur un
   1.234 +ordinateur individuel. Cependant, même si ces outils présentaient une grande
   1.235 +avancée par rapport à la gestion manuelle des versions, leur modèle de
   1.236 +verrouillage et leur utilisation limitée à un seul ordinateur rendaient leur
   1.237 +utilisation possible uniquement dans une très petite équipe.
   1.238 +</para>
   1.239 +
   1.240 +<para>La seconde génération a assoupli ces contraintes en adoptant une architecture
   1.241 +réseau et centralisée, permettant de gérer plusieurs projets entiers en même
   1.242 +temps. Alors que les projets grandirent en taille, ils rencontrèrent de nouveaux
   1.243 +problèmes. Avec les clients discutant régulièrement avec le serveurs, la montée
   1.244 +en charge devint un réel problème sur les gros projets. Une connexion réseau
   1.245 +peu fiable pouvait complètement empêcher les utilisateurs distants de dialoguer
   1.246 +avec le serveur. Alors que les projets \textit{Open Source} commencèrent à
   1.247 +mettre en place des accès en lecture seule disponible anonymement, les
   1.248 +utilisateurs sans les privilèges de <quote>commit</quote> réalisèrent qu'ils ne pouvaient
   1.249 +pas utiliser les outils pour collaborer naturellement avec le projet, comme ils
   1.250 +ne pouvaient pas non plus enregistrer leurs modifications.
   1.251 +</para>
   1.252 +
   1.253 +<para>La génération actuelle des outils de gestion de source est <quote>peer-to-peer</quote> par
   1.254 +nature. Tout ces systèmes ont abandonné la dépendance à un serveur central, et
   1.255 +ont permis à leur utilisateur de distribuer les données de leur gestion de
   1.256 +source à qui en a besoin. La collaboration à travers Internet a transformé la
   1.257 +contrainte technologique en une simple question de choix et de consencus. Les
   1.258 +outils modernes peuvent maintenant fonctionner en mode déconnecté sans limite et
   1.259 +de manière autonome, la connexion au réseau n'étant nécessaire que pour
   1.260 +synchroniser les modifications avec les autres dépôts.
   1.261 +</para>
   1.262 +
   1.263 +</sect1>
   1.264 +<sect1>
   1.265 +<title>Quelques avantages des gestionnaires de source distribués</title>
   1.266 +
   1.267 +<para>Même si les gestionnaire de source distribués sont depuis plusieurs années
   1.268 +assez robustes et aussi utilisables que leurs prédécesseurs, les utilisateurs
   1.269 +d'autres outils n'y ont pas encore été sensibilisés. Les gestionnaires
   1.270 +de source distribués se distinguent particulièrement de leurs équivalents
   1.271 +centralisés de nombreuses manières.
   1.272 +</para>
   1.273 +
   1.274 +<para>Pour un développeur individuel, ils restent beaucoup plus rapides que les
   1.275 +outils centralisés. Cela pour une raison simple : un outil centralisé doit
   1.276 +toujours dialoguer à travers le réseau pour la plupart des opérations, car
   1.277 +presque toutes les métadonnées sont stockées sur la seule copie du serveur
   1.278 +central. Un outil distribué stocke toute ses métadonnées localement. À tâche
   1.279 +égale, effectuer un échange avec le réseau ajoute un délai aux outils
   1.280 +centralisés. Ne sous-estimez pas la valeur d'un outil rapide : vous allez
   1.281 +passer beaucoup de temps à interagir avec un logiciel de gestion de source.
   1.282 +</para>
   1.283 +
   1.284 +<para>Les outils distribués sont complètement indépendants des aléas de votre serveur,
   1.285 +d'autant plus qu'ils répliquent les métadonnées à beaucoup d'endroits. Si
   1.286 +votre serveur central prend feu, vous avez intérêt à ce que les médias de
   1.287 +sauvegardes soient fiables, et que votre dernier <quote>backup</quote> soit récent et
   1.288 +fonctionne sans problème. Avec un outil distribué, vous avez autant de
   1.289 +<quote>backup</quote> que de contributeurs.
   1.290 +</para>
   1.291 +
   1.292 +<para>En outre, la fiabilité de votre réseau affectera beaucoup moins les
   1.293 +outils distribués. Vous ne pouvez même pas utiliser un outil centralisé
   1.294 +sans connexion réseau, à l'exception de quelques commandes, très limitées.
   1.295 +Avec un outil distribué, si votre connexion réseau tombe pendant que vous
   1.296 +travaillez, vous pouvez ne même pas vous en rendre compte. La seule chose
   1.297 +que vous ne serez pas capable de faire sera de communiquer avec des dépôts
   1.298 +distants, opération somme toute assez rare en comparaison aux opérations
   1.299 +locales. Si vous avez une équipe de collaborateurs très dispersée ceci peut
   1.300 +être significatif.
   1.301 +</para>
   1.302 +
   1.303 +<sect2>
   1.304 +<title>Avantages pour les projets \textit{Open Source}</title>
   1.305 +
   1.306 +<para>Si vous prenez goût à un projet \textit{Open Source} et que vous
   1.307 +décidez de commencer à toucher à son code, et que le projet utilise
   1.308 +un gestionnaire de source distribué, vous êtes immédiatement un "pair"
   1.309 +avec les personnes formant le <quote>cœur</quote> du projet. Si ils publient
   1.310 +leurs dépôts, vous pouvez immédiatement copier leurs historiques de
   1.311 +projet, faire des modifications, enregistrer votre travail en utilisant
   1.312 +les même outils qu'eux. Par comparaison, avec un outil centralisé, vous
   1.313 +devez utiliser un logiciel en mode <quote>lecture seule</quote> à moins que
   1.314 +quelqu'un ne vous donne les privilèges de <quote>commit</quote> sur le serveur
   1.315 +central. Avant ça, vous ne serez pas capable d'enregistrer vos
   1.316 +modifications, et vos propres modifications risqueront de se
   1.317 +corrompre chaque fois que vous essayerez de mettre à jour à votre
   1.318 +espace de travail avec le serveur central.
   1.319 +</para>
   1.320 +
   1.321 +<sect3>
   1.322 +<title>Le non-problème du \textit{fork}</title>
   1.323 +
   1.324 +<para>Il a été souvent suggéré que les gestionnaires de source distribués
   1.325 +posent un risque pour les projets \textit{Open Source} car ils
   1.326 +facilitent grandement la création de <quote>fork</quote>\footnote{NdT:Création
   1.327 +d'une
   1.328 +<ulink url="version alternative du logiciel">version alternative du logiciel</ulink>{http://fr.wikipedia.org/wiki/Fork#Embranchement_d.27un_projet_informatique}.}
   1.329 +Un <quote>fork</quote> apparait quand il y des divergences d'opinion ou d'attitude
   1.330 +au sein d'un groupe de développeurs qui aboutissent à la décision de ne
   1.331 +plus travailler ensemble. Chaque parti s'empare d'une copie plus ou moins
   1.332 +complète du code source du projet et continue dans sa propre direction.
   1.333 +</para>
   1.334 +
   1.335 +<para>Parfois ces différents partis décident de se réconcilier. Avec un
   1.336 +serveur central, l'aspect <emphasis>technique</emphasis> de cette réconciliation
   1.337 +est un processus douloureux, et essentiellement manuel. Vous devez
   1.338 +décider quelle modification est <quote>la gagnante</quote>, et replacer, par un
   1.339 +moyen ou un autre, les modifications de l'autre équipe dans l'arborescence
   1.340 +du projet. Ceci implique généralement la perte d'une partie de l'historique
   1.341 +d'un des partis, ou même des deux.
   1.342 +</para>
   1.343 +
   1.344 +<para>Ce que les outils distribués permettent à ce sujet est probablement
   1.345 +la <emphasis>meilleure</emphasis> façon de développer un projet. Chaque modification
   1.346 +que vous effectuez est potentiellement un <quote>fork</quote>. La grande force de
   1.347 +cette approche est que les gestionnaires de source distribués doivent être
   1.348 +vraiment très efficaces pour <emphasis>fusionner</emphasis>\footnote{NdT:j'ai choisi de
   1.349 +traduire ici \textit{merging} par <quote>fusionner</quote> pour des raisons de clarté}
   1.350 +des <quote>forks</quote>, car les <quote>forks</quote>, dans ce contexte, arrivent tout le
   1.351 +temps.
   1.352 +</para>
   1.353 +
   1.354 +<para>Si chaque altération que n'importe qui effectue, à tout moment, est vue
   1.355 +comme un <quote>fork</quote> à fusionner, alors ce que le monde de l'\textit{Open
   1.356 +Source} voit comme un <quote>fork</quote> devient <emphasis>uniquement</emphasis> une problématique
   1.357 +sociale. En fait, les outils de gestions de source distribués <emphasis>réduisent</emphasis>
   1.358 +les chances de <quote>fork</quote>:
   1.359 +</para>
   1.360 +<itemizedlist>
   1.361 +<listitem><para>Ils éliminent la distinction sociale qu'imposent les outils centralisés
   1.362 +    entre les membres du projets (ceux qui ont accès au <quote>commit</quote>) et ceux de
   1.363 +    l'extérieur (ce qui ne l'ont pas).  \item Ils rendent plus facile la
   1.364 +    réconciliation après un <quote>fork</quote> social, car
   1.365 +	tout ce qu'elle implique est une simple fusion.
   1.366 +</para>
   1.367 +</listitem></itemizedlist>
   1.368 +
   1.369 +<para>Certaines personnes font de la résistance envers les gestionnaires de source
   1.370 +distribués parce qu'ils veulent garder un contrôle ferme sur leur projet, et
   1.371 +ils pensent que les outils centralisés leur fournissent ce contrôle. Néanmoins,
   1.372 +si c'est votre cas, sachez que si vous publiez votre dépôt CVS ou Subversion
   1.373 +de manière publique, il existe une quantité d'outils disponibles pour récupérer
   1.374 +entièrement votre projet et son historique (quoique lentement) et le récréer
   1.375 +ailleurs, sans votre contrôle. En fait, votre contrôle sur votre projet est
   1.376 +illusoire, vous ne faites qu'interdire à vos collaborateurs de travailler
   1.377 +de manière fluide, en disposant d'un miroir ou d'un <quote>fork</quote> de votre
   1.378 +historique.
   1.379 +%%%TODO: Fussy, those last sentences are not really well translated:
   1.380 +%%%no problem for me (wilk)
   1.381 +%However, if you're of this belief, and you publish your CVS or Subversion
   1.382 +%repositories publically, there are plenty of tools available that can pull
   1.383 +%out your entire project's history (albeit slowly) and recreate it somewhere
   1.384 +%that you don't control.  So while your control in this case is illusory, you are
   1.385 +%forgoing the ability to fluidly collaborate with whatever people feel
   1.386 +%compelled to mirror and fork your history.
   1.387 +</para>
   1.388 +
   1.389 +</sect3>
   1.390 +</sect2>
   1.391 +<sect2>
   1.392 +<title>Avantages pour les projets commerciaux</title>
   1.393 +
   1.394 +<para>Beaucoup de projets commerciaux sont réalisés par des équipes éparpillées
   1.395 +à travers le globe. Les contributeurs qui sont loin du serveur central
   1.396 +devront subir des commandes lentes et même parfois peu fiables. Les
   1.397 +solutions propriétaires de gestion de source tentent de palier ce problème
   1.398 +avec des réplications de sites distants qui sont à la fois coûteuses à mettre
   1.399 +en place et lourdes à administrer. Un système distribué ne souffre pas
   1.400 +de ce genre de problèmes. En outre, il est très aisé de mettre en place
   1.401 +plusieurs serveurs de références, disons un par site, de manière à ce qu'il
   1.402 +n'y ait pas de communication redondante entre les dépôts, sur une connexion
   1.403 +longue distance souvent onéreuse.
   1.404 +</para>
   1.405 +
   1.406 +<para>Les systèmes de gestion de source supportent généralement assez mal la
   1.407 +montée en charge. Ce n'est pas rare pour un gestionnaire de source centralisé
   1.408 +pourtant onéreux de s'effondrer sous la charge combinée d'une douzaine
   1.409 +d'utilisateurs concurrents seulement. Une fois encore, la réponse à cette problématique
   1.410 +est généralement encore la mise en place d'un ensemble complexe de serveurs
   1.411 +synchronisés par un mécanisme de réplication. Dans le cas d'un gestionnaire
   1.412 +de source distribué, la charge du serveur central &emdash; si vous avez un&emdash; est
   1.413 +plusieurs fois inférieure (car toutes les données sont déjà répliquées ailleurs),
   1.414 +un simple serveur, pas très cher, peut gérer les besoins d'une plus grande
   1.415 +équipe, et la réplication pour balancer la charge devient le
   1.416 +travail d'un simple script.
   1.417 +</para>
   1.418 +
   1.419 +<para>Si vous avez des employés sur le terrain, en train de chercher à résoudre un souci sur
   1.420 +le site d'un client, ils bénéficieront aussi d'un gestionnaire de source
   1.421 +distribué. Cet outil leur permettra de générer des versions personnalisées,
   1.422 +d'essayer différentes solutions, en les isolant aisément les unes des autres,
   1.423 +et de rechercher efficacement à travers l'historique des sources, la cause
   1.424 +des bugs ou des régressions, tout ceci sans avoir besoin de la moindre
   1.425 +connexion au réseau de votre compagnie.
   1.426 +</para>
   1.427 +
   1.428 +</sect2>
   1.429 +</sect1>
   1.430 +<sect1>
   1.431 +<title>Pourquoi choisir Mercurial?</title>
   1.432 +
   1.433 +<para>Mercurial a plusieurs caractéristiques qui en font un choix particulièrement
   1.434 +pertinent pour la gestion de source:
   1.435 +</para>
   1.436 +<itemizedlist>
   1.437 +<listitem><para>	\item Il est facile à apprendre et à utiliser ;
   1.438 +	\item Il est léger et performant ;
   1.439 +	\item Il monte facilement en charge ;
   1.440 +	\item Il est facile à personnaliser ;
   1.441 +</para>
   1.442 +</listitem></itemizedlist>
   1.443 +
   1.444 +<para>Si vous êtes déjà familier d'un outil de gestion de source, vous serez
   1.445 +capable de l'utiliser en moins de 5 minutes. Sinon, ça ne sera pas beaucoup
   1.446 +plus long\footnote{NdT: Pour appuyer le propos de l'auteur, je signale que
   1.447 +j'utilise Mercurial comme outil d'initiation à la gestion de contrôle dans
   1.448 +des travaux pratiques à l'ESME Sudria (<ulink url="http://www.esme.fr">http://www.esme.fr</ulink>) et que les
   1.449 +élèves le prennent en main sans difficulté majeure malgré l'approche distribuée.}.
   1.450 +Les commandes utilisées par Mercurial, comme ses fonctionnalités, sont
   1.451 +généralement uniformes et cohérentes, et vous pouvez donc ainsi garder en tête
   1.452 +simplement quelques règles générales, plutôt qu'un lot complexe d'exceptions.
   1.453 +</para>
   1.454 +
   1.455 +<para>Sur un petit projet, vous pouvez commencer à travailler avec Mercurial en
   1.456 +quelques instants. Ajouter des modifications ou des branches, transférer
   1.457 +ces modifications (localement ou via le réseau), et les opérations
   1.458 +d'historique ou de statut sont aussi très rapides. Mercurial reste hors de
   1.459 +votre chemin grâce à sa simplicité d'utilisation et sa rapidité d'exécution.
   1.460 +</para>
   1.461 +
   1.462 +<para>L'utilité de Mercurial ne se limite pas à de petits projets: il est
   1.463 +aussi utilisé par des projets ayant des centaines ou même des milliers
   1.464 +de contributeurs, avec plusieurs dizaines de milliers de fichiers, et des
   1.465 +centaines de méga de code source.
   1.466 +</para>
   1.467 +
   1.468 +<para>Voici une liste non exhaustive des projets complexes ou critiques utilisant
   1.469 +Mercurial :
   1.470 +%TODO
   1.471 +% For both spanish and english version, add the following examples:
   1.472 +</para>
   1.473 +<itemizedlist>
   1.474 +<listitem><para>	\item <ulink url="Firefox">Firefox</ulink>{https://developer.mozilla.org/en/Mozilla_Source_Code_(Mercurial)} ;
   1.475 +	\item <ulink url="OpenSolaris">OpenSolaris</ulink>{http://opensolaris.org/os/community/tools/scm/hg_help/} ;
   1.476 +	\item <ulink url="OpenJDK">OpenJDK</ulink>{http://hg.openjdk.java.net/} (utilisant en outre l'extension
   1.477 +	<quote>forest</quote> pour gérer ses sous modules);
   1.478 +</para>
   1.479 +</listitem></itemizedlist>
   1.480 +
   1.481 +<para>Si les fonctionnalités cœur de Mercurial ne sont pas suffisantes pour vous,
   1.482 +il est très aisé d'en construire d'autres. Mercurial est adapté à l'utilisation
   1.483 +de scripts, et son implémentation interne en Python, propre et claire,
   1.484 +rend encore plus facile l'ajout de fonctionnalités sous forme d'extensions. Il
   1.485 +en existe déjà un certain nombre de très populaires et très utiles,
   1.486 +dont le périmètre va de la recherche de bugs à l'amélioration des performances.
   1.487 +</para>
   1.488 +
   1.489 +</sect1>
   1.490 +<sect1>
   1.491 +<title>Mercurial comparé aux autres outils</title>
   1.492 +
   1.493 +<para>Avant que vous n'alliez plus loin, comprenez bien que cette section
   1.494 +reflète mes propres expériences, et elle est donc (j'ose le dire)
   1.495 +peu objective. Néanmoins, j'ai utilisé les outils de gestion de source
   1.496 +listés ci dessous, dans la plupart des cas, pendant plusieurs années.
   1.497 +%% TODO: Fussy translation.
   1.498 +</para>
   1.499 +
   1.500 +<sect2>
   1.501 +<title>Subversion</title>
   1.502 +
   1.503 +<para>Subversion est un des outils de gestion de source les plus populaire, il fût
   1.504 +développé pour remplacer CVS. Il a une architecture client/server centralisée.
   1.505 +</para>
   1.506 +
   1.507 +<para>Subversion et Mercurial ont des noms de commandes très similaires pour
   1.508 +les mêmes opérations, ainsi si vous êtes familier avec l'un, c'est facile
   1.509 +d'apprendre l'autre. Ces deux outils sont portables sur les systèmes
   1.510 +d'exploitation les plus populaires\footnote{NdT:Mercurial fonctionne sans problème
   1.511 +sur OpenVMS à l'ESME Sudria <ulink url="http://www.esme.fr">http://www.esme.fr</ulink>, compte tenu que Subversion a été
   1.512 +développé en C, je ne suis pas sûr que son portage aurait été aussi aisé.}.
   1.513 +%TODO: Backport this statement in english and spanish
   1.514 +</para>
   1.515 +
   1.516 +<para>Avant la version 1.5, Subversion n'offrait aucune forme de support pour les fusions. Lors
   1.517 +de l'écriture de ce livre, ses capacités de fusion étaient nouvelles, et réputées pour être
   1.518 +\href{http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword}{complexes
   1.519 +et bugguées}.
   1.520 +</para>
   1.521 +
   1.522 +<para>Mercurial dispose d'un avantage substantiel en terme de performance par rapport à
   1.523 +Subversion sur la plupart des opérations que j'ai pu tester. J'ai mesuré
   1.524 +une différence de performance allant de deux à six fois plus rapide avec
   1.525 +le système de stockage de fichier local de Subversion 1.4.3
   1.526 +(<emphasis>ra_local</emphasis>), qui est la méthode d'accès la plus rapide disponible. Dans
   1.527 +un déploiement plus réaliste, impliquant un stockage réseau, Subversion
   1.528 +serait encore plus désavantagé. Parce que la plupart des commandes Subversion
   1.529 +doivent communiquer avec le serveur et que Subversion n'a pas de mécanisme
   1.530 +de réplication, la capacité du serveur et la bande passante sont devenues des
   1.531 +goulots d'étranglement pour les projets de taille moyenne ou grande.
   1.532 +</para>
   1.533 +
   1.534 +<para>En outre, Subversion implique une surcharge substantielle dans le stockage local
   1.535 +de certaines données, pour éviter des transactions avec le serveur, pour
   1.536 +certaines opérations communes, telles que la recherche des fichiers modifiés
   1.537 +(<literal>status</literal>) et l'affichage des modifications par rapport à la révision
   1.538 +courante (<literal>diff</literal>). En conséquence, un répertoire de travail Subversion
   1.539 +a souvent la même taille, ou est plus grand, qu'un dépôt Mercurial et son
   1.540 +espace de travail, et ceci bien que le dépôt Mercurial contienne l'intégralité
   1.541 +de l'historique.
   1.542 +</para>
   1.543 +
   1.544 +<para>Subversion est largement supporté par les outils tierces. Mercurial est
   1.545 +actuellement encore en retrait de ce point de vue. L'écart se réduit, néanmoins,
   1.546 +et en effet certains des outils graphiques sont maintenant supérieurs à leurs
   1.547 +équivalents Subversion. Comme Mercurial, Subversion dispose d'un excellent
   1.548 +manuel utilisateur.
   1.549 +</para>
   1.550 +
   1.551 +<para>Parce que Subversion ne stocke pas l'historique chez ses clients, il est
   1.552 +parfaitement adapté à la gestion de projets qui doivent suivre un ensemble
   1.553 +de larges fichiers binaires et opaques. Si vous suivez une cinquantaine de
   1.554 +versions d'un fichier incompressible de 10MB, l'occupation disque coté client
   1.555 +d'un projet sous Subversion restera à peu près constante. A l'inverse,
   1.556 +l'occupation disque du même projet sous n'importe lequel des gestionnaires
   1.557 +de source distribués grandira rapidement, proportionnellement aux nombres
   1.558 +de versions, car les différences entre chaque révisions seront très grandes.
   1.559 +</para>
   1.560 +
   1.561 +<para>En outre, c'est souvent difficile ou, généralement, impossible de fusionner
   1.562 +des différences dans un fichier binaire. La capacité de Subversion de
   1.563 +verrouiller des fichiers, pour permettre à l'utilisateur d'être le seul
   1.564 +à le mettre à jour (<quote>commit</quote>) temporairement, est un avantage significatif
   1.565 +dans un projet doté de beaucoup de fichiers binaires.
   1.566 +</para>
   1.567 +
   1.568 +<para>Mercurial peut importer l'historique depuis un dépôt Subversion. Il peut
   1.569 +aussi exporter l'ensemble des révisions d'un projet vers un dépôt Subversion.
   1.570 +Ceci rend très facile de <quote>prendre la température</quote> et d'utiliser Mercurial et Subversion
   1.571 +en parallèle, avant de décider de migrer vers Mercurial. La conversion de
   1.572 +l'historique est incrémentale, donc vous pouvez effectuer une conversion
   1.573 +initiale, puis de petites additions par la suite pour ajouter les nouvelles
   1.574 +modifications.
   1.575 +</para>
   1.576 +
   1.577 +</sect2>
   1.578 +<sect2>
   1.579 +<title>Git</title>
   1.580 +
   1.581 +<para>Git est un outil de gestion de source distribué qui fût développé pour gérer
   1.582 +le code source de noyau de Linux. Comme Mercurial, sa conception initiale a
   1.583 +été inspirée par Monotone.
   1.584 +</para>
   1.585 +
   1.586 +<para>Git dispose d'un ensemble conséquent de commandes, avec plus de 139 commandes
   1.587 +individuelles pour la version 1.5.0. Il a aussi la réputation d'être difficile
   1.588 +à apprendre. Comparé à Git, le point fort de Mercurial est clairement sa
   1.589 +simplicité.
   1.590 +</para>
   1.591 +
   1.592 +<para>En terme de performance, Git est extrêmement rapide. Dans la plupart des
   1.593 +cas, il est plus rapide que Mercurial, tout du moins sur Linux, alors que
   1.594 +Mercurial peut être plus performant sur d'autres opérations. Néanmoins, sur
   1.595 +Windows, les performances et le niveau de support général fourni par Git,
   1.596 +au moment de l'écriture de cet ouvrage, est bien derrière celui de Mercurial.
   1.597 +</para>
   1.598 +
   1.599 +<para>Alors que le dépôt Mercurial ne demande aucune maintenance, un dépôt Git
   1.600 +exige d'exécuter manuellement et régulièrement la commande <quote>repacks</quote> sur
   1.601 +ces métadonnées. Sans ceci, les performances de git se dégradent et la
   1.602 +consommation de l'espace disque augmente rapidement. Un serveur qui contient
   1.603 +plusieurs dépôts Git qui ne sont pas régulièrement et fréquemment <quote>repacked</quote>
   1.604 +deviendra un vrai problème lors des <quote>backups</quote> du disque, et il y eu des
   1.605 +cas, où un <quote>backup</quote> journalier pouvait durer plus de 24 heures. Un dépôt
   1.606 +fraichement <quote>repacked</quote> sera légèrement plus petit qu'un dépôt Mercurial,
   1.607 +mais un dépôt non <quote>repacked</quote> est beaucoup plus grand.
   1.608 +</para>
   1.609 +
   1.610 +<para>Le cœur de Git est écrit en C. La plupart des commandes Git sont implémentées
   1.611 +sous forme de scripts Shell ou Perl, et la qualité de ces scripts varie
   1.612 +grandement. J'ai plusieurs fois constaté que certains de ces scripts étaient
   1.613 +chargés en mémoire aveuglément et que la présence d'erreurs pouvait s'avérer
   1.614 +fatal.
   1.615 +</para>
   1.616 +
   1.617 +<para>Mercurial peut importer l'historique d'un dépôt Git.
   1.618 +</para>
   1.619 +
   1.620 +</sect2>
   1.621 +<sect2>
   1.622 +<title>CVS</title>
   1.623 +
   1.624 +<para>CVS est probablement l'outil de gestion de source le plus utilisé aujourd'hui
   1.625 +dans le monde. À cause de son manque de clarté interne, il n'est plus
   1.626 +maintenu depuis plusieurs années.
   1.627 +</para>
   1.628 +
   1.629 +<para>Il a une architecture client/serveur centralisée. Il ne regroupe pas les
   1.630 +modifications de fichiers dans une opération de <quote>commit</quote> atomique, ce
   1.631 +qui permet à ses utilisateurs de <quote>casser le \textit{build}</quote> assez
   1.632 +facilement : une personne peut effectuer une opération de <quote>commit</quote>
   1.633 +sans problème puis être bloquée par besoin de fusion, avec comme conséquence
   1.634 +néfaste, que les autres utilisateurs ne récupèreront qu'une partie de ses
   1.635 +modifications. Ce problème affecte aussi la manière de travailler avec
   1.636 +l'historique du projet. Si vous voulez voir toutes les modifications d'une
   1.637 +personne du projet, vous devrez injecter manuellement les descriptions et les
   1.638 +\textit{timestamps} des modifications de chacun des fichiers impliqués (si
   1.639 +vous savez au moins quels sont ces fichiers).
   1.640 +</para>
   1.641 +
   1.642 +<para>CVS a une notion étrange des \textit{tags} et des branches que je n'essayerai
   1.643 +même pas de décrire ici. Il ne supporte pas bien les opérations de renommage d'un
   1.644 +fichier ou d'un répertoire, ce qui facilite la corruption de son dépôt. Il n'a
   1.645 +presque pas pour ainsi dire de contrôle de cohérence interne, il est donc
   1.646 +pratiquement impossible de dire si un dépôt est corrompu ni à quel point. Je
   1.647 +ne recommanderai pas CVS pour un projet existant ou nouveau.
   1.648 +</para>
   1.649 +
   1.650 +<para>Mercurial peut importer l'historique d'un projet CVS. Néanmoins, il y a
   1.651 +quelques principes à respecter; ce qui est vrai aussi pour les autres
   1.652 +outils d'import de projet CVS. À cause de l'absence de <quote>commit</quote> atomique
   1.653 +et gestion de version de l'arborescence, il n'est pas possible de reconstruire
   1.654 +de manière précise l'ensemble de l'historique. Un travail de <quote>devinette</quote>
   1.655 +est donc nécessaire, et les fichiers renommés ne sont pas détectés. Parce
   1.656 +qu'une bonne part de l'administration d'un dépôt CVS est effectuée manuellement,
   1.657 +et est donc, sujette à erreur, il est courant que les imports CVS rencontrent
   1.658 +de nombreux problèmes avec les dépôt corrompus (des \textit{timestamps}
   1.659 +de révision complètement buggés et des fichiers verrouillés depuis des années
   1.660 +sont deux des problèmes les moins intéressants dont je me souvienne).
   1.661 +</para>
   1.662 +
   1.663 +<para>Mercurial peut importer l'historique depuis un dépôt CVS.
   1.664 +</para>
   1.665 +
   1.666 +</sect2>
   1.667 +<sect2>
   1.668 +<title>Outils propriétaires</title>
   1.669 +
   1.670 +<para>Perforce a une architecture client/serveur centralisée, sans aucun
   1.671 +mécanisme de mise en cache de données coté client. Contrairement à la plupart
   1.672 +des outils modernes de gestion de source, Perforce exige de ses
   1.673 +utilisateurs d'exécuter une commande pour informer le serveur
   1.674 +central de tout fichier qu'ils souhaitent modifier.
   1.675 +</para>
   1.676 +
   1.677 +<para>Les performances de Perforce sont plutôt bonnes pour des petites
   1.678 +équipes, mais elles s'effondrent rapidement lorsque le nombre
   1.679 +d'utilisateurs augmente au delà de la douzaine. Des installations
   1.680 +de Perforce assez larges nécessitent le déploiement de proxies pour
   1.681 +supporter la montée en charge associée.
   1.682 +</para>
   1.683 +
   1.684 +</sect2>
   1.685 +<sect2>
   1.686 +<title>Choisir un outil de gestion de source</title>
   1.687 +
   1.688 +<para>A l'exception de CVS, tous les outils listés ci-dessus ont des
   1.689 +forces qui leur sont propres et qui correspondent à certaines
   1.690 +formes de projet. Il n'y a pas un seul meilleur outil de gestion
   1.691 +de source qui correspondrait le mieux à toutes les situations.
   1.692 +</para>
   1.693 +
   1.694 +<para>Par exemple, Subversion est un très bon choix lorsqu'on travaille
   1.695 +avec beaucoup de fichiers binaires, qui évoluent régulièrement, grâce
   1.696 +à sa nature centralisée et sa capacité à verrouiller des fichiers.
   1.697 +</para>
   1.698 +
   1.699 +<para>Personnellement, je préfère Mercurial pour sa simplicité, ses
   1.700 +performances et sa bonne capacité de fusion, et il m'a très bien rendu service
   1.701 +de plusieurs années maintenant.
   1.702 +</para>
   1.703 +
   1.704 +</sect2>
   1.705 +</sect1>
   1.706 +<sect1>
   1.707 +<title>Migrer depuis un outil à Mercurial</title>
   1.708 +
   1.709 +<para>Mercurial est livré avec une extension nommée <literal role="hg-ext">convert</literal>, qui
   1.710 +peut de manière incrémentale importer des révisions depuis différents
   1.711 +autres outils de gestion de source. Par <quote>incrémental</quote>, j'entends que
   1.712 +vous pouvez convertir l'historique entier du projet en une seule fois,
   1.713 +puis relancer l'outil d'import plus tard pour obtenir les modifications
   1.714 +effectuées depuis votre import initial.
   1.715 +</para>
   1.716 +
   1.717 +<para>Les outils de gestion de source supportés par <literal role="hg-ext">convert</literal> sont :
   1.718 +</para>
   1.719 +<itemizedlist>
   1.720 +<listitem><para>	\item Subversion
   1.721 +	\item CVS
   1.722 +	\item Git
   1.723 +	\item Darcs
   1.724 +</para>
   1.725 +</listitem></itemizedlist>
   1.726 +
   1.727 +<para>En outre, <literal role="hg-ext">convert</literal> peut exporter les modifications depuis Mercurial
   1.728 +vers Subversion. Ceci rend possible d'essayer Subversion en parallèle
   1.729 +avant de choisir une solution définitive, sans aucun risque de perte de
   1.730 +données.
   1.731 +</para>
   1.732 +
   1.733 +<para>La commande <command role="hg-ext-conver">convert</command> est très simple à utiliser. Simplement,
   1.734 +indiquez le chemin ou l'URL du dépôt de source, en lui indiquant éventuellement
   1.735 +le nom du chemin de destination, et la conversion se met en route. Après cet
   1.736 +import initial, il suffit de relancer la commande encore une fois pour
   1.737 +importer les modifications effectuées depuis.
   1.738 +</para>
   1.739 +
   1.740 +</sect1>
   1.741 +</chapter>
   1.742 +
   1.743 +<!--
   1.744 +local variables: 
   1.745 +sgml-parent-document: ("00book.xml" "book" "chapter")
   1.746 +end:
   1.747 +-->
   1.748 \ No newline at end of file