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