hgbook
view fr/ch01-intro.xml @ 1030:2ac31ea48a3d
merge with trunk
| author | Romain PELISSE <belaran@gmail.com> |
|---|---|
| date | Thu Apr 22 12:39:32 2010 +0200 (2010-04-22) |
| parents | 0298bccbb8ee |
| children |
line source
1 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
3 <chapter id="chap:intro">
4 <?dbhtml filename="how-did-we-get-here.html"?>
5 <title>Comment en est-on arrivé là ?</title>
7 <sect1>
8 <title>À propos de la gestion de révisions. Pourquoi Mercurial ?</title>
10 <para id="x_6d">La gestion de révisions 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 id="x_6e">Ce genre de gestion de révisions manuelle, ne serait-ce que
17 d'un seul fichier, est cependant facilement sujette
18 aux erreurs, ainsi, depuis longtemps, des logiciels existent pour
19 résoudre cette problématique. Les premiers outils de gestion de révisions
20 étaient destinés à aider un seul utilisateur, à automatiser la gestion
21 des versions d'un seul fichier. Durant les dernières décennies, cette cible
22 s'est largement agrandie, ils gèrent désormais de multiples fichiers, et
23 aident un grand nombre de personnes à travailler ensemble. Les outils les
24 plus modernes n'ont aucune difficulté à gérer plusieurs milliers de
25 personnes travaillant ensemble sur des projets regroupant plusieurs
26 centaines de milliers de fichiers.</para>
28 <para id="x_6f">L'arrivée de la gestion de révisions distribuée est
29 relativement récente, et, pour le moment, ce nouveau domaine a grandi
30 grâce à la volonté des gens d'explorer ces territoires encore inconnus.
31 </para>
33 <para id="x_70">J'écris un livre sur la gestion de révisions distribuée
34 parce que je pense qu'il s'agit d'un sujet important qui mérite un guide
35 de terrain. J'ai choisi d'écrire un livre sur Mercurial car il est
36 l'outil le plus facile pour découvrir ce nouveau domaine, tout en étant
37 un outil efficace qui répond aux demandes d'environnements réels et
38 difficiles, là où d'autres outils de gestion de révisions s'effondrent.</para>
40 <sect2>
41 <title>Pourquoi utiliser un gestionnaire de révisions ?</title>
43 <para id="x_71">Il y a de nombreuses raisons pour que vous ou votre équipe souhaitiez
44 utiliser un outil automatisant la gestion de révisions pour votre projet.</para>
46 <itemizedlist>
47 <listitem><para id="x_72">L'outil se chargera de suivre l'évolution de votre projet, sans
48 que vous ayez à le faire. Pour chaque modification, vous aurez à votre
49 disposition un journal indiquant <emphasis>qui</emphasis> a fait quoi, <emphasis>pourquoi</emphasis>
50 il l'a fait, <emphasis>quand</emphasis> il l'a fait, et
51 <emphasis>ce</emphasis> qu'il a modifié.</para>
52 </listitem>
53 <listitem><para id="x_73">Quand vous travaillez avec d'autres personnes, les logiciels de
54 gestion de révisions facilitent le travail collaboratif. Par exemple, quand
55 plusieurs personnes font, plus ou moins simultanément, des modifications
56 incompatibles, le logiciel vous aidera à identifier et à résoudre les conflits.</para>
57 </listitem>
58 <listitem><para id="x_74">L'outil vous aidera à réparer vos erreurs. Si vous effectuez un changement
59 qui se révèle être une erreur, vous pourrez revenir à une version
60 antérieure d'un fichier ou même d'un ensemble de fichiers. En fait, un outil de
61 gestion de révisions <emphasis>vraiment</emphasis> efficace vous permettra d'identifier à quel
62 moment le problème est apparu (voir la section <xref linkend="sec:undo:bisect"/> pour plus
63 de détails).</para>
64 </listitem>
65 <listitem><para id="x_75">L'outil vous permettra aussi de travailler sur plusieurs versions différentes
66 de votre projet et de gérer l'écart entre chacune.</para>
67 </listitem></itemizedlist>
68 <para id="x_76">La plupart de ces raisons ont autant d'importances &emdash;du
69 moins en théorie&emdash; que vous travailliez seul sur un projet, ou
70 avec une centaine d'autres personnes.
71 </para>
73 <para id="x_77">Une question fondamentale à propos des outils de gestion de
74 révisions, qu'il s'agisse du projet d'une personne ou d'une grande équipe, est
75 quels sont ses <emphasis>gains</emphasis> par rapport à ses
76 <emphasis>coûts</emphasis>. Un outil qui est difficile à utiliser ou à
77 comprendre exigera un lourd effort d'adaptation.
78 </para>
80 <para id="x_78">Un projet de cinq mille personnes s'effondrera très
81 certainement de lui même sans aucun processus et outil de gestion de
82 révisions. Dans ce cas, le coût d'utilisation d'un logiciel de gestion de
83 révisions est dérisoire puisque <emphasis>sans</emphasis> celui-ci, l'échec est presque
84 garanti.
85 </para>
87 <para id="x_79">D'un autre coté, un <quote>rapide hack</quote> d'une personne
88 peut sembler un contexte bien pauvre pour utiliser un outil de gestion de
89 révisions, car, bien évidement le coût d'utilisation dépasse le coût total du
90 projet. N'est-ce pas ?
91 </para>
93 <para id="x_7a">Mercurial supporte ces <emphasis>deux</emphasis>
94 échelles de travail. Vous pouvez apprendre les bases en quelques
95 minutes seulement, et, grâce à sa performance, vous pouvez l'utiliser
96 avec facilité sur le plus petit des projets. Cette simplicité
97 signifie que vous n'avez pas de concept obscur ou de séquence de
98 commandes défiant l'imagination, sans aucune corrélation avec
99 ce que vous êtes <emphasis>réellement</emphasis> en train de faire. En même
100 temps, ses mêmes performances et sa nature
101 <quote>peer-to-peer</quote> vous permettent d'adapter, sans
102 difficulté, son utilisation à de très grands projets.
103 </para>
105 <para id="x_7b">Aucun outil de gestion de révisions ne peut sauver un
106 projet mal mené, mais un bon outil peut rendre beaucoup plus fluide
107 votre travail.
108 </para>
110 </sect2>
112 <sect2>
113 <title>Les multiples noms de la gestion de source</title>
115 <para id="x_7c">La gestion de source
116 <!-- TODO:<footnote><J'ai utilisé systématiquement le terme
117 <quote>gestion de révisions</quote> à travers tout l'ouvrage. Ce
118 n'est pas forcement la meilleure traduction, et ceci peut rendre
119 la lecture un peu lourde, mais je pense que le document y gagne
120 en clarté et en précision. -->
121 est un domaine tellement large qu'il n'existe pas qu'un seul nom ou
122 acronyme pour le désigner. Voici quelques noms ou acronymes que vous
123 rencontrerez le plus souvent.
124 <!-- TODO:<footnote> J'ai conservé la liste des noms en anglais pour
125 des raisons de commodité (ils sont plus <quote>googelable</quote>).
126 En outre, j'ai opté pour conserver l'ensemble des opérations de
127 Mercurial (\textit{commit},\textit{push}, \textit{pull},...) en
128 anglais, là aussi pour faciliter la lecture d'autres documents en
129 anglais, ainsi que l'utilisation de Mercurial. -->
130 </para>
132 <para>:
133 </para>
135 <itemizedlist>
136 <listitem><para id="x_7d">Revision control (RCS)</para></listitem>
137 <listitem><para id="x_7e">Software configuration management (SCM), ou
138 configuration management</para></listitem>
139 <listitem><para id="x_7f">Source code management</para></listitem>
140 <listitem><para id="x_80">Source code control, ou source control</para></listitem>
141 <listitem><para id="x_81">Version control (VCS)</para></listitem></itemizedlist>
143 <para id="x_82">Certaines personnes prétendent que ces termes ont en fait
144 des sens différents mais en pratique ils se recouvrent tellement qu'il n'y
145 a pas réellement de manière pertinente de les distinguer. </para>
147 </sect2>
148 </sect1>
150 <sect1>
152 <title>À propos des exemples dans ce livre</title>
154 <para id="x_84">Ce livre prend une approche non usuelle pour les exemples
155 de code. Tous les exemples sont en <quote>live</quote> &emdash; chacun
156 est actuellement le résultat d'un script shell qui exécute les
157 commandes Mercurial que vous voyez. Chaque fois qu'une image du livre
158 est construite à partir des sources, tous les scripts d'exemples sont
159 lancés automatiquement, et leurs résultats effectifs sont comparés aux
160 résultats attendus.</para>
162 <para id="x_85">L'avantage de cette approche est que les exemples sont
163 toujours précis ; ils décrivent <emphasis>exactement</emphasis> la
164 comportement de la version de Mercurial qui est mentionnée en entête du
165 livre. Si je mets à jour la version de Mercurial que je suis en train de
166 documenter, et que la sortie de certaines commandes change, la
167 construction du livre échoue.</para>
169 <para id="x_86">
170 Il existe un petit désavantage à cette approche qui est que les dates et
171 heures que vous verrez dans les exemples tendent à être
172 <quote>écrasés</quote> ensemble, dans le sens où elles ne sont pas
173 celles qu'elles auraient été si un humain avait tapé les commandes. En
174 effet, un humain ne peut pas taper plus d'une commande toutes les quelques
175 secondes, avec le temps qui s'écoule, mes scripts d'exemples exécutent
176 plusieurs commandes en une seconde.
177 </para>
179 <para id="x_87">Comme exemple de ceci, plusieurs commits
180 consécutifs dans un exemple peuvent apparaître comme ayant eu lieu
181 durant la même seconde.
182 Vous pouvez observer le phénomène dans l'exemple <literal
183 role="hg-ext">bisect</literal> dans <xref linkend="sec:undo:bisect"/>
184 </para>
186 <para id="x_88">Donc, lorsque vous lisez ces exemples, ne prêtez pas trop
187 d'importance aux dates et heures que vous voyez dans la sortie des
188 commandes. Cependant, <emphasis>soyez</emphasis> confiants que le
189 comportement que vous voyez est cohérent et reproductible.
190 </para>
192 </sect1>
194 <!-- The next section has disapper from this part of the book. it may be splaced somewhere else... t-->
196 <sect1>
197 <title>Tendances de la gestion de révisions</title>
199 <para id="x_89">Il y a eu une tendance évidente dans le développement et
200 l'utilisation d'outils de gestion de source depuis les quatre dernières
201 décennies, au fur et à mesure que les utilisateurs se sont habitués à
202 leur outils et se sont sentis contraints par leurs limitations.
203 </para>
205 <para id="x_8a">La première génération commença simplement par gérer un
206 fichier unique sur un ordinateur individuel. Cependant, même si ces
207 outils présentaient une grande avancée par rapport à la gestion
208 manuelle des versions, leur modèle de verrouillage et leur utilisation
209 limitée à un seul ordinateur rendaient leur utilisation possible
210 uniquement dans une très petite équipe.
211 </para>
213 <para id="x_8b">La seconde génération a assoupli ces contraintes en
214 adoptant une architecture réseau et centralisée, permettant de gérer
215 plusieurs projets entiers en même temps. Alors que les projets
216 grandirent en taille, ils rencontrèrent de nouveaux problèmes. Avec les
217 clients discutant régulièrement avec le serveur, la montée en charge
218 devint un réel problème sur les gros projets. Une connexion réseau peu
219 fiable pouvait complètement empêcher les utilisateurs distants de
220 dialoguer avec le serveur. Alors que les projets <emphasis
221 remap="it">Open Source</emphasis> commencèrent à mettre en place des
222 accès en lecture seule disponible anonymement, les utilisateurs sans
223 les privilèges de <quote>commit</quote> réalisèrent qu'ils ne pouvaient
224 pas utiliser les outils pour collaborer naturellement avec le projet,
225 comme ils ne pouvaient pas non plus enregistrer leurs modifications.
226 </para>
228 <para id="x_8c">La génération actuelle des outils de gestion de révisions
229 est <quote>peer-to-peer</quote> par nature. Tous ces systèmes ont
230 abandonné la dépendance à un serveur central, et ont permis à leurs
231 utilisateurs de distribuer les données de leur gestion de révisions à qui
232 en a besoin. La collaboration à travers Internet a transformé la
233 contrainte technologique en une simple question de choix et de
234 consensus. Les outils modernes peuvent maintenant fonctionner en mode
235 déconnecté sans limite et de manière autonome, la connexion au réseau
236 n'étant nécessaire que pour synchroniser les modifications avec les
237 autres dépôts.
238 </para>
239 </sect1>
241 <sect1>
242 <title>Quelques avantages des gestionnaires de révisions distribués</title>
244 <para id="x_8d">Même si les gestionnaire de révisions distribués sont depuis
245 plusieurs années assez robustes et aussi utilisables que leurs
246 prédécesseurs, les utilisateurs d'autres outils n'y ont pas encore été
247 sensibilisés. Les gestionnaires de révisions distribués se distinguent
248 particulièrement de leurs équivalents centralisés de nombreuses
249 manières.
250 </para>
252 <para id="x_8e">Pour un développeur individuel, ils restent beaucoup plus
253 rapides que les outils centralisés. Cela pour une raison simple : un
254 outil centralisé doit toujours dialoguer à travers le réseau pour la
255 plupart des opérations, car presque toutes les métadonnées sont
256 stockées sur la seule copie du serveur central. Un outil distribué
257 stocke toute ses métadonnées localement. À tâche égale, effectuer un
258 échange avec le réseau ajoute un délai aux outils centralisés. Ne
259 sous-estimez pas la valeur d'un outil rapide : vous allez passer
260 beaucoup de temps à interagir avec un logiciel de gestion de révisions.
261 </para>
263 <para id="x_8f">Les outils distribués sont complètement indépendants des
264 aléas de votre serveur, d'autant plus qu'ils répliquent les métadonnées
265 à beaucoup d'endroits. Si votre serveur central prend feu, vous avez
266 intérêt à ce que les médias de sauvegardes soient fiables, et que votre
267 dernier <quote>backup</quote> soit récent et fonctionne sans problème.
268 Avec un outil distribué, vous avez autant de <quote>backups</quote> que
269 de contributeurs.
270 </para>
272 <para id="x_90">En outre, la fiabilité de votre réseau affectera beaucoup
273 moins les outils distribués. Vous ne pouvez même pas utiliser un outil
274 centralisé sans connexion réseau, à l'exception de quelques commandes,
275 très limitées. Avec un outil distribué, si votre connexion réseau tombe
276 pendant que vous travaillez, vous pouvez ne même pas vous en rendre
277 compte. La seule chose que vous ne serez pas capable de faire sera de
278 communiquer avec des dépôts distants, opération somme toute assez rare
279 en comparaison des opérations locales. Si vous avez une équipe de
280 collaborateurs très dispersée ceci peut être significatif.
281 </para>
283 <sect2>
284 <title>Avantages pour les projets Open Source</title>
286 <para id="x_91">Si vous prenez goût à un projet <emphasis
287 remap="it">Open Source</emphasis> et que vous décidez de commencer
288 à toucher à son code, et que le projet utilise un gestionnaire de
289 révisions distribué, vous êtes immédiatement un "pair" avec les
290 personnes formant le <quote>cœur</quote> du projet. S'ils publient
291 leurs dépôts, vous pouvez immédiatement copier leurs historiques de
292 projet, faire des modifications, enregistrer votre travail en
293 utilisant les mêmes outils qu'eux. Par comparaison avec un outil
294 centralisé, vous devez utiliser un logiciel en mode <quote>lecture
295 seule</quote> à moins que quelqu'un ne vous donne les privilèges de
296 <quote>commit</quote> sur le serveur central. Avant ça, vous ne serez
297 pas capable d'enregistrer vos modifications, et vos propres
298 modifications risqueront de se corrompre chaque fois que vous
299 essayerez de mettre à jour à votre espace de travail avec le serveur
300 central.
301 </para>
303 <sect3>
304 <title>Le non-problème du "fork"</title>
306 <para id="x_92">Il a été souvent suggéré que les gestionnaires de
307 révisions distribués posent un risque pour les projets <emphasis
308 remap="it">Open Source</emphasis> car ils facilitent grandement la
309 création de <quote>fork</quote>.
310 <!--footnote{NdT:Création d'une <ulink url="version alternative du
311 logiciel">version alternative du
312 logiciel</ulink>{http://fr.wikipedia.org/wiki/Fork#Embranchement_d.27un_projet_informatique}
313 -->
314 Un <quote>fork</quote> apparait quand il y des divergences d'opinion
315 ou d'attitude au sein d'un groupe de développeurs qui aboutissent à
316 la décision de ne plus travailler ensemble. Chaque parti s'empare
317 d'une copie plus ou moins complète du code source du projet et
318 continue dans sa propre direction.
319 </para>
322 <para id="x_93">Parfois ces différents partis décident de se
323 réconcilier. Avec un serveur central, l'aspect
324 <emphasis>technique</emphasis> de cette réconciliation est un
325 processus douloureux, et essentiellement manuel. Vous devez décider
326 quelle modification est <quote>la gagnante</quote>, et replacer, par
327 un moyen ou un autre, les modifications de l'autre équipe dans
328 l'arborescence du projet. Ceci implique généralement la perte d'une
329 partie de l'historique d'un des partis, ou même des deux.
330 </para>
332 <para id="x_94">Ce que les outils distribués permettent à ce sujet est
333 probablement la <emphasis>meilleure</emphasis> façon de développer un
334 projet. Chaque modification que vous effectuez est potentiellement un
335 <quote>fork</quote>. La grande force de cette approche est que les
336 gestionnaires de révisions distribués doivent être vraiment très
337 efficaces pour <emphasis>fusionner (merge)</emphasis>
338 <!-- TODO footnote{NdT:j'ai choisi de traduire ici <emphasis
339 remap="it">merging</emphasis> par <quote>fusionner</quote> pour des
340 raisons de clarté} -->
341 des <quote>forks</quote>, car les <quote>forks</quote>, dans ce
342 contexte, arrivent tout le temps.
343 </para>
345 <para id="x_95">Si chaque altération que n'importe qui effectue, à tout
346 moment, est vue comme un <quote>fork</quote> à fusionner, alors ce
347 que le monde de l'<emphasis remap="it">Open Source</emphasis> voit
348 comme un <quote>fork</quote> devient <emphasis>uniquement</emphasis>
349 une problématique sociale. En fait, les outils de gestions de révisions
350 distribués <emphasis>réduisent</emphasis> les chances de
351 <quote>fork</quote> :
352 </para>
354 <itemizedlist>
355 <listitem>
356 <para>Ils éliminent la distinction sociale qu'imposent les outils
357 centralisés entre les membres du projets (ceux qui ont accès au
358 <quote>commit</quote>) et ceux de l'extérieur (qui ne l'ont
359 pas).
360 </para>
361 <para>Ils rendent plus facile la réconciliation après un
362 <quote>fork</quote> social, car tout ce qu'elle implique est une
363 simple fusion.
364 </para>
365 </listitem>
366 </itemizedlist>
368 <para id="x_98">Certaines personnes font de la résistance envers les
369 gestionnaires de révisions distribués parce qu'ils veulent garder un
370 contrôle ferme sur leur projet, et ils pensent que les outils
371 centralisés leur fournissent ce contrôle. Néanmoins, si c'est votre
372 cas, sachez que si vous publiez votre dépôt CVS ou Subversion de
373 manière publique, il existe une quantité d'outils disponibles pour
374 récupérer entièrement votre projet et son historique (quoique
375 lentement) et le récréer ailleurs, sans votre contrôle. En fait,
376 votre contrôle sur votre projet est illusoire, vous ne faites
377 qu'interdire à vos collaborateurs de travailler de manière fluide, en
378 disposant d'un miroir ou d'un <quote>fork</quote> de votre
379 historique.
380 </para>
382 </sect3>
383 </sect2>
384 <sect2>
385 <title>Avantages pour les projets commerciaux</title>
387 <para id="x_99">Beaucoup de projets commerciaux sont réalisés par des
388 équipes éparpillées à travers le globe. Les contributeurs qui sont
389 loin du serveur central devront subir des commandes lentes et même
390 parfois peu fiables. Les solutions propriétaires de gestion de révisions
391 tentent de palier ce problème avec des réplications de sites distants
392 qui sont à la fois coûteuses à mettre en place et lourdes à
393 administrer. Un système distribué ne souffre pas de ce genre de
394 problèmes. En outre, il est très aisé de mettre en place plusieurs
395 serveurs de références, disons un par site, de manière à ce qu'il n'y
396 ait pas de communication redondante entre les dépôts, sur une
397 connexion longue distance souvent onéreuse.
398 </para>
400 <para id="x_9a">Les systèmes de gestion de révisions supportent
401 généralement assez mal la montée en charge. Il n'est pas rare pour un
402 gestionnaire de révisions centralisé pourtant onéreux de s'effondrer
403 sous la charge combinée de quelques dizaines d'utilisateurs concurrents
404 seulement. Une fois encore, la réponse à cette problématique est
405 généralement encore la mise en place d'un ensemble complexe de
406 serveurs synchronisés par un mécanisme de réplication. Dans le cas
407 d'un gestionnaire de révisions distribué, la charge du serveur central
408 &emdash; si vous en avez un&emdash; est largement inférieure (car
409 toutes les données sont déjà répliquées ailleurs), un simple serveur,
410 peu onéreux, peut gérer les besoins d'une plus grande équipe, et la
411 réplication pour répartir la charge devient le travail d'un simple
412 script.
413 </para>
415 <para id="x_9b">Si vous avez des employés sur le terrain, en train de
416 chercher à résoudre un souci sur le site d'un client, ils
417 bénéficieront aussi d'un gestionnaire de révisions distribué. Cet outil
418 leur permettra de générer des versions personnalisées, d'essayer
419 différentes solutions, en les isolant aisément les unes des autres,
420 et de rechercher efficacement à travers l'historique des sources, la
421 cause des bugs ou des régressions, tout ceci sans avoir besoin de la
422 moindre connexion au réseau de votre société.
423 </para>
425 </sect2>
426 </sect1>
427 <sect1>
428 <title>Pourquoi choisir Mercurial?</title>
430 <para id="x_9c">Mercurial a plusieurs caractéristiques qui en font un
431 choix particulièrement pertinent pour la gestion de révisions :
432 </para>
433 <itemizedlist>
434 <listitem><para id="x_9d">Il est simple à apprendre et à utiliser.</para></listitem>
435 <listitem><para id="x_9e">Il est léger.</para></listitem>
436 <listitem><para id="x_9f">Il s'adapte très bien à la charge.</para></listitem>
437 <listitem><para id="x_a0">Il se personnalise facilement.</para></listitem>
438 </itemizedlist>
440 <para id="x_a1">Si vous êtes déjà familier d'un outil de gestion de
441 révisions, vous serez capable de l'utiliser en moins de 5 minutes. Sinon,
442 ça ne sera pas beaucoup plus long. Les commandes utilisées par
443 Mercurial, comme ses fonctionnalités, sont généralement uniformes et
444 cohérentes, et vous pouvez ainsi garder en tête simplement quelques
445 règles générales, plutôt que de nombreuses exceptions.
446 </para>
448 <para id="x_a2">Sur un petit projet, vous pouvez commencer à travailler
449 avec Mercurial en quelques instants. Ajouter des modifications ou des
450 branches, transférer ces modifications (localement ou via le réseau),
451 et les opérations d'historique ou de statut sont aussi très rapides.
452 Mercurial ne vous encombre pas grâce à sa simplicité
453 d'utilisation et sa rapidité d'exécution.
454 </para>
456 <para id="x_a3">L'utilité de Mercurial ne se limite pas à de petits
457 projets : il est aussi utilisé par des projets ayant des centaines ou
458 même des milliers de contributeurs, avec plusieurs dizaines de milliers
459 de fichiers, et des centaines de méga octets de code source.
460 </para>
462 <para id="x_a4">Si les fonctionnalités au cœur de Mercurial ne sont pas
463 suffisantes pour vous, il est très aisé d'en construire d'autres.
464 Mercurial est adapté à l'utilisation de scripts, et son implémentation
465 interne en Python, propre et claire, rend encore plus facile l'ajout de
466 fonctionnalités sous forme d'extensions. Il en existe déjà un certain
467 nombre de très populaires et très utiles, dont le périmètre va de la
468 recherche de bugs à l'amélioration des performances.
469 </para>
471 </sect1>
472 <sect1>
473 <title>Mercurial comparé aux autres outils</title>
475 <para id="x_a5">Avant que vous n'alliez plus loin, comprenez bien que
476 cette section reflète mes propres expériences, et elle est donc (j'ose
477 le dire) peu objective. Néanmoins, j'ai utilisé les outils de gestion
478 de source listés ci dessous, dans la plupart des cas, pendant plusieurs
479 années.
480 </para>
482 <sect2>
483 <title>Subversion</title>
485 <para id="x_a6">Subversion est un des outils de gestion de révisions les
486 plus populaire, développé pour remplacer CVS. Il a une
487 architecture client/serveur centralisée.
488 </para>
490 <para id="x_a7">Subversion et Mercurial ont des noms de commandes très
491 similaires pour les mêmes opérations, ainsi si vous êtes familier
492 avec l'un, c'est facile d'apprendre l'autre. Ces deux outils sont
493 portables sur tous les systèmes d'exploitation populaires.
494 </para>
496 <para id="x_a8">Avant la version 1.5, Subversion n'offrait aucune forme
497 de support pour les fusions. Lors de l'écriture de ce livre, ses
498 capacités de fusion étaient nouvelles, et réputées pour être <ulink
499 url="http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword">
500 complexes et buguées</ulink>.
501 </para>
503 <para id="x_a9">Mercurial dispose d'un avantage substantiel en terme de
504 performance par rapport à Subversion sur la plupart des opérations
505 que j'ai pu tester. J'ai mesuré une différence de performance allant
506 de deux à six fois plus rapide avec le système de stockage de fichier
507 local de Subversion 1.4.3 (<emphasis>ra_local</emphasis>), qui est la
508 méthode d'accès la plus rapide disponible. Dans un déploiement plus
509 réaliste, impliquant un stockage réseau, Subversion serait encore
510 plus désavantagé. Parce que la plupart des commandes Subversion
511 doivent communiquer avec le serveur et que Subversion n'a pas de
512 mécanisme de réplication, la capacité du serveur et la bande passante
513 sont devenues des goulots d'étranglement pour les projets de taille
514 moyenne ou grande.
515 </para>
517 <para id="x_aa">En outre, Subversion implique une surcharge
518 substantielle dans le stockage local de certaines données, pour
519 éviter des transactions avec le serveur, pour certaines opérations
520 communes, telles que la recherche des fichiers modifiés
521 (<literal>status</literal>) et l'affichage des modifications par
522 rapport à la révision courante (<literal>diff</literal>). En
523 conséquence, un répertoire de travail Subversion a souvent la même
524 taille, ou est plus grand, qu'un dépôt Mercurial et son espace de
525 travail, et ceci bien que le dépôt Mercurial contienne l'intégralité
526 de l'historique.
527 </para>
529 <para id="x_ab">Subversion est largement supporté par les outils
530 tiers. Mercurial est actuellement encore en retrait de ce point de
531 vue. L'écart se réduit néanmoins, en effet, certains des outils
532 graphiques sont maintenant supérieurs à leurs équivalents Subversion.
533 Comme Mercurial, Subversion dispose d'un excellent manuel
534 utilisateur.
535 </para>
537 <para id="x_ac">Parce que Subversion ne stocke pas l'historique chez
538 ses clients, il est parfaitement adapté à la gestion de projets qui
539 doivent suivre un ensemble de larges fichiers binaires et opaques. Si
540 vous suivez une cinquantaine de versions d'un fichier incompressible
541 de 10MB, l'occupation disque coté client d'un projet sous Subversion
542 restera à peu près constante. À l'inverse, l'occupation disque du
543 même projet sous n'importe lequel des gestionnaires de révisions
544 distribués grandira rapidement, proportionnellement aux nombres de
545 versions, car les différences entre chaque révision seront très
546 grandes.
547 </para>
549 <para id="x_ad">En outre, c'est souvent difficile ou, généralement,
550 impossible de fusionner des différences dans un fichier binaire. La
551 capacité de Subversion de verrouiller des fichiers, pour permettre à
552 l'utilisateur d'être le seul à le mettre à jour
553 (<quote>commit</quote>) temporairement, est un avantage significatif
554 dans un projet doté de beaucoup de fichiers binaires.
555 </para>
557 <para id="x_ae">Mercurial peut importer l'historique depuis un dépôt
558 Subversion. Il peut aussi exporter l'ensemble des révisions d'un
559 projet vers un dépôt Subversion. Ceci rend très facile de
560 <quote>prendre la température</quote> et d'utiliser Mercurial et
561 Subversion en parallèle, avant de décider de migrer vers Mercurial.
562 La conversion de l'historique est incrémentale, donc vous pouvez
563 effectuer une conversion initiale, puis de petites additions par la
564 suite pour ajouter les nouvelle modifications.
565 </para>
568 </sect2>
569 <sect2>
570 <title>Git</title>
572 <para id="x_af">Git est un outil de gestion de révisions distribué qui a été
573 développé pour gérer le code source de noyau de Linux. Comme
574 Mercurial, sa conception initiale a été inspirée par Monotone.
575 </para>
577 <para id="x_b0">Git dispose d'un ensemble conséquent de commandes, avec
578 plus de 139 commandes individuelles pour la version 1.5.0. Il a aussi
579 la réputation d'être difficile à apprendre. Comparé à Git, le point
580 fort de Mercurial est clairement sa simplicité.
581 </para>
583 <para id="x_b1">En terme de performance, Git est extrêmement rapide.
584 Dans la plupart des cas, il est plus rapide que Mercurial, tout du
585 moins sur Linux, alors que Mercurial peut être plus performant sur
586 d'autres opérations. Néanmoins, sur Windows, les performances et le
587 niveau de support général fourni par Git, au moment de l'écriture de
588 cet ouvrage, est bien derrière celui de Mercurial.
589 </para>
591 <para id="x_b2">Alors que le dépôt Mercurial ne demande aucune
592 maintenance, un dépôt Git exige d'exécuter manuellement et
593 régulièrement la commande <quote>repacks</quote> sur ses métadonnées.
594 Sans ceci, les performances de git se dégradent et la consommation de
595 l'espace disque augmente rapidement. Un serveur qui contient
596 plusieurs dépôts Git qui ne sont pas régulièrement et fréquemment
597 <quote>repacked</quote> deviendra un vrai problème lors des
598 <quote>backups</quote> du disque, et il y eu des cas, où un
599 <quote>backup</quote> journalier pouvait durer plus de 24 heures. Un
600 dépôt fraichement <quote>repacked</quote> sera légèrement plus petit
601 qu'un dépôt Mercurial, mais un dépôt non <quote>repacked</quote> est
602 beaucoup plus grand.
603 </para>
605 <para id="x_b3">Le cœur de Git est écrit en C. La plupart des commandes
606 Git sont implémentées sous forme de scripts Shell ou Perl, et la
607 qualité de ces scripts varie grandement. J'ai plusieurs fois constaté
608 que certains de ces scripts étaient chargés en mémoire aveuglément et
609 que la présence d'erreurs pouvait s'avérer fatale.
610 </para>
612 <para id="x_b4">Mercurial peut importer l'historique d'un dépôt Git.</para>
614 </sect2>
615 <sect2>
616 <title>CVS</title>
618 <para id="x_b5">CVS est probablement l'outil de gestion de révisions le
619 plus utilisé aujourd'hui dans le monde. À cause de son manque de
620 clarté interne, il n'est plus maintenu depuis plusieurs années.
621 </para>
623 <para id="x_b6">Il a une architecture client/serveur centralisée. Il ne
624 regroupe pas les modifications de fichiers dans une opération de
625 <quote>commit</quote> atomique, ce qui permet à ses utilisateurs de
626 <quote>casser le <emphasis>build</emphasis></quote> assez facilement :
627 une personne peut effectuer une opération de <quote>commit</quote>
628 sans problème puis être bloquée par besoin de fusion, avec comme
629 conséquence néfaste, que les autres utilisateurs ne récupèreront
630 qu'une partie de ses modifications. Ce problème affecte aussi la
631 manière de travailler avec l'historique du projet. Si vous voulez
632 voir toutes les modifications d'une personne du projet, vous devrez
633 injecter manuellement les descriptions et les <emphasis
634 remap="it">timestamps</emphasis> des modifications de chacun des
635 fichiers impliqués (si vous savez au moins quels sont ces fichiers).
636 </para>
638 <para id="x_b7">CVS a une notion étrange des <emphasis
639 remap="it">tags</emphasis> et des branches que je n'essayerai même
640 pas de décrire ici. Il ne supporte pas bien les opérations de
641 renommage d'un fichier ou d'un répertoire, ce qui facilite la
642 corruption de son dépôt. Il n'a presque pas pour ainsi dire de
643 contrôle de cohérence interne, il est donc pratiquement impossible de
644 dire si un dépôt est corrompu ni à quel point. Je ne recommanderai
645 pas CVS pour un projet existant ou nouveau.
646 </para>
648 <para id="x_b8">Mercurial peut importer l'historique d'un projet CVS.
649 Néanmoins, il y a quelques principes à respecter ; ce qui est vrai
650 aussi pour les autres outils d'import de projet CVS. À cause de
651 l'absence de <quote>commit</quote> atomique et gestion de versions de
652 l'arborescence, il n'est pas possible de reconstruire de manière
653 précise l'ensemble de l'historique. Un travail de
654 <quote>devinette</quote> est donc nécessaire, et les fichiers
655 renommés ne sont pas détectés. Parce qu'une bonne part de
656 l'administration d'un dépôt CVS est effectuée manuellement, et est
657 donc, sujette à erreur, il est courant que les imports CVS
658 rencontrent de nombreux problèmes avec les dépôt corrompus (des
659 <emphasis remap="it">timestamps</emphasis> de révision complètement
660 buggés et des fichiers verrouillés depuis des années sont deux des
661 problèmes les moins intéressants dont je me souvienne).
662 </para>
664 <para id="x_b9">Mercurial peut importer l'historique depuis un dépôt CVS.
665 </para>
668 </sect2>
669 <sect2>
670 <title>Outils propriétaires</title>
672 <para id="x_ba">Perforce a une architecture client/serveur centralisée,
673 sans aucun mécanisme de mise en cache de données côté client.
674 Contrairement à la plupart des outils modernes de gestion de révisions,
675 Perforce exige de ses utilisateurs d'exécuter une commande pour
676 informer le serveur central de tout fichier qu'ils souhaitent
677 modifier.
678 </para>
680 <para id="x_bb">Les performances de Perforce sont plutôt bonnes pour
681 des petites équipes, mais elles s'effondrent rapidement lorsque le
682 nombre d'utilisateurs augmente au delà de quelques dizaines. Des
683 installations de Perforce assez larges nécessitent le déploiement de
684 proxies pour supporter la montée en charge associée.
685 </para>
687 </sect2>
688 <sect2>
689 <title>Choisir un outil de gestion de révisions</title>
691 <para id="x_bc">À l'exception de CVS, tous les outils listés ci-dessus
692 ont des forces qui leurs sont propres et qui correspondent à certaines
693 formes de projet. Il n'y a pas un seul meilleur outil de gestion de
694 révisions qui correspondrait le mieux à toutes les situations.
695 </para>
697 <para id="x_bd">En guise exemple, Subversion est un très bon choix
698 lorsqu'on travaille avec beaucoup de fichiers binaires, qui évoluent
699 régulièrement, grâce à sa nature centralisée et sa capacité à
700 verrouiller des fichiers.
701 </para>
703 <para id="x_be">Personnellement, je préfère Mercurial pour sa
704 simplicité, ses performances et sa bonne capacité de fusion, et il
705 m'a très bien rendu service de plusieurs années maintenant.
706 </para>
708 </sect2>
709 </sect1>
710 <sect1>
711 <title>Migrer depuis un outil vers Mercurial</title>
713 <para id="x_bf">Mercurial est livré avec une extension nommée <literal
714 role="hg-ext">convert</literal>, qui peut, de manière incrémentale
715 importer des révisions depuis différents autres outils de gestion de
716 source. Par <quote>incrémental</quote>, j'entends que vous pouvez
717 convertir l'historique entier du projet en une seule fois, puis
718 relancer l'outil d'import plus tard pour obtenir les modifications
719 effectuées depuis votre import initial.
720 </para>
722 <para id="x_c0">Les outils de gestion de révisions supportés par <literal
723 role="hg-ext">convert</literal> sont :
724 </para>
725 <itemizedlist>
726 <listitem><para id="x_c1">Subversion</para></listitem>
727 <listitem><para id="x_c2">CVS</para></listitem>
728 <listitem><para id="x_c3">Git</para></listitem>
729 <listitem><para id="x_c4">Darcs</para></listitem>
730 </itemizedlist>
732 <para id="x_c5">En outre, <literal role="hg-ext">convert</literal> peut
733 exporter les modifications depuis Mercurial vers Subversion. Ceci rend
734 possible d'essayer Subversion en parallèle avant de choisir une
735 solution définitive, sans aucun risque de perte de données.
736 </para>
738 <para id="x_c6">La commande <command
739 role="hg-ext-conver">convert</command> est très simple à utiliser.
740 Simplement, indiquez le chemin ou l'URL du dépôt de source, en lui
741 indiquant éventuellement le nom du chemin de destination, et la
742 conversion se met en route. Après cet import initial, il suffit de
743 relancer la commande encore une fois pour importer les modifications
744 effectuées depuis.
745 </para>
746 </sect1>
748 <sect1>
749 <title>Une courte histoire de la gestion de révisions</title>
751 <para id="x_c7">Le plus célèbre des anciens outils de gestion de révisions
752 est <emphasis remap="it">SCCS</emphasis> (Source Code Control System)},
753 que Marc Rochkind conçu dans les laboratoires de recherche de Bell
754 (<emphasis remap="it">Bell Labs</emphasis>), dans le début des années
755 70. <emphasis remap="it">SCCS</emphasis> ne fonctionnait que sur des
756 fichiers individuels, et obligeait chaque personne travaillant sur le
757 projet d'avoir un accès à un répertoire de travail commun, sur le même
758 système. Seulement une seule personne pouvait modifier un fichier au
759 même moment, ce fonctionnement était assuré par l'utilisation de verrou
760 (<quote>lock</quote>). Il était courant que des personnes verrouillent
761 des fichiers, et plus tard, oublient de le déverrouiller ; empêchant
762 n'importe qui d'autre de travailler sur ces fichiers sans l'aide de
763 l'administrateur...
764 </para>
766 <para id="x_c8">Walter Tichy a développé une alternative libre à
767 <emphasis remap="it">SCCS</emphasis> au début des années 80, qu'il
768 nomma <emphasis remap="it">RCS (Revision Control System)</emphasis>.
769 Comme <emphasis remap="it">SCCS</emphasis>, <emphasis
770 remap="it">RCS</emphasis> demandait aux développeurs de travailler
771 sur le même répertoire partagé, et de verrouiller les fichiers pour se
772 prémunir de tout conflit issu de modifications concurrentes.
773 </para>
775 <para id="x_c9">Un peu plus tard dans les années 1980, Dick Grune utilisa
776 <emphasis remap="it">RCS</emphasis> comme une brique de base pour un
777 ensemble de scripts <emphasis remap="it">shell</emphasis> qu'il
778 intitula cmt, avant de la renommer en <emphasis remap="it">CVS
779 (Concurrent Versions System)</emphasis>. La grande innovation de CVS
780 était que les développeurs pouvaient travailler simultanément et
781 indépendamment dans leur propre espace de travail. Ces espaces de
782 travail privés assuraient que les développeurs ne se marchent pas
783 mutuellement sur les pieds, comme c'était souvent le cas avec RCS et
784 SCCS. Tous les développeurs disposaient donc de leur copie de tous les
785 fichiers du projet, et ils pouvaient donc librement les modifier. Ils
786 devaient néanmoins effectuer la <quote>fusion</quote> (<emphasis
787 remap="it"><quote>merge</quote></emphasis>) de leurs fichiers, avant
788 d'effectuer le <quote>commit</quote> de leurs modifications sur le dépôt
789 central.
790 </para>
792 <para id="x_ca">Brian Berliner reprit les scripts de Grune's et les réécrit en C,
793 qu'il publia en 1989. Depuis, ce code a été modifié jusqu'à devenir la
794 version moderne de CVS. CVS a acquis ainsi la capacité de fonctionner
795 en réseau, transformant son architecture en client/serveur.
796 L'architecture de CVS est centralisée, seul le serveur a une copie de
797 l'historique du projet. L'espace de travail client ne contient qu'une
798 copie de la dernière version du projet, et quelques métadonnées pour
799 indiquer où le serveur se trouve. CVS a été un grand succès,
800 aujourd'hui il est probablement l'outil de gestion de révisions le plus
801 utilisé au monde.
802 </para>
804 <para id="x_cb">Au début des années 1990, Sun Microsystems développa un premier
805 outil de gestion de révisions distribué, nommé TeamWare. Un espace de
806 travail TeamWare contient une copie complète de l'historique du projet.
807 TeamWare n'a pas de notion de dépôt central. (CVS utilisait RCS pour le
808 stockage de l'historique, TeamWare utilisait SCCS).
809 </para>
811 <para id="x_cc">Alors que les années 1990 avançaient, les utilisateurs ont pris
812 conscience d'un certain nombre de problèmes avec CVS. Il enregistrait
813 simultanément des modifications sur différents fichiers
814 individuellement, au lieu de les regrouper dans une seule opération
815 cohérente et atomique. Il ne gère pas bien sa hiérarchie de fichiers, il
816 est donc assez aisé de créer le chaos en renommant les fichiers et les
817 répertoires. Pire encore, son code source est difficile à lire et à
818 maintenir, ce qui augmente largement le <quote>niveau de
819 souffrance</quote> associé à la réparation de ces problèmes
820 d'architecture de manière prohibitive.
821 </para>
823 <para id="x_cd">En 2001, Jim Blandy et Karl Fogel, deux développeurs qui avaient
824 travaillé sur CVS, initièrent un projet pour le remplacer par un outil
825 qui aurait une meilleure architecture et un code plus propre. Le
826 résultat, Subversion, ne quitte pas le modèle centralisé et
827 client/serveur de CVS, mais ajoute les opérations de
828 <quote>commit</quote> atomique sur de multiples fichiers, une meilleure
829 gestion des espaces de noms, et d'autres fonctionnalités qui en font un
830 meilleur outil que CVS. Depuis sa première publication, il est
831 rapidement devenu très populaire.
832 </para>
834 <para id="x_ce">Plus ou moins simultanément, Graydon Hoare a commencé sur
835 l'ambitieux système de gestion distribuée Monotone. Bien que Monotone
836 corrige plusieurs défauts de CVS tout en offrant une architecture
837 <quote>peer-to-peer</quote>, il va aussi plus loin que la plupart des
838 outils de gestion de révisions de manière assez innovante. Il utilise des
839 <quote>hashs</quote> cryptographiques comme identifiants, et il a une
840 notion complète de <quote>confiance</quote> du code issu des
841 différentes sources.
842 </para>
844 <para id="x_cf">Mercurial est né en 2005. Bien que très influencé par Monotone,
845 Mercurial se concentre sur la facilité d'utilisation, les performances
846 et la capacité à monter en charge sur de très gros projets.
847 </para>
849 </sect1>
851 </chapter>
853 <!--
854 local variables:
855 sgml-parent-document: ("00book.xml" "book" "chapter")
856 end:
857 -->