hgbook
view fr/ch01-intro.xml @ 979:64475a75365b
Merged from rpelisse
| author | Jean-Marie Clément <JeanMarieClement@web.de> |
|---|---|
| date | Fri Sep 04 18:24:06 2009 +0200 (2009-09-04) |
| parents | 6b680d569bb4 |
| children | a9c3a727f253 |
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 source</title>
10 <para id="x_6d">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 id="x_6e">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 <para id="x_6f">L'arrivée de la gestion de révision distribuée est
28 relativement récente, et, pour le moment, ce nouveau domaine a grandi
29 grâce à la volonté des gens d'explorer ces territoires encores inconnues.
30 </para>
32 <para id="x_70">J'écris un livre sur la gestion de révision distribuée
33 parce que je pense qu'il s'agit d'un sujet important qui mérite un guide
34 du terrain. J'ai choisi d'écrire un livre sur Mercurial car il est
35 l'outil le plus facile pour découvrir ce nouveau domaine, tout en étant
36 un outil efficase qui répond aux demandes d'environement réel et
37 difficile, là où d'autres outils de révisions s'effondre.</para>
39 <sect2>
40 <title>Pourquoi utiliser un gestionnaire de source ?</title>
42 <para id="x_71">Il y a de nombreuses raisons pour que vous ou votre équipe souhaitiez
43 utiliser un outil automatisant la gestion de version pour votre projet.</para>
45 <itemizedlist>
46 <listitem><para id="x_72">L'outil se chargera de suivre l'évolution de votre projet, sans
47 que vous n'ayez à le faire. Pour chaque modification, vous aurez à votre
48 disposition un journal indiquant <emphasis>qui</emphasis> a fait quoi, <emphasis>pourquoi</emphasis>
49 ils l'ont fait, <emphasis>quand</emphasis> ils l'ont fait, et <emphasis>ce</emphasis> qu'ils ont
50 modifiés.</para>
51 </listitem>
52 <listitem><para id="x_73">Quand vous travaillez avec d'autres personnes, les logiciels de
53 gestion de source facilitent le travail collaboratif. Par exemple, quand
54 plusieurs personnes font, plus ou moins simultanément, des modifications
55 incompatibles, le logiciel vous aidera à identifier et à résoudre les conflits.</para>
56 </listitem>
57 <listitem><para id="x_74">L'outil vous aidera à réparer vos erreurs. Si vous effectuez un changement
58 qui se révèle être une erreur, vous pourrez revenir à une version
59 antérieure d'un fichier ou même d'un ensemble de fichiers. En fait, un outil de
60 gestion de source <emphasis>vraiment</emphasis> efficace vous permettra d'identifier à quel
61 moment le problème est apparu (voir la section <xref linkend="sec:undo:bisect"/> pour plus
62 de détails).</para>
63 </listitem>
64 <listitem><para id="x_75">L'outil vous permettra aussi de travailler sur plusieurs versions différentes
65 de votre projet et à gérer l'écart entre chacune.</para>
66 </listitem></itemizedlist>
67 <para id="x_76">La plupart de ces raisons ont autant d'importances &emdash;du moins en théorie&emdash; que
68 vous travailliez sur un projet pour vous, ou avec une centaine d'autres
69 personnes.
70 </para>
72 <para id="x_77">Une question fondamentale à propos des outils de gestion de source, qu'il s'agisse
73 du projet d'une personne ou d'une grande équipe, est quels sont ses
74 <emphasis>avantages</emphasis> par rapport à ses <emphasis>coûts</emphasis>. Un outil qui est difficile à
75 utiliser ou à comprendre exigera un lourd effort d'adaptation.
76 </para>
78 <para id="x_78">)Un projet de cinq milles personnes s'effondrera très certainement de lui même
79 sans aucun processus et outil de gestion de source. Dans ce cas, le coût
80 d'utilisation d'un logiciel de gestion de source est dérisoire puisque
81 <emphasis>sans</emphasis>, l'échec est presque garanti.
82 </para>
84 <para id="x_79">D'un autre coté, un <quote>rapide hack</quote> d'une personne peut sembler un contexte
85 bien pauvre pour utiliser un outil de gestion de source, car, bien évidement
86 le coût d'utilisation dépasse le coût total du projet. N'est ce pas ?
87 </para>
89 <para id="x_7a">Mercurial supporte ces <emphasis>deux</emphasis> échelles de travail. Vous pouvez apprendre
90 les bases en quelques minutes seulement, et, grâce à sa performance, vous pouvez
91 l'utiliser avec facilité sur le plus petit des projets. Cette simplicité
92 signifie que vous n'avez pas de concept obscurs ou de séquence de commandes
93 défiant l'imagination, sans aucune corrélation avec <emphasis>ce que vous
94 êtes entrain de faire</emphasis>. En même temps, ces mêmes performances et sa
95 nature <quote>peer-to-peer</quote> vous permettent d'augmenter, sans difficulté, son
96 utilisation à de très grands projets.
97 </para>
99 <para id="x_7b">Aucun outil de gestion de source ne peut sauver un projet mal mené, mais un
100 bon outil peut rendre beaucoup plus fluide votre travail.
101 </para>
103 </sect2>
105 <sect2>
106 <title>Les multiples noms de la gestion de source</title>
108 <para id="x_7c">La gestion de source<!--
109 TODO:<footnote><J'ai utilisé systématiquement le terme
110 <quote>gestion de source</quote> à travers tout l'ouvrage. Ce n'est pas forcement la
111 meilleure traduction, et ceci peut rendre la lecture un peu lourde, mais je
112 pense que le document y gagne en clarté et en précision. --> est un domaine
113 divers, tellement qu'il n'existe pas une seul nom ou acronyme pour le désigner.
114 Voilà quelqu'uns des noms ou
115 acronymes que vous rencontrerez le plus souvent <!-- TODO:<footnote> J'ai conservé la
116 liste des noms en anglais pour des raisons de commodité (ils sont plus
117 <quote>googelable</quote>). En outre, j'ai opté pour conserver l'ensemble des opérations de
118 Mercurial (\textit{commit},\textit{push}, \textit{pull},...) en anglais, là
119 aussi pour faciliter la lecture d'autres documents en anglais, ainsi que
120 l'utilisation de Mercurial. -->
121 </para>
123 <para>:
124 </para>
126 <itemizedlist>
127 <listitem><para id="x_7d">Revision control (RCS)</para></listitem>
128 <listitem><para id="x_7e">Software configuration management (SCM), or
129 configuration management</para></listitem>
130 <listitem><para id="x_7f">Source code management</para></listitem>
131 <listitem><para id="x_80">Source code control, or source
132 control</para></listitem>
133 <listitem><para id="x_81">Version control
134 (VCS)</para></listitem></itemizedlist>
136 <para id="x_82">Certaines personnes prétendent que ces termes ont en fait des sens
137 différents mais en pratique ils se recouvrent tellement qu'il n'y a pas
138 réellement de manière pertinente de les distinguer.
139 </para>
141 </sect2>
142 </sect1>
144 <sect1>
146 <title>About the examples in this book</title>
148 <para id="x_84">This book takes an unusual approach to code samples. Every
149 example is <quote>live</quote>&emdash;each one is actually the result
150 of a shell script that executes the Mercurial commands you see.
151 Every time an image of the book is built from its sources, all
152 the example scripts are automatically run, and their current
153 results compared against their expected results.</para>
155 <para id="x_85">The advantage of this approach is that the examples are
156 always accurate; they describe <emphasis>exactly</emphasis> the
157 behavior of the version of Mercurial that's mentioned at the
158 front of the book. If I update the version of Mercurial that
159 I'm documenting, and the output of some command changes, the
160 build fails.</para>
162 <para id="x_86">There is a small disadvantage to this approach, which is
163 that the dates and times you'll see in examples tend to be
164 <quote>squashed</quote> together in a way that they wouldn't be
165 if the same commands were being typed by a human. Where a human
166 can issue no more than one command every few seconds, with any
167 resulting timestamps correspondingly spread out, my automated
168 example scripts run many commands in one second.</para>
170 <para id="x_87">As an instance of this, several consecutive commits in an
171 example can show up as having occurred during the same second.
172 You can see this occur in the <literal
173 role="hg-ext">bisect</literal> example in <xref
174 linkend="sec:undo:bisect"/>, for instance.</para>
176 <para id="x_88">So when you're reading examples, don't place too much weight
177 on the dates or times you see in the output of commands. But
178 <emphasis>do</emphasis> be confident that the behavior you're
179 seeing is consistent and reproducible.</para>
181 </sect1>
183 <!-- The next section has disapper from this part of the book. it may be splaced somewhere else... t-->
185 <sect1>
186 <title>Tendances de la gestion de source</title>
188 <para id="x_89">Il y a eu une tendance évidente dans le développement et l'utilisation d'outils
189 de gestion de source depuis les quatre dernières décades, au fur et à mesure
190 que les utilisateurs se sont habitués à leur outils et se sont sentis contraints
191 par leurs limitations.
192 </para>
194 <para id="x_8a">La première génération commença simplement par gérer un fichier unique sur un
195 ordinateur individuel. Cependant, même si ces outils présentaient une grande
196 avancée par rapport à la gestion manuelle des versions, leur modèle de
197 verrouillage et leur utilisation limitée à un seul ordinateur rendaient leur
198 utilisation possible uniquement dans une très petite équipe.
199 </para>
201 <para id="x_8b">La seconde génération a assoupli ces contraintes en adoptant une architecture
202 réseau et centralisée, permettant de gérer plusieurs projets entiers en même
203 temps. Alors que les projets grandirent en taille, ils rencontrèrent de nouveaux
204 problèmes. Avec les clients discutant régulièrement avec le serveurs, la montée
205 en charge devint un réel problème sur les gros projets. Une connexion réseau
206 peu fiable pouvait complètement empêcher les utilisateurs distants de dialoguer
207 avec le serveur. Alors que les projets <emphasis remap="it">Open Source</emphasis> commencèrent à
208 mettre en place des accès en lecture seule disponible anonymement, les
209 utilisateurs sans les privilèges de <quote>commit</quote> réalisèrent qu'ils ne pouvaient
210 pas utiliser les outils pour collaborer naturellement avec le projet, comme ils
211 ne pouvaient pas non plus enregistrer leurs modifications.
212 </para>
214 <para id="x_8c">La génération actuelle des outils de gestion de source est <quote>peer-to-peer</quote> par
215 nature. Tout ces systèmes ont abandonné la dépendance à un serveur central, et
216 ont permis à leur utilisateur de distribuer les données de leur gestion de
217 source à qui en a besoin. La collaboration à travers Internet a transformé la
218 contrainte technologique en une simple question de choix et de consencus. Les
219 outils modernes peuvent maintenant fonctionner en mode déconnecté sans limite et
220 de manière autonome, la connexion au réseau n'étant nécessaire que pour
221 synchroniser les modifications avec les autres dépôts.
222 </para>
224 </sect1>
225 <sect1>
226 <title>Quelques avantages des gestionnaires de source distribués</title>
228 <para id="x_8d">Même si les gestionnaire de source distribués sont depuis plusieurs années
229 assez robustes et aussi utilisables que leurs prédécesseurs, les utilisateurs
230 d'autres outils n'y ont pas encore été sensibilisés. Les gestionnaires
231 de source distribués se distinguent particulièrement de leurs équivalents
232 centralisés de nombreuses manières.
233 </para>
235 <para id="x_8e">Pour un développeur individuel, ils restent beaucoup plus rapides que les
236 outils centralisés. Cela pour une raison simple : un outil centralisé doit
237 toujours dialoguer à travers le réseau pour la plupart des opérations, car
238 presque toutes les métadonnées sont stockées sur la seule copie du serveur
239 central. Un outil distribué stocke toute ses métadonnées localement. À tâche
240 égale, effectuer un échange avec le réseau ajoute un délai aux outils
241 centralisés. Ne sous-estimez pas la valeur d'un outil rapide : vous allez
242 passer beaucoup de temps à interagir avec un logiciel de gestion de source.
243 </para>
245 <para id="x_8f">Les outils distribués sont complètement indépendants des aléas de votre serveur,
246 d'autant plus qu'ils répliquent les métadonnées à beaucoup d'endroits. Si
247 votre serveur central prend feu, vous avez intérêt à ce que les médias de
248 sauvegardes soient fiables, et que votre dernier <quote>backup</quote> soit récent et
249 fonctionne sans problème. Avec un outil distribué, vous avez autant de
250 <quote>backup</quote> que de contributeurs.
251 </para>
253 <para id="x_90">En outre, la fiabilité de votre réseau affectera beaucoup moins les
254 outils distribués. Vous ne pouvez même pas utiliser un outil centralisé
255 sans connexion réseau, à l'exception de quelques commandes, très limitées.
256 Avec un outil distribué, si votre connexion réseau tombe pendant que vous
257 travaillez, vous pouvez ne même pas vous en rendre compte. La seule chose
258 que vous ne serez pas capable de faire sera de communiquer avec des dépôts
259 distants, opération somme toute assez rare en comparaison aux opérations
260 locales. Si vous avez une équipe de collaborateurs très dispersée ceci peut
261 être significatif.
262 </para>
265 <sect2>
266 <title>Avantages pour les projets Open Source</title>
268 <para id="x_91">Si vous prenez goût à un projet <emphasis remap="it">Open Source</emphasis> et que vous
269 décidez de commencer à toucher à son code, et que le projet utilise
270 un gestionnaire de source distribué, vous êtes immédiatement un "pair"
271 avec les personnes formant le <quote>cœur</quote> du projet. Si ils publient
272 leurs dépôts, vous pouvez immédiatement copier leurs historiques de
273 projet, faire des modifications, enregistrer votre travail en utilisant
274 les même outils qu'eux. Par comparaison, avec un outil centralisé, vous
275 devez utiliser un logiciel en mode <quote>lecture seule</quote> à moins que
276 quelqu'un ne vous donne les privilèges de <quote>commit</quote> sur le serveur
277 central. Avant ça, vous ne serez pas capable d'enregistrer vos
278 modifications, et vos propres modifications risqueront de se
279 corrompre chaque fois que vous essayerez de mettre à jour à votre
280 espace de travail avec le serveur central.
281 </para>
283 <sect3>
284 <title>Le non-problème du "fork"</title>
286 <para id="x_92">Il a été souvent suggéré que les gestionnaires de source distribués
287 posent un risque pour les projets <emphasis remap="it">Open Source</emphasis> car ils
288 facilitent grandement la création de <quote>fork</quote>.<!-- footnote{NdT:Création
289 d'une
290 <ulink url="version alternative du logiciel">version alternative du
291 logiciel</ulink>{http://fr.wikipedia.org/wiki/Fork#Embranchement_d.27un_projet_informatique}
292 -->
293 Un <quote>fork</quote> apparait quand il y des divergences d'opinion ou d'attitude
294 au sein d'un groupe de développeurs qui aboutissent à la décision de ne
295 plus travailler ensemble. Chaque parti s'empare d'une copie plus ou moins
296 complète du code source du projet et continue dans sa propre direction.
297 </para>
299 <para id="x_93">Parfois ces différents partis décident de se réconcilier. Avec un
300 serveur central, l'aspect <emphasis>technique</emphasis> de cette réconciliation
301 est un processus douloureux, et essentiellement manuel. Vous devez
302 décider quelle modification est <quote>la gagnante</quote>, et replacer, par un
303 moyen ou un autre, les modifications de l'autre équipe dans l'arborescence
304 du projet. Ceci implique généralement la perte d'une partie de l'historique
305 d'un des partis, ou même des deux.
306 </para>
308 <para id="x_94">Ce que les outils distribués permettent à ce sujet est probablement
309 la <emphasis>meilleure</emphasis> façon de développer un projet. Chaque modification
310 que vous effectuez est potentiellement un <quote>fork</quote>. La grande force de
311 cette approche est que les gestionnaires de source distribués doivent être
312 vraiment très efficaces pour <emphasis>fusionner</emphasis><!-- TODO footnote{NdT:j'ai choisi de
313 traduire ici <emphasis remap="it">merging</emphasis> par <quote>fusionner</quote> pour des raisons
314 de clarté} --> des <quote>forks</quote>, car les <quote>forks</quote>, dans ce contexte, arrivent
315 tout le temps.</para>
317 <para id="x_95">Si chaque altération que n'importe qui effectue, à tout moment, est vue
318 comme un <quote>fork</quote> à fusionner, alors ce que le monde de
319 l'<emphasis remap="it">Open Source</emphasis>
320 Source} voit comme un <quote>fork</quote> devient <emphasis>uniquement</emphasis> une problématique
321 sociale. En fait, les outils de gestions de source distribués <emphasis>réduisent</emphasis>
322 les chances de <quote>fork</quote>:
323 </para>
324 <itemizedlist>
325 <listitem>
326 <para>Ils éliminent la distinction sociale qu'imposent les outils centralisés
327 entre les membres du projets (ceux qui ont accès au <quote>commit</quote>) et ceux de
328 l'extérieur (ce qui ne l'ont pas).</para>
329 <para>rendent plus facile la réconciliation après un <quote>fork</quote> social, car tout ce
330 qu'elle implique est une simple fusion.</para>
331 </listitem>
332 </itemizedlist>
334 <para id="x_98">Certaines personnes font de la résistance envers les gestionnaires de source
335 distribués parce qu'ils veulent garder un contrôle ferme sur leur projet, et
336 ils pensent que les outils centralisés leur fournissent ce contrôle. Néanmoins,
337 si c'est votre cas, sachez que si vous publiez votre dépôt CVS ou Subversion
338 de manière publique, il existe une quantité d'outils disponibles pour récupérer
339 entièrement votre projet et son historique (quoique lentement) et le récréer
340 ailleurs, sans votre contrôle. En fait, votre contrôle sur votre projet est
341 illusoire, vous ne faites qu'interdire à vos collaborateurs de travailler
342 de manière fluide, en disposant d'un miroir ou d'un <quote>fork</quote> de votre
343 historique.
344 %%%TODO: Fussy, those last sentences are not really well translated:
345 %%%no problem for me (wilk)
346 %However, if you're of this belief, and you publish your CVS or Subversion
347 %repositories publically, there are plenty of tools available that can pull
348 %out your entire project's history (albeit slowly) and recreate it somewhere
349 %that you don't control. So while your control in this case is illusory, you are
350 %forgoing the ability to fluidly collaborate with whatever people feel
351 %compelled to mirror and fork your history.
352 </para>
354 </sect3>
355 </sect2>
356 <sect2>
357 <title>Avantages pour les projets commerciaux</title>
359 <para id="x_99">Beaucoup de projets commerciaux sont réalisés par des équipes éparpillées
360 à travers le globe. Les contributeurs qui sont loin du serveur central
361 devront subir des commandes lentes et même parfois peu fiables. Les
362 solutions propriétaires de gestion de source tentent de palier ce problème
363 avec des réplications de sites distants qui sont à la fois coûteuses à mettre
364 en place et lourdes à administrer. Un système distribué ne souffre pas
365 de ce genre de problèmes. En outre, il est très aisé de mettre en place
366 plusieurs serveurs de références, disons un par site, de manière à ce qu'il
367 n'y ait pas de communication redondante entre les dépôts, sur une connexion
368 longue distance souvent onéreuse.
369 </para>
371 <para id="x_9a">Les systèmes de gestion de source supportent généralement assez mal la
372 montée en charge. Ce n'est pas rare pour un gestionnaire de source centralisé
373 pourtant onéreux de s'effondrer sous la charge combinée d'une douzaine
374 d'utilisateurs concurrents seulement. Une fois encore, la réponse à cette problématique
375 est généralement encore la mise en place d'un ensemble complexe de serveurs
376 synchronisés par un mécanisme de réplication. Dans le cas d'un gestionnaire
377 de source distribué, la charge du serveur central &emdash; si vous avez un&emdash; est
378 plusieurs fois inférieure (car toutes les données sont déjà répliquées ailleurs),
379 un simple serveur, pas très cher, peut gérer les besoins d'une plus grande
380 équipe, et la réplication pour balancer la charge devient le
381 travail d'un simple script.
382 </para>
384 <para id="x_9b">Si vous avez des employés sur le terrain, en train de chercher à résoudre un souci sur
385 le site d'un client, ils bénéficieront aussi d'un gestionnaire de source
386 distribué. Cet outil leur permettra de générer des versions personnalisées,
387 d'essayer différentes solutions, en les isolant aisément les unes des autres,
388 et de rechercher efficacement à travers l'historique des sources, la cause
389 des bugs ou des régressions, tout ceci sans avoir besoin de la moindre
390 connexion au réseau de votre compagnie.
391 </para>
393 </sect2>
394 </sect1>
395 <sect1>
396 <title>Pourquoi choisir Mercurial?</title>
398 <para id="x_9c">Mercurial a plusieurs caractéristiques qui en font un choix particulièrement
399 pertinent pour la gestion de source:
400 </para>
401 <itemizedlist>
402 <listitem><para id="x_9d">It is easy to learn and use.</para></listitem>
403 <listitem><para id="x_9e">It is lightweight.</para></listitem>
404 <listitem><para id="x_9f">It scales excellently.</para></listitem>
405 <listitem><para id="x_a0">It is easy to
406 customise.</para></listitem></itemizedlist>
408 <para id="x_a1">Si vous êtes déjà familier d'un outil de gestion de source, vous serez
409 capable de l'utiliser en moins de 5 minutes. Sinon, ça ne sera pas beaucoup
410 plus long.
411 Les commandes utilisées par Mercurial, comme ses fonctionnalités, sont
412 généralement uniformes et cohérentes, et vous pouvez donc ainsi garder en tête
413 simplement quelques règles générales, plutôt qu'un lot complexe d'exceptions.
414 </para>
416 <para id="x_a2">Sur un petit projet, vous pouvez commencer à travailler avec Mercurial en
417 quelques instants. Ajouter des modifications ou des branches, transférer
418 ces modifications (localement ou via le réseau), et les opérations
419 d'historique ou de statut sont aussi très rapides. Mercurial reste hors de
420 votre chemin grâce à sa simplicité d'utilisation et sa rapidité d'exécution.
421 </para>
423 <para id="x_a3">L'utilité de Mercurial ne se limite pas à de petits projets: il est
424 aussi utilisé par des projets ayant des centaines ou même des milliers
425 de contributeurs, avec plusieurs dizaines de milliers de fichiers, et des
426 centaines de méga de code source.
427 </para>
429 <para id="x_a4">Si les fonctionnalités cœur de Mercurial ne sont pas suffisantes pour vous,
430 il est très aisé d'en construire d'autres. Mercurial est adapté à l'utilisation
431 de scripts, et son implémentation interne en Python, propre et claire,
432 rend encore plus facile l'ajout de fonctionnalités sous forme d'extensions. Il
433 en existe déjà un certain nombre de très populaires et très utiles,
434 dont le périmètre va de la recherche de bugs à l'amélioration des performances.
435 </para>
437 </sect1>
438 <sect1>
439 <title>Mercurial comparé aux autres outils</title>
441 <para id="x_a5">Avant que vous n'alliez plus loin, comprenez bien que cette section
442 reflète mes propres expériences, et elle est donc (j'ose le dire)
443 peu objective. Néanmoins, j'ai utilisé les outils de gestion de source
444 listés ci dessous, dans la plupart des cas, pendant plusieurs années.
445 %% TODO: Fussy translation.
446 </para>
449 <sect2>
450 <title>Subversion</title>
452 <para id="x_a6">Subversion est un des outils de gestion de source les plus populaire, il fût
453 développé pour remplacer CVS. Il a une architecture client/server centralisée.
454 </para>
456 <para id="x_a7">Subversion et Mercurial ont des noms de commandes très similaires pour
457 les mêmes opérations, ainsi si vous êtes familier avec l'un, c'est facile
458 d'apprendre l'autre. Ces deux outils sont portables sur les systèmes
459 d'exploitation les plus populaires
460 </para>
462 <para id="x_a8">Avant la version 1.5, Subversion n'offrait aucune forme de support pour les fusions. Lors
463 de l'écriture de ce livre, ses capacités de fusion étaient nouvelles, et réputées pour être
464 <ulink url="http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword">
465 complexes et boguées</ulink>.
466 </para>
468 <para id="x_a9">Mercurial dispose d'un avantage substantiel en terme de performance par rapport à
469 Subversion sur la plupart des opérations que j'ai pu tester. J'ai mesuré
470 une différence de performance allant de deux à six fois plus rapide avec
471 le système de stockage de fichier local de Subversion 1.4.3
472 (<emphasis>ra_local</emphasis>), qui est la méthode d'accès la plus rapide disponible. Dans
473 un déploiement plus réaliste, impliquant un stockage réseau, Subversion
474 serait encore plus désavantagé. Parce que la plupart des commandes Subversion
475 doivent communiquer avec le serveur et que Subversion n'a pas de mécanisme
476 de réplication, la capacité du serveur et la bande passante sont devenues des
477 goulots d'étranglement pour les projets de taille moyenne ou grande.
478 </para>
480 <para id="x_aa">En outre, Subversion implique une surcharge substantielle dans le stockage local
481 de certaines données, pour éviter des transactions avec le serveur, pour
482 certaines opérations communes, telles que la recherche des fichiers modifiés
483 (<literal>status</literal>) et l'affichage des modifications par rapport à la révision
484 courante (<literal>diff</literal>). En conséquence, un répertoire de travail Subversion
485 a souvent la même taille, ou est plus grand, qu'un dépôt Mercurial et son
486 espace de travail, et ceci bien que le dépôt Mercurial contienne l'intégralité
487 de l'historique.
488 </para>
490 <para id="x_ab">Subversion est largement supporté par les outils tierces. Mercurial est
491 actuellement encore en retrait de ce point de vue. L'écart se réduit, néanmoins,
492 et en effet certains des outils graphiques sont maintenant supérieurs à leurs
493 équivalents Subversion. Comme Mercurial, Subversion dispose d'un excellent
494 manuel utilisateur.
495 </para>
497 <para id="x_ac">Parce que Subversion ne stocke pas l'historique chez ses clients, il est
498 parfaitement adapté à la gestion de projets qui doivent suivre un ensemble
499 de larges fichiers binaires et opaques. Si vous suivez une cinquantaine de
500 versions d'un fichier incompressible de 10MB, l'occupation disque coté client
501 d'un projet sous Subversion restera à peu près constante. A l'inverse,
502 l'occupation disque du même projet sous n'importe lequel des gestionnaires
503 de source distribués grandira rapidement, proportionnellement aux nombres
504 de versions, car les différences entre chaque révisions seront très grandes.
505 </para>
507 <para id="x_ad">En outre, c'est souvent difficile ou, généralement, impossible de fusionner
508 des différences dans un fichier binaire. La capacité de Subversion de
509 verrouiller des fichiers, pour permettre à l'utilisateur d'être le seul
510 à le mettre à jour (<quote>commit</quote>) temporairement, est un avantage significatif
511 dans un projet doté de beaucoup de fichiers binaires.
512 </para>
514 <para id="x_ae">Mercurial peut importer l'historique depuis un dépôt Subversion. Il peut
515 aussi exporter l'ensemble des révisions d'un projet vers un dépôt Subversion.
516 Ceci rend très facile de <quote>prendre la température</quote> et d'utiliser Mercurial et Subversion
517 en parallèle, avant de décider de migrer vers Mercurial. La conversion de
518 l'historique est incrémentale, donc vous pouvez effectuer une conversion
519 initiale, puis de petites additions par la suite pour ajouter les nouvelles
520 modifications.
521 </para>
524 </sect2>
525 <sect2>
526 <title>Git</title>
528 <para id="x_af">Git est un outil de gestion de source distribué qui fût développé pour gérer
529 le code source de noyau de Linux. Comme Mercurial, sa conception initiale a
530 été inspirée par Monotone.
531 </para>
533 <para id="x_b0">Git dispose d'un ensemble conséquent de commandes, avec plus de 139 commandes
534 individuelles pour la version 1.5.0. Il a aussi la réputation d'être difficile
535 à apprendre. Comparé à Git, le point fort de Mercurial est clairement sa
536 simplicité.
537 </para>
539 <para id="x_b1">En terme de performance, Git est extrêmement rapide. Dans la plupart des
540 cas, il est plus rapide que Mercurial, tout du moins sur Linux, alors que
541 Mercurial peut être plus performant sur d'autres opérations. Néanmoins, sur
542 Windows, les performances et le niveau de support général fourni par Git,
543 au moment de l'écriture de cet ouvrage, est bien derrière celui de Mercurial.
544 </para>
546 <para id="x_b2">Alors que le dépôt Mercurial ne demande aucune maintenance, un dépôt Git
547 exige d'exécuter manuellement et régulièrement la commande <quote>repacks</quote> sur
548 ces métadonnées. Sans ceci, les performances de git se dégradent et la
549 consommation de l'espace disque augmente rapidement. Un serveur qui contient
550 plusieurs dépôts Git qui ne sont pas régulièrement et fréquemment <quote>repacked</quote>
551 deviendra un vrai problème lors des <quote>backups</quote> du disque, et il y eu des
552 cas, où un <quote>backup</quote> journalier pouvait durer plus de 24 heures. Un dépôt
553 fraichement <quote>repacked</quote> sera légèrement plus petit qu'un dépôt Mercurial,
554 mais un dépôt non <quote>repacked</quote> est beaucoup plus grand.
555 </para>
557 <para id="x_b3">Le cœur de Git est écrit en C. La plupart des commandes Git sont implémentées
558 sous forme de scripts Shell ou Perl, et la qualité de ces scripts varie
559 grandement. J'ai plusieurs fois constaté que certains de ces scripts étaient
560 chargés en mémoire aveuglément et que la présence d'erreurs pouvait s'avérer
561 fatal.
562 </para>
564 <para id="x_b4">Mercurial peut importer l'historique d'un dépôt Git.
565 </para>
569 </sect2>
570 <sect2>
571 <title>CVS</title>
573 <para id="x_b5">CVS est probablement l'outil de gestion de source le plus utilisé aujourd'hui
574 dans le monde. À cause de son manque de clarté interne, il n'est plus
575 maintenu depuis plusieurs années.
576 </para>
578 <para id="x_b6">Il a une architecture client/serveur centralisée. Il ne regroupe pas les
579 modifications de fichiers dans une opération de <quote>commit</quote> atomique, ce
580 qui permet à ses utilisateurs de <quote>casser le <emphasis>build</emphasis></quote> assez
581 facilement : une personne peut effectuer une opération de <quote>commit</quote>
582 sans problème puis être bloquée par besoin de fusion, avec comme conséquence
583 néfaste, que les autres utilisateurs ne récupèreront qu'une partie de ses
584 modifications. Ce problème affecte aussi la manière de travailler avec
585 l'historique du projet. Si vous voulez voir toutes les modifications d'une
586 personne du projet, vous devrez injecter manuellement les descriptions et les
587 <emphasis remap="it">timestamps</emphasis> des modifications de chacun des fichiers impliqués (si
588 vous savez au moins quels sont ces fichiers).
589 </para>
591 <para id="x_b7">CVS a une notion étrange des <emphasis
592 remap="it">tags</emphasis> et des branches que je n'essayerai
593 même pas de décrire ici. Il ne supporte pas bien les opérations de renommage d'un
594 fichier ou d'un répertoire, ce qui facilite la corruption de son dépôt. Il n'a
595 presque pas pour ainsi dire de contrôle de cohérence interne, il est donc
596 pratiquement impossible de dire si un dépôt est corrompu ni à quel point. Je
597 ne recommanderai pas CVS pour un projet existant ou nouveau.
598 </para>
600 <para id="x_b8">Mercurial peut importer l'historique d'un projet CVS. Néanmoins, il y a
601 quelques principes à respecter; ce qui est vrai aussi pour les autres
602 outils d'import de projet CVS. À cause de l'absence de <quote>commit</quote> atomique
603 et gestion de version de l'arborescence, il n'est pas possible de reconstruire
604 de manière précise l'ensemble de l'historique. Un travail de <quote>devinette</quote>
605 est donc nécessaire, et les fichiers renommés ne sont pas détectés. Parce
606 qu'une bonne part de l'administration d'un dépôt CVS est effectuée manuellement,
607 et est donc, sujette à erreur, il est courant que les imports CVS rencontrent
608 de nombreux problèmes avec les dépôt corrompus (des <emphasis
609 remap="it">timestamps</emphasis> de révision complètement buggés et des fichiers
610 verrouillés depuis des années sont deux des problèmes les moins intéressants dont
611 je me souvienne).
612 </para>
614 <para id="x_b9">Mercurial peut importer l'historique depuis un dépôt CVS.
615 </para>
618 </sect2>
619 <sect2>
620 <title>Outils propriétaires</title>
622 <para id="x_ba">Perforce a une architecture client/serveur centralisée, sans aucun
623 mécanisme de mise en cache de données coté client. Contrairement à la plupart
624 des outils modernes de gestion de source, Perforce exige de ses
625 utilisateurs d'exécuter une commande pour informer le serveur
626 central de tout fichier qu'ils souhaitent modifier.
627 </para>
629 <para id="x_bb">Les performances de Perforce sont plutôt bonnes pour des petites
630 équipes, mais elles s'effondrent rapidement lorsque le nombre
631 d'utilisateurs augmente au delà de la douzaine. Des installations
632 de Perforce assez larges nécessitent le déploiement de proxies pour
633 supporter la montée en charge associée.
634 </para>
637 </sect2>
638 <sect2>
639 <title>Choisir un outil de gestion de source</title>
641 <para id="x_bc">A l'exception de CVS, tous les outils listés ci-dessus ont des
642 forces qui leur sont propres et qui correspondent à certaines
643 formes de projet. Il n'y a pas un seul meilleur outil de gestion
644 de source qui correspondrait le mieux à toutes les situations.
645 </para>
647 <para id="x_bd">En guise exemple, Subversion est un très bon choix lorsqu'on travaille
648 avec beaucoup de fichiers binaires, qui évoluent régulièrement, grâce
649 à sa nature centralisée et sa capacité à verrouiller des fichiers.
650 </para>
652 <para id="x_be">Personnellement, je préfère Mercurial pour sa simplicité, ses
653 performances et sa bonne capacité de fusion, et il m'a très bien rendu service
654 de plusieurs années maintenant.
655 </para>
658 </sect2>
659 </sect1>
660 <sect1>
661 <title>Migrer depuis un outil à Mercurial</title>
663 <para id="x_bf">Mercurial est livré avec une extension nommée <literal role="hg-ext">convert</literal>, qui
664 peut de manière incrémentale importer des révisions depuis différents
665 autres outils de gestion de source. Par <quote>incrémental</quote>, j'entends que
666 vous pouvez convertir l'historique entier du projet en une seule fois,
667 puis relancer l'outil d'import plus tard pour obtenir les modifications
668 effectuées depuis votre import initial.
669 </para>
671 <para id="x_c0">Les outils de gestion de source supportés par <literal role="hg-ext">convert</literal> sont :
672 </para>
673 <itemizedlist>
674 <listitem><para id="x_c1">Subversion</para></listitem>
675 <listitem><para id="x_c2">CVS</para></listitem>
676 <listitem><para id="x_c3">Git</para></listitem>
677 <listitem><para id="x_c4">Darcs</para></listitem></itemizedlist>
679 <para id="x_c5">En outre, <literal role="hg-ext">convert</literal> peut exporter les modifications depuis Mercurial
680 vers Subversion. Ceci rend possible d'essayer Subversion en parallèle
681 avant de choisir une solution définitive, sans aucun risque de perte de
682 données.
683 </para>
685 <para id="x_c6">La commande <command role="hg-ext-conver">convert</command> est très simple à utiliser. Simplement,
686 indiquez le chemin ou l'URL du dépôt de source, en lui indiquant éventuellement
687 le nom du chemin de destination, et la conversion se met en route. Après cet
688 import initial, il suffit de relancer la commande encore une fois pour
689 importer les modifications effectuées depuis.
690 </para>
691 </sect1>
693 <sect1>
694 <title>Une courte histoire de la gestion de source</title>
696 <para id="x_c7">Le plus célèbre des anciens outils de gestion de source
697 est <emphasis remap="it">SCCS</emphasis>
698 (Source Code Control System)}, que Marc Rochkind conçu dans les laboratoires de
699 recherche de Bell (<emphasis remap="it">Bell Labs</emphasis>), dans le début des années 70.
700 <emphasis remap="it">SCCS</emphasis> ne fonctionnait que sur des fichiers individuels, et obligeait chaque
701 personne travaillant sur le projet d'avoir un accès à un répertoire de
702 travail commun, sur le même système. Seulement une seule personne pouvait
703 modifier un fichier au même moment, ce fonctionnement était assuré par
704 l'utilisation de verrou (<quote>lock</quote>). Il était courant que des personnes
705 verrouillent des fichiers, et plus tard, oublient de le déverrouiller;
706 empêchant n'importe qui d'autre de travailler sur ces fichiers sans l'aide de
707 l'administrateur...
708 </para>
710 <para id="x_c8">Walter Tichy a développé une alternative libre à
711 <emphasis remap="it">SCCS</emphasis> au début des
712 années 80, qu'il nomma <emphasis remap="it">RCS (Revision Control System)</emphasis>. Comme
713 <emphasis remap="it">SCCS</emphasis>, <emphasis remap="it">RCS</emphasis> demandait aux développeurs de travailler sur le même
714 répertoire partagé, et de verrouiller les
715 fichiers pour se prémunir de tout conflit issu de modifications concurrentes.
716 </para>
718 <para id="x_c9">Un peu plus tard dans les années 1980, Dick Grune utilisa <emphasis remap="it">RCS</emphasis> comme
719 une brique de base pour un ensemble de scripts <emphasis
720 remap="it">shell</emphasis> qu'il intitula
721 cmt, avant de la renommer en <emphasis remap="it">CVS (Concurrent Versions System)</emphasis>. La
722 grande innovation de CVS était que les développeurs pouvaient travailler
723 simultanément et indépendamment dans leur propre espace de travail. Ces espaces
724 de travail privés assuraient que les développeurs ne se marchent pas
725 mutuellement sur les pieds, comme c'était souvent le cas avec RCS et SCCS.
726 Chaque développeur disposait donc de sa copie de tous les fichiers du projet,
727 et ils pouvaient donc librement les modifier. Ils devaient néanmoins effectuer
728 la <quote>fusion</quote> (<emphasis
729 remap="it"><quote>merge</quote></emphasis>) de leurs fichiers, avant d'effectuer le
730 <quote>commit</quote> de leur modifications sur le dépôt central.
731 </para>
733 <para>Brian Berliner reprit les scripts de Grune's et les réécrit en C, qu'il publia
734 en 1989. Depuis, ce code a été modifié jusqu'à devenir la version moderne de
735 CVS. CVS a acquis ainsi la capacité de fonctionner en réseau, transformant son
736 architecture en client/serveur. L'architecture de CVS est centralisée, seul le
737 serveur a une copie de l'historique du projet. L'espace de travail client ne
738 contient qu'une copie de la dernière version du projet, et quelques métadonnées
739 pour indiquer où le serveur se trouve. CVS a été un grand succès, aujourd'hui
740 il est probablement l'outil de gestion de contrôle le plus utilisé au monde.
741 </para>
743 <para>Au début des années 1990, Sun Microsystmes développa un premier outil de
744 gestion de source distribué, nommé TeamWare. Un espace de travail TeamWare
745 contient une copie complète de l'historique du projet. TeamWare n'a pas de
746 notion de dépôt central. (CVS utilisait RCS pour le stockage de l'historique,
747 TeamWare utilisait SCCS).
748 </para>
750 <para>Alors que les années 1990 avançaient, les utilisateurs ont pris conscience d'un
751 certain nombre de problèmes avec CVS. Il enregistrait simultanément des
752 modifications sur différents fichiers individuellement, au lieu de les
753 regrouper dans une seule opération cohérente et atomique. Il ne gère pas bien
754 sa hiérarchie de fichier, il est donc assez aisé de créer le chaos en renommant
755 les fichiers et les répertoires. Pire encore, son code source est difficile à
756 lire et à maintenir, ce qui agrandit largement le <quote>niveau de souffrance</quote>
757 associé à la réparation de ces problèmes d'architecture de manière prohibitive.
758 </para>
760 <para>En 2001, Jim Blandy et Karl Fogel, deux développeurs qui avaient travaillé sur
761 CVS, initièrent un projet pour le remplacer par un outil qui aurait une
762 meilleure architecture et un code plus propre. Le résultat, Subversion, ne
763 quitte pas le modèle centralisé et client/server de CVS, mais ajoute les
764 opérations de <quote>commit</quote> atomique sur de multiples fichiers, une meilleure
765 gestion des espaces de noms, et d'autres fonctionnalités qui en font un
766 meilleur outil que CVS. Depuis sa première publication, il est rapidement
767 devenu très populaire.
768 </para>
770 <para>Plus ou moins simultanément, Graydon Hoare a commencé sur l'ambitieux
771 système de gestion distribué Monotone. Bien que Monotone corrige plusieurs
772 défauts de CVS's tout en offrant une architecture <quote>peer-to-peer</quote>, il va aussi
773 plus loin que la plupart des outils de révision de manière assez innovante. Il
774 utilise des <quote>hash</quote> cryptographiques comme identifiants, et il a une notion
775 complète de <quote>confiance</quote> du code issu des différentes sources.
776 </para>
778 <para>Mercurial est né en 2005. Bien que très influencé par Monotone, Mercurial se
779 concentre sur la facilité d'utilisation, les performances et la capacité à
780 monter en charge pour de très gros projets.
781 </para>
783 </sect1>
787 </chapter>
789 <!--
790 local variables:
791 sgml-parent-document: ("00book.xml" "book" "chapter")
792 end:
793 -->