hgbook

annotate fr/ch01-intro.xml @ 964:6b680d569bb4

find changesets by author, revision, files, or words in the commit message
deleting a bunch of files not longer necessary 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
rev   line source
belaran@964 1 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
belaran@964 2
belaran@964 3 <chapter>
belaran@964 4 <title>Introduction</title>
belaran@964 5 <para>\label{chap:intro}</para>
belaran@964 6
belaran@964 7 <sect1>
belaran@964 8 <title>À propos de la gestion source</title>
belaran@964 9
belaran@964 10 <para>La gestion de sources est un processus permettant de gérer différentes
belaran@964 11 versions de la même information. Dans sa forme la plus simple, c'est
belaran@964 12 ce que tout le monde fait manuellement : quand vous modifiez
belaran@964 13 un fichier, vous le sauvegardez sous un nouveau nom contenant un numéro,
belaran@964 14 à chaque fois plus grand que celui de la version précédente.</para>
belaran@964 15
belaran@964 16 <para>Ce genre de gestion de version manuelle est cependant facilement sujette
belaran@964 17 à des erreurs, ainsi, depuis longtemps, des logiciels existent pour
belaran@964 18 résoudre cette problématique. Les premiers outils de gestion de sources
belaran@964 19 étaient destinés à aider un seul utilisateur, à automatiser la gestion
belaran@964 20 des versions d'un seul fichier. Dans les dernières décades, cette cible
belaran@964 21 s'est largement agrandie, ils gèrent désormais de multiples fichiers, et
belaran@964 22 aident un grand nombre de personnes à travailler ensemble. Les outils les
belaran@964 23 plus modernes n'ont aucune difficulté à gérer plusieurs milliers de
belaran@964 24 personnes travaillant ensemble sur des projets regroupant plusieurs
belaran@964 25 centaines de milliers de fichiers.</para>
belaran@964 26
belaran@964 27 <sect2>
belaran@964 28 <title>Pourquoi utiliser un gestionnaire de source ?</title>
belaran@964 29
belaran@964 30 <para>Il y a de nombreuses raisons pour que vous ou votre équipe souhaitiez
belaran@964 31 utiliser un outil automatisant la gestion de version pour votre projet.</para>
belaran@964 32 <itemizedlist>
belaran@964 33 <listitem><para>L'outil se chargera de suivre l'évolution de votre projet, sans
belaran@964 34 que vous n'ayez à le faire. Pour chaque modification, vous aurez à votre
belaran@964 35 disposition un journal indiquant <emphasis>qui</emphasis> a fait quoi, <emphasis>pourquoi</emphasis>
belaran@964 36 ils l'ont fait, <emphasis>quand</emphasis> ils l'ont fait, et <emphasis>ce</emphasis> qu'ils ont
belaran@964 37 modifiés.</para>
belaran@964 38 </listitem>
belaran@964 39 <listitem><para>Quand vous travaillez avec d'autres personnes, les logiciels de
belaran@964 40 gestion de source facilitent le travail collaboratif. Par exemple, quand
belaran@964 41 plusieurs personnes font, plus ou moins simultanément, des modifications
belaran@964 42 incompatibles, le logiciel vous aidera à identifier et à résoudre les conflits.</para>
belaran@964 43 </listitem>
belaran@964 44 <listitem><para>L'outil vous aidera à réparer vos erreurs. Si vous effectuez un changement
belaran@964 45 qui se révèle être une erreur, vous pourrez revenir à une version
belaran@964 46 antérieure d'un fichier ou même d'un ensemble de fichiers. En fait, un outil de
belaran@964 47 gestion de source <emphasis>vraiment</emphasis> efficace vous permettra d'identifier à quel
belaran@964 48 moment le problème est apparu (voir la section <xref linkend="sec:undo:bisect"/> pour plus
belaran@964 49 de détails).</para>
belaran@964 50 </listitem>
belaran@964 51 <listitem><para>L'outil vous permettra aussi de travailler sur plusieurs versions différentes
belaran@964 52 de votre projet et à gérer l'écart entre chacune.</para>
belaran@964 53 </listitem></itemizedlist>
belaran@964 54 <para>La plupart de ces raisons ont autant d'importances &emdash;du moins en théorie&emdash; que
belaran@964 55 vous travailliez sur un projet pour vous, ou avec une centaine d'autres
belaran@964 56 personnes.
belaran@964 57 </para>
belaran@964 58
belaran@964 59 <para>Une question fondamentale à propos des outils de gestion de source, qu'il s'agisse
belaran@964 60 du projet d'une personne ou d'une grande équipe, est quels sont ses
belaran@964 61 <emphasis>avantages</emphasis> par rapport à ses <emphasis>coûts</emphasis>. Un outil qui est difficile à
belaran@964 62 utiliser ou à comprendre exigera un lourd effort d'adaptation.
belaran@964 63 </para>
belaran@964 64
belaran@964 65 <para>Un projet de cinq milles personnes s'effondrera très certainement de lui même
belaran@964 66 sans aucun processus et outil de gestion de source. Dans ce cas, le coût
belaran@964 67 d'utilisation d'un logiciel de gestion de source est dérisoire puisque
belaran@964 68 <emphasis>sans</emphasis>, l'échec est presque garanti.
belaran@964 69 </para>
belaran@964 70
belaran@964 71 <para>D'un autre coté, un <quote>rapide hack</quote> d'une personne peut sembler un contexte
belaran@964 72 bien pauvre pour utiliser un outil de gestion de source, car, bien évidement
belaran@964 73 le coût d'utilisation dépasse le coût total du projet. N'est ce pas ?
belaran@964 74 </para>
belaran@964 75
belaran@964 76 <para>Mercurial supporte ces <emphasis>deux</emphasis> échelles de travail. Vous pouvez apprendre
belaran@964 77 les bases en quelques minutes seulement, et, grâce à sa performance, vous pouvez
belaran@964 78 l'utiliser avec facilité sur le plus petit des projets. Cette simplicité
belaran@964 79 signifie que vous n'avez pas de concept obscurs ou de séquence de commandes
belaran@964 80 défiant l'imagination, sans aucune corrélation avec \emph{ce que vous êtes
belaran@964 81 vraiment en train de faire}. En même temps, ces mêmes performances et sa
belaran@964 82 nature <quote>peer-to-peer</quote> vous permettent d'augmenter, sans difficulté, son
belaran@964 83 utilisation à de très grands projets.
belaran@964 84 </para>
belaran@964 85
belaran@964 86 <para>Aucun outil de gestion de source ne peut sauver un projet mal mené, mais un
belaran@964 87 bon outil peut rendre beaucoup plus fluide votre travail.
belaran@964 88 </para>
belaran@964 89
belaran@964 90 </sect2>
belaran@964 91 <sect2>
belaran@964 92 <title>Les multiples noms de la gestion de source</title>
belaran@964 93
belaran@964 94 <para>La gestion de source\footnote{NdT: J'ai utilisé systématiquement le terme
belaran@964 95 <quote>gestion de source</quote> à travers tout l'ouvrage. Ce n'est pas forcement la
belaran@964 96 meilleure traduction, et ceci peut rendre la lecture un peu lourde, mais je
belaran@964 97 pense que le document y gagne en clarté et en précision.} est un domaine
belaran@964 98 divers, tellement qu'il n'existe pas une seul nom ou acronyme pour le désigner.
belaran@964 99 Voilà quelqu'uns des noms ou
belaran@964 100 acronymes que vous rencontrerez le plus souvent\footnote{NdT: J'ai conservé la
belaran@964 101 liste des noms en anglais pour des raisons de commodité (ils sont plus
belaran@964 102 <quote>googelable</quote>). En outre, j'ai opté pour conserver l'ensemble des opérations de
belaran@964 103 Mercurial (\textit{commit},\textit{push}, \textit{pull},...) en anglais, là
belaran@964 104 aussi pour faciliter la lecture d'autres documents en anglais, ainsi que
belaran@964 105 l'utilisation de Mercurial}.
belaran@964 106 </para>
belaran@964 107
belaran@964 108 <para>:
belaran@964 109 </para>
belaran@964 110 <itemizedlist>
belaran@964 111 <listitem><para>\textit{Revision control (RCS)} ;
belaran@964 112 </para>
belaran@964 113 </listitem>
belaran@964 114 <listitem><para>Software configuration management (SCM), ou \textit{configuration management} ;
belaran@964 115 </para>
belaran@964 116 </listitem>
belaran@964 117 <listitem><para>\textit{Source code management} ;
belaran@964 118 </para>
belaran@964 119 </listitem>
belaran@964 120 <listitem><para>\textit{Source code control}, ou \textit{source control} ;
belaran@964 121 </para>
belaran@964 122 </listitem>
belaran@964 123 <listitem><para>\textit{Version control (VCS)}.
belaran@964 124 </para>
belaran@964 125 </listitem></itemizedlist>
belaran@964 126
belaran@964 127 <para>Certaines personnes prétendent que ces termes ont en fait des sens
belaran@964 128 différents mais en pratique ils se recouvrent tellement qu'il n'y a pas
belaran@964 129 réellement de manière pertinente de les distinguer.
belaran@964 130 </para>
belaran@964 131
belaran@964 132 </sect2>
belaran@964 133 </sect1>
belaran@964 134 <sect1>
belaran@964 135 <title>Une courte histoire de la gestion de source</title>
belaran@964 136
belaran@964 137 <para>Le plus célèbre des anciens outils de gestion de source est \textit{SCCS
belaran@964 138 (Source Code Control System)}, que Marc Rochkind conçu dans les laboratoires de
belaran@964 139 recherche de Bell (\textit{Bell Labs}), dans le début des années 70.
belaran@964 140 \textit{SCCS} ne fonctionnait que sur des fichiers individuels, et obligeait chaque
belaran@964 141 personne travaillant sur le projet d'avoir un accès à un répertoire de
belaran@964 142 travail commun, sur le même système. Seulement une seule personne pouvait
belaran@964 143 modifier un fichier au même moment, ce fonctionnement était assuré par
belaran@964 144 l'utilisation de verrou (<quote>lock</quote>). Il était courant que des personnes
belaran@964 145 verrouillent des fichiers, et plus tard, oublient de le déverrouiller;
belaran@964 146 empêchant n'importe qui d'autre de travailler sur ces fichiers sans l'aide de
belaran@964 147 l'administrateur...
belaran@964 148 </para>
belaran@964 149
belaran@964 150 <para>Walter Tichy a développé une alternative libre à \textit{SCCS} au début des
belaran@964 151 années 80, qu'il nomma \textit{RSC (Revison Control System)}. Comme
belaran@964 152 \textit{SCCS}, \textit{RCS} demandait aux développeurs de travailler sur le même
belaran@964 153 répertoire partagé, et de verrouiller les
belaran@964 154 fichiers pour se prémunir de tout conflit issu de modifications concurrentes.
belaran@964 155 </para>
belaran@964 156
belaran@964 157 <para>Un peu plus tard dans les années 1980, Dick Grune utilisa \textit{RCS} comme
belaran@964 158 une brique de base pour un ensemble de scripts \textit{shell} qu'il intitula
belaran@964 159 cmt, avant de la renommer en \textit{CVS (Concurrent Versions System)}. La
belaran@964 160 grande innovation de CVS était que les développeurs pouvaient travailler
belaran@964 161 simultanément et indépendamment dans leur propre espace de travail. Ces espaces
belaran@964 162 de travail privés assuraient que les développeurs ne se marchent pas
belaran@964 163 mutuellement sur les pieds, comme c'était souvent le cas avec RCS et SCCS.
belaran@964 164 Chaque développeur disposait donc de sa copie de tous les fichiers du projet,
belaran@964 165 et ils pouvaient donc librement les modifier. Ils devaient néanmoins effectuer
belaran@964 166 la <quote>fusion</quote> (\textit{<quote>merge</quote>}) de leurs fichiers, avant d'effectuer le
belaran@964 167 <quote>commit</quote> de leur modifications sur le dépôt central.
belaran@964 168 </para>
belaran@964 169
belaran@964 170 <para>Brian Berliner reprit les scripts de Grune's et les réécrit en C, qu'il publia
belaran@964 171 en 1989. Depuis, ce code a été modifié jusqu'à devenir la version moderne de
belaran@964 172 CVS. CVS a acquis ainsi la capacité de fonctionner en réseau, transformant son
belaran@964 173 architecture en client/serveur. L'architecture de CVS est centralisée, seul le
belaran@964 174 serveur a une copie de l'historique du projet. L'espace de travail client ne
belaran@964 175 contient qu'une copie de la dernière version du projet, et quelques métadonnées
belaran@964 176 pour indiquer où le serveur se trouve. CVS a été un grand succès, aujourd'hui
belaran@964 177 il est probablement l'outil de gestion de contrôle le plus utilisé au monde.
belaran@964 178 </para>
belaran@964 179
belaran@964 180 <para>Au début des années 1990, Sun Microsystmes développa un premier outil de
belaran@964 181 gestion de source distribué, nommé TeamWare. Un espace de travail TeamWare
belaran@964 182 contient une copie complète de l'historique du projet. TeamWare n'a pas de
belaran@964 183 notion de dépôt central. (CVS utilisait RCS pour le stockage de l'historique,
belaran@964 184 TeamWare utilisait SCCS).
belaran@964 185 </para>
belaran@964 186
belaran@964 187 <para>Alors que les années 1990 avançaient, les utilisateurs ont pris conscience d'un
belaran@964 188 certain nombre de problèmes avec CVS. Il enregistrait simultanément des
belaran@964 189 modifications sur différents fichiers individuellement, au lieu de les
belaran@964 190 regrouper dans une seule opération cohérente et atomique. Il ne gère pas bien
belaran@964 191 sa hiérarchie de fichier, il est donc assez aisé de créer le chaos en renommant
belaran@964 192 les fichiers et les répertoires. Pire encore, son code source est difficile à
belaran@964 193 lire et à maintenir, ce qui agrandit largement le <quote>niveau de souffrance</quote>
belaran@964 194 associé à la réparation de ces problèmes d'architecture de manière prohibitive.
belaran@964 195 </para>
belaran@964 196
belaran@964 197 <para>En 2001, Jim Blandy et Karl Fogel, deux développeurs qui avaient travaillé sur
belaran@964 198 CVS, initièrent un projet pour le remplacer par un outil qui aurait une
belaran@964 199 meilleure architecture et un code plus propre. Le résultat, Subversion, ne
belaran@964 200 quitte pas le modèle centralisé et client/server de CVS, mais ajoute les
belaran@964 201 opérations de <quote>commit</quote> atomique sur de multiples fichiers, une meilleure
belaran@964 202 gestion des espaces de noms, et d'autres fonctionnalités qui en font un
belaran@964 203 meilleur outil que CVS. Depuis sa première publication, il est rapidement
belaran@964 204 devenu très populaire.
belaran@964 205 </para>
belaran@964 206
belaran@964 207 <para>Plus ou moins simultanément, Graydon Hoare a commencé sur l'ambitieux
belaran@964 208 système de gestion distribué Monotone. Bien que Monotone corrige plusieurs
belaran@964 209 défauts de CVS's tout en offrant une architecture <quote>peer-to-peer</quote>, il va aussi
belaran@964 210 plus loin que la plupart des outils de révision de manière assez innovante. Il
belaran@964 211 utilise des <quote>hash</quote> cryptographiques comme identifiants, et il a une notion
belaran@964 212 complète de <quote>confiance</quote> du code issu des différentes sources.
belaran@964 213 </para>
belaran@964 214
belaran@964 215 <para>Mercurial est né en 2005. Bien que très influencé par Monotone, Mercurial se
belaran@964 216 concentre sur la facilité d'utilisation, les performances et la capacité à
belaran@964 217 monter en charge pour de très gros projets.
belaran@964 218 </para>
belaran@964 219
belaran@964 220 </sect1>
belaran@964 221 <sect1>
belaran@964 222 <title>Tendances de la gestion de source</title>
belaran@964 223
belaran@964 224 <para>Il y a eu une tendance évidente dans le développement et l'utilisation d'outils
belaran@964 225 de gestion de source depuis les quatre dernières décades, au fur et à mesure
belaran@964 226 que les utilisateurs se sont habitués à leur outils et se sont sentis contraints
belaran@964 227 par leurs limitations.
belaran@964 228 </para>
belaran@964 229
belaran@964 230 <para>La première génération commença simplement par gérer un fichier unique sur un
belaran@964 231 ordinateur individuel. Cependant, même si ces outils présentaient une grande
belaran@964 232 avancée par rapport à la gestion manuelle des versions, leur modèle de
belaran@964 233 verrouillage et leur utilisation limitée à un seul ordinateur rendaient leur
belaran@964 234 utilisation possible uniquement dans une très petite équipe.
belaran@964 235 </para>
belaran@964 236
belaran@964 237 <para>La seconde génération a assoupli ces contraintes en adoptant une architecture
belaran@964 238 réseau et centralisée, permettant de gérer plusieurs projets entiers en même
belaran@964 239 temps. Alors que les projets grandirent en taille, ils rencontrèrent de nouveaux
belaran@964 240 problèmes. Avec les clients discutant régulièrement avec le serveurs, la montée
belaran@964 241 en charge devint un réel problème sur les gros projets. Une connexion réseau
belaran@964 242 peu fiable pouvait complètement empêcher les utilisateurs distants de dialoguer
belaran@964 243 avec le serveur. Alors que les projets \textit{Open Source} commencèrent à
belaran@964 244 mettre en place des accès en lecture seule disponible anonymement, les
belaran@964 245 utilisateurs sans les privilèges de <quote>commit</quote> réalisèrent qu'ils ne pouvaient
belaran@964 246 pas utiliser les outils pour collaborer naturellement avec le projet, comme ils
belaran@964 247 ne pouvaient pas non plus enregistrer leurs modifications.
belaran@964 248 </para>
belaran@964 249
belaran@964 250 <para>La génération actuelle des outils de gestion de source est <quote>peer-to-peer</quote> par
belaran@964 251 nature. Tout ces systèmes ont abandonné la dépendance à un serveur central, et
belaran@964 252 ont permis à leur utilisateur de distribuer les données de leur gestion de
belaran@964 253 source à qui en a besoin. La collaboration à travers Internet a transformé la
belaran@964 254 contrainte technologique en une simple question de choix et de consencus. Les
belaran@964 255 outils modernes peuvent maintenant fonctionner en mode déconnecté sans limite et
belaran@964 256 de manière autonome, la connexion au réseau n'étant nécessaire que pour
belaran@964 257 synchroniser les modifications avec les autres dépôts.
belaran@964 258 </para>
belaran@964 259
belaran@964 260 </sect1>
belaran@964 261 <sect1>
belaran@964 262 <title>Quelques avantages des gestionnaires de source distribués</title>
belaran@964 263
belaran@964 264 <para>Même si les gestionnaire de source distribués sont depuis plusieurs années
belaran@964 265 assez robustes et aussi utilisables que leurs prédécesseurs, les utilisateurs
belaran@964 266 d'autres outils n'y ont pas encore été sensibilisés. Les gestionnaires
belaran@964 267 de source distribués se distinguent particulièrement de leurs équivalents
belaran@964 268 centralisés de nombreuses manières.
belaran@964 269 </para>
belaran@964 270
belaran@964 271 <para>Pour un développeur individuel, ils restent beaucoup plus rapides que les
belaran@964 272 outils centralisés. Cela pour une raison simple : un outil centralisé doit
belaran@964 273 toujours dialoguer à travers le réseau pour la plupart des opérations, car
belaran@964 274 presque toutes les métadonnées sont stockées sur la seule copie du serveur
belaran@964 275 central. Un outil distribué stocke toute ses métadonnées localement. À tâche
belaran@964 276 égale, effectuer un échange avec le réseau ajoute un délai aux outils
belaran@964 277 centralisés. Ne sous-estimez pas la valeur d'un outil rapide : vous allez
belaran@964 278 passer beaucoup de temps à interagir avec un logiciel de gestion de source.
belaran@964 279 </para>
belaran@964 280
belaran@964 281 <para>Les outils distribués sont complètement indépendants des aléas de votre serveur,
belaran@964 282 d'autant plus qu'ils répliquent les métadonnées à beaucoup d'endroits. Si
belaran@964 283 votre serveur central prend feu, vous avez intérêt à ce que les médias de
belaran@964 284 sauvegardes soient fiables, et que votre dernier <quote>backup</quote> soit récent et
belaran@964 285 fonctionne sans problème. Avec un outil distribué, vous avez autant de
belaran@964 286 <quote>backup</quote> que de contributeurs.
belaran@964 287 </para>
belaran@964 288
belaran@964 289 <para>En outre, la fiabilité de votre réseau affectera beaucoup moins les
belaran@964 290 outils distribués. Vous ne pouvez même pas utiliser un outil centralisé
belaran@964 291 sans connexion réseau, à l'exception de quelques commandes, très limitées.
belaran@964 292 Avec un outil distribué, si votre connexion réseau tombe pendant que vous
belaran@964 293 travaillez, vous pouvez ne même pas vous en rendre compte. La seule chose
belaran@964 294 que vous ne serez pas capable de faire sera de communiquer avec des dépôts
belaran@964 295 distants, opération somme toute assez rare en comparaison aux opérations
belaran@964 296 locales. Si vous avez une équipe de collaborateurs très dispersée ceci peut
belaran@964 297 être significatif.
belaran@964 298 </para>
belaran@964 299
belaran@964 300 <sect2>
belaran@964 301 <title>Avantages pour les projets \textit{Open Source}</title>
belaran@964 302
belaran@964 303 <para>Si vous prenez goût à un projet \textit{Open Source} et que vous
belaran@964 304 décidez de commencer à toucher à son code, et que le projet utilise
belaran@964 305 un gestionnaire de source distribué, vous êtes immédiatement un "pair"
belaran@964 306 avec les personnes formant le <quote>cœur</quote> du projet. Si ils publient
belaran@964 307 leurs dépôts, vous pouvez immédiatement copier leurs historiques de
belaran@964 308 projet, faire des modifications, enregistrer votre travail en utilisant
belaran@964 309 les même outils qu'eux. Par comparaison, avec un outil centralisé, vous
belaran@964 310 devez utiliser un logiciel en mode <quote>lecture seule</quote> à moins que
belaran@964 311 quelqu'un ne vous donne les privilèges de <quote>commit</quote> sur le serveur
belaran@964 312 central. Avant ça, vous ne serez pas capable d'enregistrer vos
belaran@964 313 modifications, et vos propres modifications risqueront de se
belaran@964 314 corrompre chaque fois que vous essayerez de mettre à jour à votre
belaran@964 315 espace de travail avec le serveur central.
belaran@964 316 </para>
belaran@964 317
belaran@964 318 <sect3>
belaran@964 319 <title>Le non-problème du \textit{fork}</title>
belaran@964 320
belaran@964 321 <para>Il a été souvent suggéré que les gestionnaires de source distribués
belaran@964 322 posent un risque pour les projets \textit{Open Source} car ils
belaran@964 323 facilitent grandement la création de <quote>fork</quote>\footnote{NdT:Création
belaran@964 324 d'une
belaran@964 325 <ulink url="version alternative du logiciel">version alternative du logiciel</ulink>{http://fr.wikipedia.org/wiki/Fork#Embranchement_d.27un_projet_informatique}.}
belaran@964 326 Un <quote>fork</quote> apparait quand il y des divergences d'opinion ou d'attitude
belaran@964 327 au sein d'un groupe de développeurs qui aboutissent à la décision de ne
belaran@964 328 plus travailler ensemble. Chaque parti s'empare d'une copie plus ou moins
belaran@964 329 complète du code source du projet et continue dans sa propre direction.
belaran@964 330 </para>
belaran@964 331
belaran@964 332 <para>Parfois ces différents partis décident de se réconcilier. Avec un
belaran@964 333 serveur central, l'aspect <emphasis>technique</emphasis> de cette réconciliation
belaran@964 334 est un processus douloureux, et essentiellement manuel. Vous devez
belaran@964 335 décider quelle modification est <quote>la gagnante</quote>, et replacer, par un
belaran@964 336 moyen ou un autre, les modifications de l'autre équipe dans l'arborescence
belaran@964 337 du projet. Ceci implique généralement la perte d'une partie de l'historique
belaran@964 338 d'un des partis, ou même des deux.
belaran@964 339 </para>
belaran@964 340
belaran@964 341 <para>Ce que les outils distribués permettent à ce sujet est probablement
belaran@964 342 la <emphasis>meilleure</emphasis> façon de développer un projet. Chaque modification
belaran@964 343 que vous effectuez est potentiellement un <quote>fork</quote>. La grande force de
belaran@964 344 cette approche est que les gestionnaires de source distribués doivent être
belaran@964 345 vraiment très efficaces pour <emphasis>fusionner</emphasis>\footnote{NdT:j'ai choisi de
belaran@964 346 traduire ici \textit{merging} par <quote>fusionner</quote> pour des raisons de clarté}
belaran@964 347 des <quote>forks</quote>, car les <quote>forks</quote>, dans ce contexte, arrivent tout le
belaran@964 348 temps.
belaran@964 349 </para>
belaran@964 350
belaran@964 351 <para>Si chaque altération que n'importe qui effectue, à tout moment, est vue
belaran@964 352 comme un <quote>fork</quote> à fusionner, alors ce que le monde de l'\textit{Open
belaran@964 353 Source} voit comme un <quote>fork</quote> devient <emphasis>uniquement</emphasis> une problématique
belaran@964 354 sociale. En fait, les outils de gestions de source distribués <emphasis>réduisent</emphasis>
belaran@964 355 les chances de <quote>fork</quote>:
belaran@964 356 </para>
belaran@964 357 <itemizedlist>
belaran@964 358 <listitem><para>Ils éliminent la distinction sociale qu'imposent les outils centralisés
belaran@964 359 entre les membres du projets (ceux qui ont accès au <quote>commit</quote>) et ceux de
belaran@964 360 l'extérieur (ce qui ne l'ont pas). \item Ils rendent plus facile la
belaran@964 361 réconciliation après un <quote>fork</quote> social, car
belaran@964 362 tout ce qu'elle implique est une simple fusion.
belaran@964 363 </para>
belaran@964 364 </listitem></itemizedlist>
belaran@964 365
belaran@964 366 <para>Certaines personnes font de la résistance envers les gestionnaires de source
belaran@964 367 distribués parce qu'ils veulent garder un contrôle ferme sur leur projet, et
belaran@964 368 ils pensent que les outils centralisés leur fournissent ce contrôle. Néanmoins,
belaran@964 369 si c'est votre cas, sachez que si vous publiez votre dépôt CVS ou Subversion
belaran@964 370 de manière publique, il existe une quantité d'outils disponibles pour récupérer
belaran@964 371 entièrement votre projet et son historique (quoique lentement) et le récréer
belaran@964 372 ailleurs, sans votre contrôle. En fait, votre contrôle sur votre projet est
belaran@964 373 illusoire, vous ne faites qu'interdire à vos collaborateurs de travailler
belaran@964 374 de manière fluide, en disposant d'un miroir ou d'un <quote>fork</quote> de votre
belaran@964 375 historique.
belaran@964 376 %%%TODO: Fussy, those last sentences are not really well translated:
belaran@964 377 %%%no problem for me (wilk)
belaran@964 378 %However, if you're of this belief, and you publish your CVS or Subversion
belaran@964 379 %repositories publically, there are plenty of tools available that can pull
belaran@964 380 %out your entire project's history (albeit slowly) and recreate it somewhere
belaran@964 381 %that you don't control. So while your control in this case is illusory, you are
belaran@964 382 %forgoing the ability to fluidly collaborate with whatever people feel
belaran@964 383 %compelled to mirror and fork your history.
belaran@964 384 </para>
belaran@964 385
belaran@964 386 </sect3>
belaran@964 387 </sect2>
belaran@964 388 <sect2>
belaran@964 389 <title>Avantages pour les projets commerciaux</title>
belaran@964 390
belaran@964 391 <para>Beaucoup de projets commerciaux sont réalisés par des équipes éparpillées
belaran@964 392 à travers le globe. Les contributeurs qui sont loin du serveur central
belaran@964 393 devront subir des commandes lentes et même parfois peu fiables. Les
belaran@964 394 solutions propriétaires de gestion de source tentent de palier ce problème
belaran@964 395 avec des réplications de sites distants qui sont à la fois coûteuses à mettre
belaran@964 396 en place et lourdes à administrer. Un système distribué ne souffre pas
belaran@964 397 de ce genre de problèmes. En outre, il est très aisé de mettre en place
belaran@964 398 plusieurs serveurs de références, disons un par site, de manière à ce qu'il
belaran@964 399 n'y ait pas de communication redondante entre les dépôts, sur une connexion
belaran@964 400 longue distance souvent onéreuse.
belaran@964 401 </para>
belaran@964 402
belaran@964 403 <para>Les systèmes de gestion de source supportent généralement assez mal la
belaran@964 404 montée en charge. Ce n'est pas rare pour un gestionnaire de source centralisé
belaran@964 405 pourtant onéreux de s'effondrer sous la charge combinée d'une douzaine
belaran@964 406 d'utilisateurs concurrents seulement. Une fois encore, la réponse à cette problématique
belaran@964 407 est généralement encore la mise en place d'un ensemble complexe de serveurs
belaran@964 408 synchronisés par un mécanisme de réplication. Dans le cas d'un gestionnaire
belaran@964 409 de source distribué, la charge du serveur central &emdash; si vous avez un&emdash; est
belaran@964 410 plusieurs fois inférieure (car toutes les données sont déjà répliquées ailleurs),
belaran@964 411 un simple serveur, pas très cher, peut gérer les besoins d'une plus grande
belaran@964 412 équipe, et la réplication pour balancer la charge devient le
belaran@964 413 travail d'un simple script.
belaran@964 414 </para>
belaran@964 415
belaran@964 416 <para>Si vous avez des employés sur le terrain, en train de chercher à résoudre un souci sur
belaran@964 417 le site d'un client, ils bénéficieront aussi d'un gestionnaire de source
belaran@964 418 distribué. Cet outil leur permettra de générer des versions personnalisées,
belaran@964 419 d'essayer différentes solutions, en les isolant aisément les unes des autres,
belaran@964 420 et de rechercher efficacement à travers l'historique des sources, la cause
belaran@964 421 des bugs ou des régressions, tout ceci sans avoir besoin de la moindre
belaran@964 422 connexion au réseau de votre compagnie.
belaran@964 423 </para>
belaran@964 424
belaran@964 425 </sect2>
belaran@964 426 </sect1>
belaran@964 427 <sect1>
belaran@964 428 <title>Pourquoi choisir Mercurial?</title>
belaran@964 429
belaran@964 430 <para>Mercurial a plusieurs caractéristiques qui en font un choix particulièrement
belaran@964 431 pertinent pour la gestion de source:
belaran@964 432 </para>
belaran@964 433 <itemizedlist>
belaran@964 434 <listitem><para> \item Il est facile à apprendre et à utiliser ;
belaran@964 435 \item Il est léger et performant ;
belaran@964 436 \item Il monte facilement en charge ;
belaran@964 437 \item Il est facile à personnaliser ;
belaran@964 438 </para>
belaran@964 439 </listitem></itemizedlist>
belaran@964 440
belaran@964 441 <para>Si vous êtes déjà familier d'un outil de gestion de source, vous serez
belaran@964 442 capable de l'utiliser en moins de 5 minutes. Sinon, ça ne sera pas beaucoup
belaran@964 443 plus long\footnote{NdT: Pour appuyer le propos de l'auteur, je signale que
belaran@964 444 j'utilise Mercurial comme outil d'initiation à la gestion de contrôle dans
belaran@964 445 des travaux pratiques à l'ESME Sudria (<ulink url="http://www.esme.fr">http://www.esme.fr</ulink>) et que les
belaran@964 446 élèves le prennent en main sans difficulté majeure malgré l'approche distribuée.}.
belaran@964 447 Les commandes utilisées par Mercurial, comme ses fonctionnalités, sont
belaran@964 448 généralement uniformes et cohérentes, et vous pouvez donc ainsi garder en tête
belaran@964 449 simplement quelques règles générales, plutôt qu'un lot complexe d'exceptions.
belaran@964 450 </para>
belaran@964 451
belaran@964 452 <para>Sur un petit projet, vous pouvez commencer à travailler avec Mercurial en
belaran@964 453 quelques instants. Ajouter des modifications ou des branches, transférer
belaran@964 454 ces modifications (localement ou via le réseau), et les opérations
belaran@964 455 d'historique ou de statut sont aussi très rapides. Mercurial reste hors de
belaran@964 456 votre chemin grâce à sa simplicité d'utilisation et sa rapidité d'exécution.
belaran@964 457 </para>
belaran@964 458
belaran@964 459 <para>L'utilité de Mercurial ne se limite pas à de petits projets: il est
belaran@964 460 aussi utilisé par des projets ayant des centaines ou même des milliers
belaran@964 461 de contributeurs, avec plusieurs dizaines de milliers de fichiers, et des
belaran@964 462 centaines de méga de code source.
belaran@964 463 </para>
belaran@964 464
belaran@964 465 <para>Voici une liste non exhaustive des projets complexes ou critiques utilisant
belaran@964 466 Mercurial :
belaran@964 467 %TODO
belaran@964 468 % For both spanish and english version, add the following examples:
belaran@964 469 </para>
belaran@964 470 <itemizedlist>
belaran@964 471 <listitem><para> \item <ulink url="Firefox">Firefox</ulink>{https://developer.mozilla.org/en/Mozilla_Source_Code_(Mercurial)} ;
belaran@964 472 \item <ulink url="OpenSolaris">OpenSolaris</ulink>{http://opensolaris.org/os/community/tools/scm/hg_help/} ;
belaran@964 473 \item <ulink url="OpenJDK">OpenJDK</ulink>{http://hg.openjdk.java.net/} (utilisant en outre l'extension
belaran@964 474 <quote>forest</quote> pour gérer ses sous modules);
belaran@964 475 </para>
belaran@964 476 </listitem></itemizedlist>
belaran@964 477
belaran@964 478 <para>Si les fonctionnalités cœur de Mercurial ne sont pas suffisantes pour vous,
belaran@964 479 il est très aisé d'en construire d'autres. Mercurial est adapté à l'utilisation
belaran@964 480 de scripts, et son implémentation interne en Python, propre et claire,
belaran@964 481 rend encore plus facile l'ajout de fonctionnalités sous forme d'extensions. Il
belaran@964 482 en existe déjà un certain nombre de très populaires et très utiles,
belaran@964 483 dont le périmètre va de la recherche de bugs à l'amélioration des performances.
belaran@964 484 </para>
belaran@964 485
belaran@964 486 </sect1>
belaran@964 487 <sect1>
belaran@964 488 <title>Mercurial comparé aux autres outils</title>
belaran@964 489
belaran@964 490 <para>Avant que vous n'alliez plus loin, comprenez bien que cette section
belaran@964 491 reflète mes propres expériences, et elle est donc (j'ose le dire)
belaran@964 492 peu objective. Néanmoins, j'ai utilisé les outils de gestion de source
belaran@964 493 listés ci dessous, dans la plupart des cas, pendant plusieurs années.
belaran@964 494 %% TODO: Fussy translation.
belaran@964 495 </para>
belaran@964 496
belaran@964 497 <sect2>
belaran@964 498 <title>Subversion</title>
belaran@964 499
belaran@964 500 <para>Subversion est un des outils de gestion de source les plus populaire, il fût
belaran@964 501 développé pour remplacer CVS. Il a une architecture client/server centralisée.
belaran@964 502 </para>
belaran@964 503
belaran@964 504 <para>Subversion et Mercurial ont des noms de commandes très similaires pour
belaran@964 505 les mêmes opérations, ainsi si vous êtes familier avec l'un, c'est facile
belaran@964 506 d'apprendre l'autre. Ces deux outils sont portables sur les systèmes
belaran@964 507 d'exploitation les plus populaires\footnote{NdT:Mercurial fonctionne sans problème
belaran@964 508 sur OpenVMS à l'ESME Sudria <ulink url="http://www.esme.fr">http://www.esme.fr</ulink>, compte tenu que Subversion a été
belaran@964 509 développé en C, je ne suis pas sûr que son portage aurait été aussi aisé.}.
belaran@964 510 %TODO: Backport this statement in english and spanish
belaran@964 511 </para>
belaran@964 512
belaran@964 513 <para>Avant la version 1.5, Subversion n'offrait aucune forme de support pour les fusions. Lors
belaran@964 514 de l'écriture de ce livre, ses capacités de fusion étaient nouvelles, et réputées pour être
belaran@964 515 \href{http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword}{complexes
belaran@964 516 et bugguées}.
belaran@964 517 </para>
belaran@964 518
belaran@964 519 <para>Mercurial dispose d'un avantage substantiel en terme de performance par rapport à
belaran@964 520 Subversion sur la plupart des opérations que j'ai pu tester. J'ai mesuré
belaran@964 521 une différence de performance allant de deux à six fois plus rapide avec
belaran@964 522 le système de stockage de fichier local de Subversion 1.4.3
belaran@964 523 (<emphasis>ra_local</emphasis>), qui est la méthode d'accès la plus rapide disponible. Dans
belaran@964 524 un déploiement plus réaliste, impliquant un stockage réseau, Subversion
belaran@964 525 serait encore plus désavantagé. Parce que la plupart des commandes Subversion
belaran@964 526 doivent communiquer avec le serveur et que Subversion n'a pas de mécanisme
belaran@964 527 de réplication, la capacité du serveur et la bande passante sont devenues des
belaran@964 528 goulots d'étranglement pour les projets de taille moyenne ou grande.
belaran@964 529 </para>
belaran@964 530
belaran@964 531 <para>En outre, Subversion implique une surcharge substantielle dans le stockage local
belaran@964 532 de certaines données, pour éviter des transactions avec le serveur, pour
belaran@964 533 certaines opérations communes, telles que la recherche des fichiers modifiés
belaran@964 534 (<literal>status</literal>) et l'affichage des modifications par rapport à la révision
belaran@964 535 courante (<literal>diff</literal>). En conséquence, un répertoire de travail Subversion
belaran@964 536 a souvent la même taille, ou est plus grand, qu'un dépôt Mercurial et son
belaran@964 537 espace de travail, et ceci bien que le dépôt Mercurial contienne l'intégralité
belaran@964 538 de l'historique.
belaran@964 539 </para>
belaran@964 540
belaran@964 541 <para>Subversion est largement supporté par les outils tierces. Mercurial est
belaran@964 542 actuellement encore en retrait de ce point de vue. L'écart se réduit, néanmoins,
belaran@964 543 et en effet certains des outils graphiques sont maintenant supérieurs à leurs
belaran@964 544 équivalents Subversion. Comme Mercurial, Subversion dispose d'un excellent
belaran@964 545 manuel utilisateur.
belaran@964 546 </para>
belaran@964 547
belaran@964 548 <para>Parce que Subversion ne stocke pas l'historique chez ses clients, il est
belaran@964 549 parfaitement adapté à la gestion de projets qui doivent suivre un ensemble
belaran@964 550 de larges fichiers binaires et opaques. Si vous suivez une cinquantaine de
belaran@964 551 versions d'un fichier incompressible de 10MB, l'occupation disque coté client
belaran@964 552 d'un projet sous Subversion restera à peu près constante. A l'inverse,
belaran@964 553 l'occupation disque du même projet sous n'importe lequel des gestionnaires
belaran@964 554 de source distribués grandira rapidement, proportionnellement aux nombres
belaran@964 555 de versions, car les différences entre chaque révisions seront très grandes.
belaran@964 556 </para>
belaran@964 557
belaran@964 558 <para>En outre, c'est souvent difficile ou, généralement, impossible de fusionner
belaran@964 559 des différences dans un fichier binaire. La capacité de Subversion de
belaran@964 560 verrouiller des fichiers, pour permettre à l'utilisateur d'être le seul
belaran@964 561 à le mettre à jour (<quote>commit</quote>) temporairement, est un avantage significatif
belaran@964 562 dans un projet doté de beaucoup de fichiers binaires.
belaran@964 563 </para>
belaran@964 564
belaran@964 565 <para>Mercurial peut importer l'historique depuis un dépôt Subversion. Il peut
belaran@964 566 aussi exporter l'ensemble des révisions d'un projet vers un dépôt Subversion.
belaran@964 567 Ceci rend très facile de <quote>prendre la température</quote> et d'utiliser Mercurial et Subversion
belaran@964 568 en parallèle, avant de décider de migrer vers Mercurial. La conversion de
belaran@964 569 l'historique est incrémentale, donc vous pouvez effectuer une conversion
belaran@964 570 initiale, puis de petites additions par la suite pour ajouter les nouvelles
belaran@964 571 modifications.
belaran@964 572 </para>
belaran@964 573
belaran@964 574 </sect2>
belaran@964 575 <sect2>
belaran@964 576 <title>Git</title>
belaran@964 577
belaran@964 578 <para>Git est un outil de gestion de source distribué qui fût développé pour gérer
belaran@964 579 le code source de noyau de Linux. Comme Mercurial, sa conception initiale a
belaran@964 580 été inspirée par Monotone.
belaran@964 581 </para>
belaran@964 582
belaran@964 583 <para>Git dispose d'un ensemble conséquent de commandes, avec plus de 139 commandes
belaran@964 584 individuelles pour la version 1.5.0. Il a aussi la réputation d'être difficile
belaran@964 585 à apprendre. Comparé à Git, le point fort de Mercurial est clairement sa
belaran@964 586 simplicité.
belaran@964 587 </para>
belaran@964 588
belaran@964 589 <para>En terme de performance, Git est extrêmement rapide. Dans la plupart des
belaran@964 590 cas, il est plus rapide que Mercurial, tout du moins sur Linux, alors que
belaran@964 591 Mercurial peut être plus performant sur d'autres opérations. Néanmoins, sur
belaran@964 592 Windows, les performances et le niveau de support général fourni par Git,
belaran@964 593 au moment de l'écriture de cet ouvrage, est bien derrière celui de Mercurial.
belaran@964 594 </para>
belaran@964 595
belaran@964 596 <para>Alors que le dépôt Mercurial ne demande aucune maintenance, un dépôt Git
belaran@964 597 exige d'exécuter manuellement et régulièrement la commande <quote>repacks</quote> sur
belaran@964 598 ces métadonnées. Sans ceci, les performances de git se dégradent et la
belaran@964 599 consommation de l'espace disque augmente rapidement. Un serveur qui contient
belaran@964 600 plusieurs dépôts Git qui ne sont pas régulièrement et fréquemment <quote>repacked</quote>
belaran@964 601 deviendra un vrai problème lors des <quote>backups</quote> du disque, et il y eu des
belaran@964 602 cas, où un <quote>backup</quote> journalier pouvait durer plus de 24 heures. Un dépôt
belaran@964 603 fraichement <quote>repacked</quote> sera légèrement plus petit qu'un dépôt Mercurial,
belaran@964 604 mais un dépôt non <quote>repacked</quote> est beaucoup plus grand.
belaran@964 605 </para>
belaran@964 606
belaran@964 607 <para>Le cœur de Git est écrit en C. La plupart des commandes Git sont implémentées
belaran@964 608 sous forme de scripts Shell ou Perl, et la qualité de ces scripts varie
belaran@964 609 grandement. J'ai plusieurs fois constaté que certains de ces scripts étaient
belaran@964 610 chargés en mémoire aveuglément et que la présence d'erreurs pouvait s'avérer
belaran@964 611 fatal.
belaran@964 612 </para>
belaran@964 613
belaran@964 614 <para>Mercurial peut importer l'historique d'un dépôt Git.
belaran@964 615 </para>
belaran@964 616
belaran@964 617 </sect2>
belaran@964 618 <sect2>
belaran@964 619 <title>CVS</title>
belaran@964 620
belaran@964 621 <para>CVS est probablement l'outil de gestion de source le plus utilisé aujourd'hui
belaran@964 622 dans le monde. À cause de son manque de clarté interne, il n'est plus
belaran@964 623 maintenu depuis plusieurs années.
belaran@964 624 </para>
belaran@964 625
belaran@964 626 <para>Il a une architecture client/serveur centralisée. Il ne regroupe pas les
belaran@964 627 modifications de fichiers dans une opération de <quote>commit</quote> atomique, ce
belaran@964 628 qui permet à ses utilisateurs de <quote>casser le \textit{build}</quote> assez
belaran@964 629 facilement : une personne peut effectuer une opération de <quote>commit</quote>
belaran@964 630 sans problème puis être bloquée par besoin de fusion, avec comme conséquence
belaran@964 631 néfaste, que les autres utilisateurs ne récupèreront qu'une partie de ses
belaran@964 632 modifications. Ce problème affecte aussi la manière de travailler avec
belaran@964 633 l'historique du projet. Si vous voulez voir toutes les modifications d'une
belaran@964 634 personne du projet, vous devrez injecter manuellement les descriptions et les
belaran@964 635 \textit{timestamps} des modifications de chacun des fichiers impliqués (si
belaran@964 636 vous savez au moins quels sont ces fichiers).
belaran@964 637 </para>
belaran@964 638
belaran@964 639 <para>CVS a une notion étrange des \textit{tags} et des branches que je n'essayerai
belaran@964 640 même pas de décrire ici. Il ne supporte pas bien les opérations de renommage d'un
belaran@964 641 fichier ou d'un répertoire, ce qui facilite la corruption de son dépôt. Il n'a
belaran@964 642 presque pas pour ainsi dire de contrôle de cohérence interne, il est donc
belaran@964 643 pratiquement impossible de dire si un dépôt est corrompu ni à quel point. Je
belaran@964 644 ne recommanderai pas CVS pour un projet existant ou nouveau.
belaran@964 645 </para>
belaran@964 646
belaran@964 647 <para>Mercurial peut importer l'historique d'un projet CVS. Néanmoins, il y a
belaran@964 648 quelques principes à respecter; ce qui est vrai aussi pour les autres
belaran@964 649 outils d'import de projet CVS. À cause de l'absence de <quote>commit</quote> atomique
belaran@964 650 et gestion de version de l'arborescence, il n'est pas possible de reconstruire
belaran@964 651 de manière précise l'ensemble de l'historique. Un travail de <quote>devinette</quote>
belaran@964 652 est donc nécessaire, et les fichiers renommés ne sont pas détectés. Parce
belaran@964 653 qu'une bonne part de l'administration d'un dépôt CVS est effectuée manuellement,
belaran@964 654 et est donc, sujette à erreur, il est courant que les imports CVS rencontrent
belaran@964 655 de nombreux problèmes avec les dépôt corrompus (des \textit{timestamps}
belaran@964 656 de révision complètement buggés et des fichiers verrouillés depuis des années
belaran@964 657 sont deux des problèmes les moins intéressants dont je me souvienne).
belaran@964 658 </para>
belaran@964 659
belaran@964 660 <para>Mercurial peut importer l'historique depuis un dépôt CVS.
belaran@964 661 </para>
belaran@964 662
belaran@964 663 </sect2>
belaran@964 664 <sect2>
belaran@964 665 <title>Outils propriétaires</title>
belaran@964 666
belaran@964 667 <para>Perforce a une architecture client/serveur centralisée, sans aucun
belaran@964 668 mécanisme de mise en cache de données coté client. Contrairement à la plupart
belaran@964 669 des outils modernes de gestion de source, Perforce exige de ses
belaran@964 670 utilisateurs d'exécuter une commande pour informer le serveur
belaran@964 671 central de tout fichier qu'ils souhaitent modifier.
belaran@964 672 </para>
belaran@964 673
belaran@964 674 <para>Les performances de Perforce sont plutôt bonnes pour des petites
belaran@964 675 équipes, mais elles s'effondrent rapidement lorsque le nombre
belaran@964 676 d'utilisateurs augmente au delà de la douzaine. Des installations
belaran@964 677 de Perforce assez larges nécessitent le déploiement de proxies pour
belaran@964 678 supporter la montée en charge associée.
belaran@964 679 </para>
belaran@964 680
belaran@964 681 </sect2>
belaran@964 682 <sect2>
belaran@964 683 <title>Choisir un outil de gestion de source</title>
belaran@964 684
belaran@964 685 <para>A l'exception de CVS, tous les outils listés ci-dessus ont des
belaran@964 686 forces qui leur sont propres et qui correspondent à certaines
belaran@964 687 formes de projet. Il n'y a pas un seul meilleur outil de gestion
belaran@964 688 de source qui correspondrait le mieux à toutes les situations.
belaran@964 689 </para>
belaran@964 690
belaran@964 691 <para>Par exemple, Subversion est un très bon choix lorsqu'on travaille
belaran@964 692 avec beaucoup de fichiers binaires, qui évoluent régulièrement, grâce
belaran@964 693 à sa nature centralisée et sa capacité à verrouiller des fichiers.
belaran@964 694 </para>
belaran@964 695
belaran@964 696 <para>Personnellement, je préfère Mercurial pour sa simplicité, ses
belaran@964 697 performances et sa bonne capacité de fusion, et il m'a très bien rendu service
belaran@964 698 de plusieurs années maintenant.
belaran@964 699 </para>
belaran@964 700
belaran@964 701 </sect2>
belaran@964 702 </sect1>
belaran@964 703 <sect1>
belaran@964 704 <title>Migrer depuis un outil à Mercurial</title>
belaran@964 705
belaran@964 706 <para>Mercurial est livré avec une extension nommée <literal role="hg-ext">convert</literal>, qui
belaran@964 707 peut de manière incrémentale importer des révisions depuis différents
belaran@964 708 autres outils de gestion de source. Par <quote>incrémental</quote>, j'entends que
belaran@964 709 vous pouvez convertir l'historique entier du projet en une seule fois,
belaran@964 710 puis relancer l'outil d'import plus tard pour obtenir les modifications
belaran@964 711 effectuées depuis votre import initial.
belaran@964 712 </para>
belaran@964 713
belaran@964 714 <para>Les outils de gestion de source supportés par <literal role="hg-ext">convert</literal> sont :
belaran@964 715 </para>
belaran@964 716 <itemizedlist>
belaran@964 717 <listitem><para> \item Subversion
belaran@964 718 \item CVS
belaran@964 719 \item Git
belaran@964 720 \item Darcs
belaran@964 721 </para>
belaran@964 722 </listitem></itemizedlist>
belaran@964 723
belaran@964 724 <para>En outre, <literal role="hg-ext">convert</literal> peut exporter les modifications depuis Mercurial
belaran@964 725 vers Subversion. Ceci rend possible d'essayer Subversion en parallèle
belaran@964 726 avant de choisir une solution définitive, sans aucun risque de perte de
belaran@964 727 données.
belaran@964 728 </para>
belaran@964 729
belaran@964 730 <para>La commande <command role="hg-ext-conver">convert</command> est très simple à utiliser. Simplement,
belaran@964 731 indiquez le chemin ou l'URL du dépôt de source, en lui indiquant éventuellement
belaran@964 732 le nom du chemin de destination, et la conversion se met en route. Après cet
belaran@964 733 import initial, il suffit de relancer la commande encore une fois pour
belaran@964 734 importer les modifications effectuées depuis.
belaran@964 735 </para>
belaran@964 736
belaran@964 737 </sect1>
belaran@964 738 </chapter>
belaran@964 739
belaran@964 740 <!--
belaran@964 741 local variables:
belaran@964 742 sgml-parent-document: ("00book.xml" "book" "chapter")
belaran@964 743 end:
belaran@964 744 -->