hgbook
diff fr/ch01-intro.xml @ 964:6b680d569bb4
deleting a bunch of files not longer necessary to build the documentation.
Adding missing newly files needed to build the documentation
Adding missing newly files needed to build the documentation
author | Romain PELISSE <belaran@gmail.com> |
---|---|
date | Sun Aug 16 04:58:01 2009 +0200 (2009-08-16) |
parents | |
children | f25ab8d4486f |
line diff
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