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