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