| rev |
line source |
|
bos@16
|
1 \chapter{Introduction}
|
|
bos@16
|
2 \label{chap:intro}
|
|
bos@16
|
3
|
|
romain@923
|
4 \section{A propros de la gestion source}
|
|
romain@923
|
5
|
|
romain@923
|
6 La gestion de source est un processus permettant de gérer différentes
|
|
romain@923
|
7 version de la même information. Dans sa forme la plus simple, c'est
|
|
romain@923
|
8 quelquechose que tout le monde fait manuellement : quand vous modifiez
|
|
romain@923
|
9 un fichier, vous le sauvegarder sous un nouveau nom contenant un numéro,
|
|
romain@923
|
10 à chaque fois plus grand la précédente version.
|
|
romain@923
|
11
|
|
romain@923
|
12 Ce genre de gestion de version manuel est cependant sujette facilement
|
|
romain@923
|
13 à des erreurs, ainsi, depuis longtemps, des logiciels existent pour
|
|
romain@923
|
14 adresser cette problématique. Les premiers outils de gestion de source
|
|
romain@923
|
15 étaient destinés à aider un seul utilisateur, à automatiser la gestion
|
|
romain@923
|
16 des versions d'un seulf fichier. Dans les dernières décades, cette cilble
|
|
romain@923
|
17 a largement était agrandie, ils gèrent désormais de multiple fichiers, et
|
|
romain@923
|
18 aident un grand nombre de personnes à travailler ensemble. Le outils les
|
|
romain@923
|
19 plus modernes n'ont aucune difficultés à gérer plusieurs milliers de
|
|
romain@923
|
20 personnes travaillant ensemble sur des projets regroupant plusieurs
|
|
romain@923
|
21 centaines de milliers de fichiers.
|
|
romain@923
|
22
|
|
romain@923
|
23 \subsection{Pourquoi utiliser un gestionnaire de source ?}
|
|
romain@923
|
24
|
|
romain@923
|
25 Il y a de nombreuse raisons pour que vous ou votre équipe souhaitiez
|
|
romain@923
|
26 utiliser un outil automatisant la gestion de version pour votre projet.
|
|
bos@217
|
27 \begin{itemize}
|
|
romain@923
|
28 \item L'outil se chargera de suivre l'évolution de votre projet, sans
|
|
romain@923
|
29 que vous ayez à le faire. Pour chaque modification, vous aurez à votre
|
|
romain@923
|
30 disposition un journal indiquant \emph{qui} a faient quoi, \emph{pourquoi}
|
|
romain@923
|
31 ils l'ont fait, \emph{quand} ils l'ont fait, et \emph{ce} qu'ils ont
|
|
romain@923
|
32 modifiés.
|
|
romain@923
|
33 \item Quand vous travaillez avec d'autres personnes, les logiciels de
|
|
romain@923
|
34 gestion de source facilite le travail collaboratif. Par exemple, quand
|
|
romain@923
|
35 plusieurs personnes font, plus ou moins simultannéement, des modifications
|
|
romain@923
|
36 incompatibles, le logiciel vous aidera à identifier et résoudre les conflits.
|
|
romain@924
|
37 \item L'outil vous aidera à réparer vos erreurs. Si vous effectuez un changement
|
|
romain@924
|
38 qui se révèlera être une erreur, vous pourrez revenir fiablement à une version
|
|
romain@924
|
39 antérieur d'une fichier ou même d'un ensemble de fichier. En fait, un outil de
|
|
romain@924
|
40 gestion de source \emph{vraiment} efficace vous permettra d'identifier à quel
|
|
romain@924
|
41 moment le problème est apparu (voir la section~\ref{sec:undo:bisect} pour plus
|
|
romain@924
|
42 de détails).
|
|
romain@924
|
43 \item L'outil vous permettra aussi de travailler sur plusieurs versions différentes
|
|
romain@924
|
44 de votre projet et à gérer l'écart entre chaque.
|
|
bos@217
|
45 \end{itemize}
|
|
romain@924
|
46 La plupart de ces raisons ont autant d'importances---du moins en théorie--- que
|
|
romain@924
|
47 vous travailliez sur un projet pour vous, ou avec une centaine d'autres
|
|
romain@924
|
48 personnes.
|
|
romain@924
|
49
|
|
romain@924
|
50 Une question fondamental à propos des outils de gestion de source, qu'il s'agisse
|
|
romain@924
|
51 du projet d'une personne ou d'une grande équipe, est quelles sont ses
|
|
romain@924
|
52 \emph{avantages} par rapport à ses \emph{coût}. Un outil qui est difficile à
|
|
romain@924
|
53 utiliser ou à comprendre exigera un effort d'adoption.
|
|
romain@924
|
54
|
|
romain@924
|
55 Un projet de cinq milles personnnes s'effondrera très certainement de lui même
|
|
romain@924
|
56 sans aucun processus et outil de gestion de source. Dans ce cas, le coût
|
|
romain@924
|
57 d'utilisation d'un logiciel de gestion de source est dérisoire, puisque
|
|
romain@924
|
58 \emph{sans}, l'échec est presque garanti.
|
|
romain@924
|
59
|
|
romain@924
|
60 D'un autre coté, un ``rapide hack'' d'une personnne peut sembler un contexte
|
|
romain@924
|
61 bien pauvre pour utiliser un outil de gestion de source, car, bien évidement
|
|
romain@924
|
62 le coût d'utilisation dépasse le coût total du projet. N'est ce pas ?
|
|
romain@924
|
63
|
|
romain@924
|
64 Mercurial supporte ces \emph{deux} échelles de travail. Vous pouvez apprendre
|
|
romain@924
|
65 les bases en juste quelques minutes, et, grâce à sa performance, vous pouvez
|
|
romain@924
|
66 l'utiliser avec facilité sur le plus petit des projets. Cette simplicité
|
|
romain@924
|
67 signifie que vous n'avez pas de concepts obscures ou de séquence de commandes
|
|
romain@924
|
68 défiant l'imagination, complètement décorrelé de \emph{ce que vous êtes
|
|
romain@924
|
69 vraiment entrain de faire}. En même temps, ces mêmes performances et sa
|
|
romain@924
|
70 nature ``peer-to-peer'' vous permet d'augmenter, sans difficulté, son
|
|
romain@924
|
71 utilisation à de très grand projet.
|
|
romain@924
|
72
|
|
romain@924
|
73 Aucun outil de gestion de source ne peut sauver un projet mal mené, mais un
|
|
romain@924
|
74 bon outil peut faire une grande différence dans la fluidité avec lequel
|
|
romain@924
|
75 vous pourrez travailler avec.
|
|
romain@924
|
76
|
|
romain@924
|
77 \subsection{Les multiples noms de la gestion de source}
|
|
romain@924
|
78
|
|
romain@928
|
79 La gestion de source\footnote{NdT: J'ai utilisé systématiquement le terme ``gestion de source'' à travers tout l'ouvrage. Ce n'est pas forcement la meilleur traduction, et ceci peut rendre la lecture un peu lourde, mais je pense que le document y gagne en clarté et en précision.} est un domaine divers, tellement qu'il n'existe pas
|
|
romain@924
|
80 une seul nom ou acronyme pour le désigner. Voilà quelqu'uns des noms ou
|
|
romain@928
|
81 acronymes que vous rencontrerez le plus souvent\footnote{NdT: J'ai conservé la liste des noms en anglais pour des raisons de commodité (ils sont plus ``googelable''). En outre, j'ai opté conserver l'ensemble des opérations de Mercurial (\textit{commit},\textit{push}, \textit{pull},...) en anglais, là aussi pour faciliter la lecture d'autres documents en anglais, et aussi l'utilisation de Mercurial}.
|
|
romain@928
|
82
|
|
romain@928
|
83 :
|
|
bos@217
|
84 \begin{itemize}
|
|
romain@924
|
85 \item \textit{Revision control (RCS)} ;
|
|
romain@924
|
86 \item Software configuration management (SCM), ou \textit{configuration management} ;
|
|
romain@924
|
87 \item \textit{Source code management} ;
|
|
romain@924
|
88 \item \textit{Source code control}, ou \textit{source control} ;
|
|
romain@924
|
89 \item \textit{Version control (VCS)}.
|
|
bos@217
|
90 \end{itemize}
|
|
romain@924
|
91
|
|
romain@924
|
92 Certains personnes prétendent que ces termes ont en fait des sens
|
|
romain@924
|
93 différents mais en pratique ils se recouvrent tellement qu'il n'y a pas
|
|
romain@924
|
94 réellement de manière pertinente de les distinguer.
|
|
romain@924
|
95
|
|
romain@924
|
96 \section{Une courte histoire de la gestion de source}
|
|
romain@924
|
97
|
|
romain@924
|
98 Le plus célèbre des anciens outils de gestion de source est \textit{SCCS (Source
|
|
romain@924
|
99 Code Control System)}, que Marc Rochkind conçu dans les laboratoire de recherche de Bell
|
|
romain@924
|
100 (\textit{Bell Labs}), dans le début des années 70. \textit{SCCS} ne fonctionner que sur des fichiers individuels, et demandait à personne travaillant sur le projet d'avoir un accès à un répertoire de travail commun, sur un unique système.
|
|
romain@924
|
101 Seulement une personne pouvait modifier un fichier au même moment, ce fonctionnement était assuré par l'utilisation de verrou (``lock''). Il était courant que des personnes ne vérouille
|
|
romain@924
|
102 des fichiers, et plus tard, oublie de le dévérouiller; empêchant n'importe qui d'autre de
|
|
romain@924
|
103 travailler sur ces fichiers sans l'aide de l'administrateur...
|
|
romain@924
|
104
|
|
romain@924
|
105 Walter Tichy a développé une alternative libre à \textit{SCCS} au début des années 80, qu'il
|
|
romain@924
|
106 nomma \textit{RSC (Revison Control System)}. Comme \textit{SCCS}, \textit{RCS}
|
|
romain@924
|
107 demander aux développeurs de travailler sur le même répertoire partagé, et de vérouiller les
|
|
romain@924
|
108 fichiers pour se prémunir de tout conflit issue de modifications concurrentes.
|
|
romain@924
|
109
|
|
romain@924
|
110 Un peu plus tard dans les années 1980, Dick Grune utilisa \textit{RCS} comme une brique de base pour un ensemble de scripts \textit{shell} qu'il intitula cmt, avant de la renommer en \textit{CVS (Concurrent Versions System)}. La grande innovation de CVS était que les développeurs pouvaient travailler simultanéement and indépendament dans leur propre espace de travail. Ces espaces de travail privés assuraient que les développeurs ne se marche mutuellement sur les pieds, comme c'était souvent le cas avec RCS et SCCS. Chaque développeur disposait donc de sa copie de tout les fichiers du projet, et ils pouvaient donc librement les modifier. Ils devaient néanmoins effectuer la ``fusion'' (\textit{``merge''}) de leur fichiers, avant d'effectuer le ``commit'' de leur modification sur le dépôt central.
|
|
bos@218
|
111
|
|
romain@926
|
112 Brian Berliner repris les scripts de Grune's et les réécris en~C, qu'il publia en 1989. Depuis, ce code a été modifié jusqu'à devenir la version moderne de CVS. CVS a acquis ainsi la capacité de fonctionner en réseau, le transformant son architecture en client/serveur. L'architecture de CVS est centralisée, seul le serveur a une copie de l'historique du projet. L'espace de travail client ne contient qu'une copie de la dernière version du projet, et quelques métadonnées pour indiquer où le serveur se trouve. CVS a été un grand succès, aujourd'hui c'est probablement l'outil de gestion de contrôle le plus utilisé au monde.
|
|
romain@926
|
113
|
|
romain@926
|
114 Au début des années 1990, Sun Microsystmes développa un premier outil de gestion de source distribué, nommé TeamWare. Un espace de travail TeamWare contient une copie complète de l'historique du projet. TeamWare n'a pas de notion de dépot central. (CVS utilisé RCS pour le stockage de l'historique, TeamWare utilisé SCCS).
|
|
romain@926
|
115
|
|
romain@926
|
116 Alors que les années 1990 avancé, les utilisateurs ont pris conscience d'un certain nombre de problème avec CVS. Il enregistrait simultanéement des modifications sur différents fichier individuellement, au lieu de les regrouper dans une seule opération cohérente et atomique. Il ne gère pas bien sa hiérarchie de fichier, il est donc assez aisé de créer le chaos en renommant les fichiers et les répertoires. Pire encore, son code source est difficile à lire et à maintenir, ce qui agrandit largement le ``niveau de souffrance'' associé à la réparation de ces problèmes d'architecture de manière prohibitive.
|
|
romain@926
|
117
|
|
romain@926
|
118
|
|
romain@926
|
119 En 2001, Jim Blandy et Karl Fogel, deux développeurs qui avaient travaillé sur CVS, initialisèrent un projet pour le remplacer par un outil qui aurait une meilleur architecture et un code plus propre. Le résultat, Subversion, ne quitte pas le modèle centralisé et client/server de CVS, mais ajoute les opérations de ``commit'' atomique sur de multiples fichier, une meilleur gestion des espaces de noms, et d'autres fonctionnalités qui en font un meilleur outil que CVS. Depuis sa première publication, il est rapidement devenu très populaire.
|
|
romain@926
|
120
|
|
romain@926
|
121 Plus ou moins de manière simultanné, Graydon Hoare a commencé sur l'ambitieux système de gestion distribué Monotone. Bien que Monotone corrige plusieurs défaut de CVS's tout en offrant une architecture ``peer-to-peer'', il va aussi plus loin que la plupart des outils de révision de manière assez innovante. Il utilise des ``hash'' cryptographique comme identifiant, et il a notion complète de ``confiance'' du code issues de différentes sources.
|
|
romain@926
|
122
|
|
romain@926
|
123 Mercurial est né en 2005. Bien que très influencé par Monotone, Mercurial se concentre sur la facilité d'utilisation, les performances et la capacité à monter en charge pour de très grand projets.
|
|
romain@926
|
124
|
|
romain@926
|
125 \section{Tendances de la gestion de source}
|
|
romain@926
|
126
|
|
romain@926
|
127 Il y a eu une tendance évidente dans le développement et l'utilisation d'outil de gestion de source depuis les quatre dernière décades, au fur et à mesure que les utilisateurs se sont habitués à leur outils et se sont sentis contraint par leur limitations.
|
|
romain@926
|
128
|
|
romain@926
|
129 La première génération commença simplement par gérer un fichier unique sur un ordinateur individuel. Cependant, même si ces outils présentè-rent une grande avancée par rapport à la gestion manuel des versions, leur modèle de vérouillage et leur utilisation limité à un seul ordinateur rendaient leur utilisation possible uniquement dans une très petite équipe.
|
|
romain@926
|
130
|
|
romain@926
|
131 La seconde génération a assoupli ces contraintes en adoptant une architecture réseau et centralisé, permettant de gérer plusieurs projets entiers en même temps. Alors que les projets grandirent en taille, ils rencontrèrent de nouveau problèmes. Avec les clients discutant régulièrement avec le serveurs, la monte en charge devint un réellement problème sur les gros projets. Une connexion réseau peu fiable pouvant empêcher simplement les utilisateurs distant de discuter avec le serveur. Alors que les projets \textit{Open Source} commencèrent à mettre en place des accès en lecture seule disponible anonymement, les utilisateurs sans les privilèges de ``commit'' réalisèrent qu'ils ne pouvaient pas utiliser les outils pour collaboraient naturellement avec le projet, comme ils ne pouvaient pas non plus enregistrer leurs modifications.
|
|
romain@926
|
132
|
|
romain@926
|
133 La génération actuelle des outils de gestion de source est ``peer-to-peer'' par nature. Tout ces systèmes ont abandonné la dépendance à un serveur central, et ont permis à leur utilisateur de distribué les données de leur gestion de source à qui en a besoin. La collaboration à travers Internet a transformée la contrainte technologique à une simple question de choix et de consencus. Les outils moderne peuvent maintenant fonctionner en mode déconnecté sans limite et de manière autonome, la connexion au réseau n'étant nécessaire que pour synchroniser les modifications avec les autres dépots.
|
|
romain@926
|
134
|
|
romain@926
|
135 \section{Quelques avantages des gestionnaire de source distribué}
|
|
romain@926
|
136
|
|
romain@926
|
137 Même si les gestionnaire de source distribué sont depuis plusieurs années
|
|
romain@926
|
138 assez robuste et aussi utilisable que leur prédécésseurs, les utilisateurs
|
|
romain@926
|
139 d'autres outils n'ont pas encore étaient sensibilisé. Les gestionnaires
|
|
romain@926
|
140 de sources distribué se distingue particulièrement de leurs équivalents
|
|
romain@926
|
141 centralisé de nombreuse manière.
|
|
romain@926
|
142
|
|
romain@926
|
143 Pour un développeur individuel, ils restent beaucoup plus rapide que les
|
|
romain@926
|
144 outils centralisés. Cela pour une raison simple: un outil centralisé doit
|
|
romain@926
|
145 toujours discuter à travers le réseau pour la plupart des opérations, car
|
|
romain@926
|
146 presque toutes les métadonnées sont stockées sur la seule copie du serveur
|
|
romain@926
|
147 central. Un outil distribué stocke toute ses métadonnées localement. À tâche
|
|
romain@926
|
148 égale, effectuer un échange avec le réseau ajoute un délai aux outils
|
|
romain@926
|
149 centralisés. Ne sous estimez pas la valeur d'un outil rapide: vous allez
|
|
romain@926
|
150 passer beaucoup de temps à interagir avec un logiciel de gestion de sources.
|
|
romain@926
|
151
|
|
romain@926
|
152 Les outils distribué sont complètement indépendant des aléas de votre serveur,
|
|
romain@926
|
153 encore une fois car ils répliquent les métadonnées à tellement d'endoit. Si
|
|
romain@926
|
154 votre serveur central prend feu, vous avez intérêt à ce que les média de
|
|
romain@926
|
155 sauvegarde soient fiable, et que votre dernier ``backup'' soit récent et
|
|
romain@926
|
156 fonctionne sans problème. Avec un outil distribué, vous avez autant de
|
|
romain@926
|
157 ``backup'' que de contributeurs.
|
|
romain@926
|
158
|
|
romain@926
|
159 En outre, la fiabilité de votre réseau affectera beaucoup moins les
|
|
romain@926
|
160 outils distribué. Vous ne pouvez même pas utiliser un outil centralisé
|
|
romain@926
|
161 sans connexion réseau, à l'exception de quelques commandes, très limités.
|
|
romain@926
|
162 Avec un outil distribué, si vous connexion réseau tombe pendant que vous
|
|
romain@926
|
163 travaillez, vous pouvez ne même pas vous en rendre compte. La seule chose
|
|
romain@926
|
164 que vous ne serez pas capable de faire sera de communiquer avec des dépôts
|
|
romain@926
|
165 distants, opération somme toute assez rare par comparaison aux opérations
|
|
romain@926
|
166 locales. Si vous avez une (TODO:far-flung???) équipe de collaborateurs,
|
|
romain@926
|
167 ceci peut être significatif.
|
|
romain@926
|
168
|
|
romain@926
|
169 \subsection{Avantages pour les projets \textit{Open Source}}
|
|
romain@926
|
170
|
|
romain@926
|
171 Si vous prenez goût à un projet \textit{Open Source} et que vous
|
|
romain@926
|
172 décidez de commencer à toucher à son code, et que le projet utilise
|
|
romain@926
|
173 un gestionnaire de source distribué, vous êtes immédiatement un "pair"
|
|
romain@926
|
174 avec les personnes formant le ``coeur'' du projet. Si ils publient
|
|
romain@926
|
175 leurs dépôts, vous pouvez immédiatement copier leurs historiques de
|
|
romain@926
|
176 projet, faire des modifications, enregistrer votre travail en utilisant
|
|
romain@926
|
177 les même outils qu'eux. Par comparaison, avec un outil centralisé, vous
|
|
romain@926
|
178 devez utiliser un logiciel en mode ``lecture seule'' à moins que
|
|
romain@926
|
179 quelqu'un ne vous donne les privilèges de ``commit'' sur le serveur
|
|
romain@926
|
180 central. Avant ça, vous ne serez pas capable d'enregistrer vos
|
|
romain@926
|
181 modifications, et vos propres modifications risqueront de se
|
|
romain@926
|
182 corrompre chaque fois que vous essayerez de mettre à jour à votre
|
|
romain@926
|
183 espace de travail avec le serveur central.
|
|
romain@926
|
184
|
|
romain@926
|
185 \subsubsection{Le non-problème du \textit{fork}}
|
|
romain@926
|
186
|
|
romain@926
|
187 Il a été souvent suggeré que les gestionnaires de source distribués
|
|
romain@926
|
188 posent un risque pour les projets \textit{Open Source} car ils
|
|
romain@926
|
189 facilitent grandement la création de ``fork''\footnote{NdT:Création
|
|
romain@926
|
190 d'une version alternative du logiciel}. %%% TODO: Link to Wikipedia
|
|
romain@926
|
191 Un ``fork'' apparait quand il y des divergences d'opinion ou d'attitude
|
|
romain@926
|
192 au sein d'un groupe de développeurs qui aboutit à la décision de ne
|
|
romain@926
|
193 plus travail ensemble. Chacun parti s'empare d'une copie plus ou moins
|
|
romain@926
|
194 complète du code source du projet et continue dans sa propre direction.
|
|
romain@926
|
195
|
|
romain@926
|
196 Parfois ces différents partis décide de se réconcilier. Avec un
|
|
romain@926
|
197 serveur central, l'aspect \emph{technique} de cette réconciliation
|
|
romain@926
|
198 est un processus douloureux, et essentiellement manuel. Vous devez
|
|
romain@926
|
199 décider quelle modification est ``la gagnante'', et replacer, par un
|
|
romain@926
|
200 moyen ou un autre, les modifications de l'autre équipe dans l'arboresence
|
|
romain@926
|
201 du projet. Ceci implique généralement la perte d'une partie l'historique
|
|
romain@926
|
202 d'un des partie, ou même des deux.
|
|
romain@926
|
203
|
|
romain@926
|
204 Ce que les outils distribués permettent à ce sujet est probablement
|
|
romain@926
|
205 la \emph{meilleur} façon de développer un projet. Chaque modification
|
|
romain@926
|
206 que vous effectué est potentiellement un ``fork''. La grande force de
|
|
romain@926
|
207 cette approche est que les gestionnaire de source distribué doit être
|
|
romain@926
|
208 vraiment très efficase pour \emph{fusionner}\footnote{NdT:j'ai choisi de
|
|
romain@926
|
209 traduire ici \textit{merging} par ``fusionner'' pour des raisons de clarté}
|
|
romain@926
|
210 des ``forks'', car les ``forks'', dans ce contexte, arrivent tout le
|
|
romain@926
|
211 temps.
|
|
romain@926
|
212
|
|
romain@926
|
213 Si chaque altération que n'importe qui effectue, à tout moment, est vu
|
|
romain@926
|
214 comme un ``fork'' à fusionner, alors ce que le monde de l'\textit{Open
|
|
romain@926
|
215 Source} voit comme un ``fork'' devient \emph{uniquement} une problématique
|
|
romain@926
|
216 social. En fait, les outils de gestion de source distribué \emph{réduisent}
|
|
romain@926
|
217 les chances de ``fork'':
|
|
bos@220
|
218 \begin{itemize}
|
|
romain@926
|
219 \item Ils éliminent la distinction social qu'imposent les outils centralisés
|
|
romain@926
|
220 entre les membres du projets (ce qui ont accès au ``comit'') et ceux de l'
|
|
romain@926
|
221 extérieur (ce qui ne l'ont pas).
|
|
romain@926
|
222 \item Ils rendent plus facile la réconciliation après un ``fork'' social, car
|
|
romain@926
|
223 tout ce qu'elle implique est juste une simple fusion.
|
|
bos@220
|
224 \end{itemize}
|
|
bos@220
|
225
|
|
romain@926
|
226 Certaines personnes font de la résistance envers les gestionnaires de source
|
|
romain@926
|
227 distribués parce qu'ils veulent garder un contrôle ferme de leur projet, et
|
|
romain@926
|
228 ils pensent que les outils centralisés leur fournissent ce contrôle. Néanmoins,
|
|
romain@926
|
229 si c'est votre cas, sachez que si vous publier votre dépôt CVS ou Subversion
|
|
romain@926
|
230 de manière publique, il existe une quantité d'outils disponibles pour récupérer
|
|
romain@926
|
231 entièrement votre projet et son historique (quoique lentement) et le récréer
|
|
romain@926
|
232 ailleurs, sans votre contrôle. En fait, votre contrôle sur votre projet est
|
|
romain@926
|
233 illusoire, vous ne faites qu'interdire à vos collaborateurs de travailler
|
|
romain@926
|
234 de manière fluide, en disposant d'un miroir ou d'un ``fork'' de votre
|
|
romain@926
|
235 historique.
|
|
romain@926
|
236 %%%TODO: Fussy, those last sentences are not really well translated:
|
|
romain@926
|
237 %However, if you're of this belief, and you publish your CVS or Subversion
|
|
romain@926
|
238 %repositories publically, there are plenty of tools available that can pull
|
|
romain@926
|
239 %out your entire project's history (albeit slowly) and recreate it somewhere
|
|
romain@926
|
240 %that you don't control. So while your control in this case is illusory, you are
|
|
romain@926
|
241 %forgoing the ability to fluidly collaborate with whatever people feel
|
|
romain@926
|
242 %compelled to mirror and fork your history.
|
|
romain@926
|
243
|
|
romain@926
|
244 \subsection{Avantages pour les projets commerciaux}
|
|
romain@926
|
245
|
|
romain@926
|
246 Beaucoup de projets commerciaux sont réalisé par des équipes éparpillées
|
|
romain@926
|
247 à travers le globe. Les contributeurs qui sont loin du serveur central
|
|
romain@926
|
248 devront subir des commandes lentes et même parfois peu fiable. Les
|
|
romain@926
|
249 solutions propriétaires gestion de source, tentent de palier ce problème
|
|
romain@926
|
250 avec des réplications de site distant qui sont à la fois coûteuses à mettre
|
|
romain@926
|
251 en place et lourdes à administrer. A un système distribué ne souffre pas
|
|
romain@926
|
252 de ce genre de problèmes. En outre, il est très aisé de mettre en place
|
|
romain@926
|
253 plusieurs serveurs de références, disont un par site, de manière à ce qu'il
|
|
romain@926
|
254 n'y est pas de communication redondante entre les dépôts, sur une connexion
|
|
romain@926
|
255 longue distance souvent onéreuse.
|
|
romain@926
|
256
|
|
romain@926
|
257 Les systèmes de gestion de source supportent généralement assez mal la
|
|
romain@926
|
258 monté en charge. Ce n'est pas rare pour un gestionnaire de source centralisé
|
|
romain@926
|
259 pourtant onéreux de s'effondrer sous la charge combinée de juste une douzaine
|
|
romain@926
|
260 d'utilisateurs concurrents. Une fois encore, la réponse à cette problématique
|
|
romain@926
|
261 est généralement encore la mise en place d'un ensemble complexe de serveurs
|
|
romain@926
|
262 synchronisé par un mécanisme de réplication. Dans le cas d'un gestionnaire
|
|
romain@926
|
263 de source distribué, la charge du serveur central--- si vous avez un--- est
|
|
romain@926
|
264 plusieurs fois inférieur (car toutes les données sont déjà répliqués ailleurs),
|
|
romain@926
|
265 un simple server, pas très cher, peut gérer les besoins d'une plus grande
|
|
romain@926
|
266 équipe, et la réplication pour balancer la charge devient simplement le
|
|
romain@926
|
267 travail d'un simple script.
|
|
romain@926
|
268
|
|
romain@926
|
269 Si vous avez des employés sur le terrain, entrain de chercher à résoudre sur
|
|
romain@926
|
270 le site d'un client, ils bénéficieront aussi d'un gestionnaire de source
|
|
romain@926
|
271 distribués. Cet outil leur permettra de générer des versions personnalisées,
|
|
romain@926
|
272 d'essayer différentes solutions, en les isolant aisément les une des autres,
|
|
romain@926
|
273 et de recherche efficasement à travers l'historique des sources, la cause
|
|
romain@926
|
274 des bugs ou des régression, tout ceci sans avoir besoin de la moindre
|
|
romain@926
|
275 connexion au réseau de votre compagnie.
|
|
romain@926
|
276
|
|
romain@926
|
277 \section{Pourquoi choisir Mercurial?}
|
|
romain@926
|
278
|
|
romain@926
|
279 Mercurial a plusieurs caractéristiques qui en font un choix particulièrement
|
|
romain@926
|
280 pertinent pour la gestion de source:
|
|
bos@221
|
281 \begin{itemize}
|
|
romain@926
|
282 \item Il est facile à apprendre et à utiliser ;It is easy to learn and use.
|
|
romain@926
|
283 \item il est léger et performant ;
|
|
romain@926
|
284 \item il monte facilement en charge ;
|
|
romain@926
|
285 \item il est facile à personnaliser ;
|
|
bos@221
|
286 \end{itemize}
|
|
bos@221
|
287
|
|
romain@926
|
288 Si vous êtes déjà familier d'un outil de gestion de source, vous serez
|
|
romain@926
|
289 capable de l'utiliser en moins de 5 minutes. Sinon, ça ne sera pas beaucoup
|
|
romain@926
|
290 plus long\footnote{NdT: Pour appuyer le propos de l'auteur, je signale que
|
|
romain@926
|
291 j'utilise Mercurial comme outil d'initiation à la gestion de contrôle dans
|
|
romain@926
|
292 des travaux pratique à l'ESME Sudria (\url{http://www.esme.fr}) et que les
|
|
romain@926
|
293 élèves le prennent en main sans difficulté majeur malgré l'approche distribuée.}.
|
|
romain@926
|
294 Les commandes utilisées par Mercurial, comme ses fonctionnalités, sont
|
|
romain@926
|
295 généralement uniformes et cohérentes, et vous pouvez donc ainsi garder en tête
|
|
romain@926
|
296 simplement quelques règles générales, plutôt qu'un lot complexe d'exceptions.
|
|
romain@926
|
297
|
|
romain@926
|
298 Sur un petit projet, vous pouvez commencer à travailler avec Mercurial en
|
|
romain@926
|
299 quelques instants. Ajouter des modifications ou des branches, transférer
|
|
romain@926
|
300 ces modifications (localement ou via le réseau), et les opérations
|
|
romain@926
|
301 d'historique ou de statut sont aussi très rapide. Mercurial reste hors de
|
|
romain@926
|
302 votre chemin grâce à sa simplicité d'utilisation et sa rapidité d'exécution.
|
|
romain@926
|
303
|
|
romain@926
|
304 L'utilité de Mercurial ne se limite pas à des petits projets: il est
|
|
romain@926
|
305 aussi utilisé par des projets ayant des centaines ou même des milliers
|
|
romain@926
|
306 de contributeurs, avec plusieurs dizaines de milliers de fichiers, et des
|
|
romain@926
|
307 centaines de méga de code source.
|
|
romain@926
|
308
|
|
romain@926
|
309 Voici une liste non exhaustive des projets complexe ou critique utilisant
|
|
romain@926
|
310 mercurial :
|
|
romain@926
|
311 %TODO
|
|
romain@926
|
312 % For both spanish and english version, add the following examples:
|
|
romain@926
|
313 \begin{itemize}
|
|
romain@926
|
314 \item Firefox ;
|
|
romain@926
|
315 \item OpenSolaris ;
|
|
romain@926
|
316 \item OpenJDK (utilisant en outre l'extension ``forest'' pour gérer
|
|
romain@926
|
317 ses sous modules);
|
|
romain@926
|
318 \end{itemize}
|
|
romain@926
|
319 % TODO: Also add appropriate link.
|
|
romain@926
|
320
|
|
romain@926
|
321 Si les fonctionnalités coeur de Mercurial ne sont pas suffisantes pour vous,
|
|
romain@926
|
322 il est très aisé de construire dessus. Mercurial est adapté à l'utilisation
|
|
romain@926
|
323 au sein de script, et son implémentation interne en python, propre et claire,
|
|
romain@926
|
324 rend encore plus facile l'ajout de fonctionnalité sous forme d'extension. Il
|
|
romain@926
|
325 en existe déjà un certains nombres de très populaires et très utiles,
|
|
romain@926
|
326 dont le périmètre va de la recherche de bugs à l'amélioration des performances.
|
|
bos@221
|
327
|
|
romain@928
|
328 \section{Mercurial comparé aux autres outils}
|
|
romain@928
|
329
|
|
romain@928
|
330 Avant que vous n'alliez plus loin, comprenez bien que cette section
|
|
romain@928
|
331 reflète mes propres expériences, et elle est donc (j'ose le dire)
|
|
romain@928
|
332 peu objectives. Néanmoins, j'ai utilisé les outils de gestion de source
|
|
romain@928
|
333 listé ci dessous, dans la plupart des cas, pendant plusieurs années.
|
|
romain@928
|
334 %% TODO: Fussy translation.
|
|
bos@280
|
335
|
|
bos@221
|
336 \subsection{Subversion}
|
|
bos@221
|
337
|
|
romain@928
|
338 Subversion est un outil de gestion de source les plus populaire, il fût
|
|
romain@928
|
339 développé pour remplacer CVS. Il a une architecture client/server centralisée.
|
|
romain@928
|
340
|
|
romain@928
|
341 Subversion et Mercurial ont des noms de commandes très similaires pour
|
|
romain@928
|
342 les mêmes opérations, ainsi si vous êtes familier avec l'un, c'est facile
|
|
romain@928
|
343 d'apprendre l'autre. Ces deux outils sont portable sur les systèmes
|
|
romain@928
|
344 d'exploitation les plus populaires\footnote{NdT:Mercurial fonctionne sans problèmes
|
|
romain@928
|
345 sur OpenVMS à l'ESME Sudria \url{http://www.esme.fr}, compte tenu que Subversion a été
|
|
romain@928
|
346 développé en C, je ne suis pas sûr que son portage aurait été aussi aisé.}.
|
|
romain@928
|
347 %TODO: Backport this statement in english and spanish
|
|
romain@928
|
348
|
|
romain@928
|
349 Avant la version 1.5, Subversion n'offre aucune forme de support pour les fusions. Lors
|
|
romain@928
|
350 de l'écriture de ce livre, ces capacités de fusion sont nouvelle, et réputé pour être
|
|
romain@928
|
351 \href{http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword}{complexes
|
|
romain@928
|
352 et buggués}.
|
|
romain@928
|
353
|
|
romain@928
|
354 Mercurial dispose d'un avantages substantiel en terme de performance sur
|
|
romain@928
|
355 Subversion sur la plupart des opérations que j'ai pu testé. J'ai mesuré
|
|
romain@928
|
356 une différence de performance allant de deux à six fois plus rapide avec
|
|
romain@928
|
357 le système de stockage de fichier local de Subversion~1.4.3
|
|
romain@928
|
358 (\emph{ra\_local}), qui la méthode d'accès la plus rapide disponible. Dans
|
|
romain@928
|
359 un déploiement plus réaliste, impliquant un stockage réseau, Subversion
|
|
romain@928
|
360 serait encore plus désavantagé. Parce que la plupart des commandes Subversion
|
|
romain@928
|
361 doivent communiquer avec le serveur et que Subversion n'a pas de mécanisme
|
|
romain@928
|
362 de réplication, la capacité du serveur et la bande passante sont devenu des
|
|
romain@928
|
363 goulots d'étranglement pour les projets de taille moyenne ou grande.
|
|
romain@928
|
364
|
|
romain@928
|
365 En outre, Subversion implique une surchage substantielle dans le stockage local
|
|
romain@928
|
366 de certaines données, pour éviter des transactions avec le serveur, pour
|
|
romain@928
|
367 certaines opérations communes, tel que la recherche des fichier modifiées
|
|
romain@928
|
368 (\texttt{status}) et l'affichage des modifications par rapport la révision
|
|
romain@928
|
369 courante (\texttt{diff}). En conséquence, un répertoire de travail Subversion
|
|
romain@928
|
370 a souvent la même taille, ou est plus grand, que un dépôt Mercurial et son
|
|
romain@928
|
371 espace de travail, bien que le dépôt Mercurial contienne l'intégralité de
|
|
romain@928
|
372 l'historique.
|
|
romain@928
|
373
|
|
romain@928
|
374 Subversion est largement supportés par les outils tierses. Mercurial est
|
|
romain@928
|
375 actuellement encore en retrait de ce point de vue. L'écart se réduit, néanmoins,
|
|
romain@928
|
376 et en effet certains des outils graphiques sont maintenant supérieur à leurs
|
|
romain@928
|
377 équivalents Subversion. Comme Mercurial, Subversion dispose d'un excellent
|
|
romain@928
|
378 manuel utilisateur.
|
|
romain@928
|
379
|
|
romain@928
|
380 Parce que Subversion ne stocke par l'historique chez ses clients, il est
|
|
romain@928
|
381 parfaitement adapté à la gestion de projet qui doivent suivre un ensemble
|
|
romain@928
|
382 de large fichier binaires et opaques. Si vous suivez une cinquantaine de
|
|
romain@928
|
383 versions d'un fichier incompressible de 10MB, l'occupation disque coté client
|
|
romain@928
|
384 d'un projet sous Subversion restera à peu près constante. A l'inverse,
|
|
romain@928
|
385 l'occupation disque du même projet sous n'importe lequel des gestionnaire
|
|
romain@928
|
386 de source distribués grandira rapidement, proportionnellement aux nombres
|
|
romain@928
|
387 de versions, car les différences entre chaque révision sera très grande.
|
|
romain@928
|
388
|
|
romain@928
|
389 En outre, c'est souvent difficle ou, généralement, impossible de fusionner
|
|
romain@928
|
390 des différences dans un fichier binaire. La capacité de Subversion de
|
|
romain@928
|
391 vérouiller des fichiers, pour permettre à l'utilisateur d'être le seul
|
|
romain@928
|
392 à le mettre à jour (``commit'') temporairement, est avantage significatif
|
|
romain@928
|
393 dans un projet doté de beaucoup de fichiers binaire.
|
|
romain@928
|
394
|
|
romain@928
|
395 Mercurial peut importer l'historique depuis un dépôt Subversion. Il peut
|
|
romain@928
|
396 aussi exporter l'ensemble des révisions d'un projet vers un dépôt Subversion.
|
|
romain@928
|
397 Ceci rend très facile de ``tester l'eau'' et d'utiliser Mercurial et Subversion
|
|
romain@928
|
398 en parallèle, avant de décider de migrer vers Mercurial. La conversion de
|
|
romain@928
|
399 l'historique est incrémental, donc vous pouvez effectuer une conversion
|
|
romain@928
|
400 initial, puis de petites additions par la suite pour ajouter les nouvelles
|
|
romain@928
|
401 modifications.
|
|
bos@221
|
402
|
|
bos@221
|
403 \subsection{Git}
|
|
bos@221
|
404
|
|
romain@928
|
405 Git est un outil de gestion de source distribué qui fût développé pour gérer
|
|
romain@928
|
406 le code source de noyau de Linux. Comme Mercurial, sa conception initial à
|
|
romain@928
|
407 était inspiré par Monotone.
|
|
romain@928
|
408
|
|
romain@928
|
409 Git dispose d'un ensemble conséquent de command, avec plus de~139 commandes
|
|
romain@928
|
410 individuels pour la version~1.5.0. Il a aussi la réputation d'être difficile
|
|
romain@928
|
411 à apprendre. Comparé à Git, le point fort de Mercurial est clairement sa
|
|
romain@928
|
412 simplicité.
|
|
romain@928
|
413
|
|
romain@928
|
414 En terme de performance, Git est extrêmement rapide. Dans la plupart des
|
|
romain@928
|
415 cas, il est plus rapide que Mercurial, tout du moins sur Linux, alors que
|
|
romain@928
|
416 Mercurial peut être plus performant sur d'autres opérations. Néanmoins, sur
|
|
romain@928
|
417 Windows, les performances et le niveau de support général fourni par Git,
|
|
romain@928
|
418 au moment de l'écriture de cet ouvrage, bien derrière celui de Mercurial.
|
|
romain@928
|
419
|
|
romain@928
|
420 Alors que le dépôt Mercurial ne demande aucune maintenance, un dépôt Git
|
|
romain@928
|
421 exige d'exécuter manuellement et régulièrement la commande ``repacks'' sur
|
|
romain@928
|
422 ces métadonnées. Sans ceci, les performances de git se dégrade, et la
|
|
romain@928
|
423 consommation de l'espace disque augmente rapidement. Un serveur qui contient
|
|
romain@928
|
424 plusieurs dépôt Git qui ne sont pas régulièrement et fréquement ``repacked''
|
|
romain@928
|
425 deviendra un vrai problème lors des ``backups'' du disque, et il y eu des
|
|
romain@928
|
426 cas, où un ``backup'' journalier pouvait durer plus de~24 heures. Un dépôt
|
|
romain@928
|
427 fraichement ``repacked'' sera légèrement plus petit que un dépôt Mercurial,
|
|
romain@928
|
428 mais un dépôt non ``repacked'' est beaucoup plus grand.
|
|
romain@928
|
429
|
|
romain@928
|
430 Le coeur de Git est écrit en C. La plupart des commandes Git sont implémentés
|
|
romain@928
|
431 sous forme de script Shell ou Perl, et la qualité de ces scripts varient
|
|
romain@928
|
432 grandement. J'ai plusieurs fois constaté que certains de ces scripts étaient
|
|
romain@928
|
433 chargé en mémoire aveuglément et que la présence d'erreurs pouvait s'avérer
|
|
romain@928
|
434 fatal.
|
|
romain@928
|
435
|
|
romain@928
|
436 Mercurial peut importer l'historique d'un dépôt Git.
|
|
bos@280
|
437
|
|
bos@221
|
438 \subsection{CVS}
|
|
bos@221
|
439
|
|
romain@928
|
440 CVS est probablement l'outil de gestion de source le plus utilisé aujourd'hui
|
|
romain@928
|
441 dans le monde. À cause de son manque de properté interne, il n'est plus
|
|
romain@928
|
442 maintenu depuis plusieurs années.
|
|
romain@928
|
443
|
|
romain@928
|
444 Il a une architecture client/serveur centralisé. Il ne groupe pas les
|
|
romain@928
|
445 modifications de fichiers dans une opération de ``commit'' atomique, ce
|
|
romain@928
|
446 qui permet à ses utilisateurs de ``casser le \textit{build}'' assez
|
|
romain@928
|
447 facilement : une personne peut effectuer une opération de ``commit''
|
|
romain@928
|
448 sans problème puis être bloqué par besoin de fusion, avec comme conséquence
|
|
romain@928
|
449 néfaste, que les autres utilisateurs ne récupèreront qu'une partie de ses
|
|
romain@928
|
450 modifications. Ce problème affecte aussi la manière de travailler avec
|
|
romain@928
|
451 l'historique du projet. Si vous voulez voir toutes les modifications d'une
|
|
romain@928
|
452 personne du projet, vous devrez injecter manuellement les descriptions et les
|
|
romain@928
|
453 \textit{timestamps} des modifications de chacun des fichiers impliqués (si
|
|
romain@928
|
454 vous savez au moins quels sont ces fichiers).
|
|
romain@928
|
455
|
|
romain@928
|
456 CVS a une notion étrange des \textit{tags} et des branches que je n'essayerais
|
|
romain@928
|
457 même de décrire ici. Il ne supporte pas bien les opérations de renommage d'un
|
|
romain@928
|
458 fichier ou de répertoire, ce qui facilite la corruption de son dépôt. Il n'a
|
|
romain@928
|
459 presque pas pour ainsi dire de contrôle de cohérence interne, il est donc
|
|
romain@928
|
460 pratiquement impossible de dire si un dépôt est corrompu ni à quel point. Je
|
|
romain@928
|
461 ne recommanderais pas CVS pour un projet existant ou nouveau.
|
|
romain@928
|
462
|
|
romain@928
|
463 Mercurial peut importer l'historique d'un projet CVS. Néanmoins, il y a
|
|
romain@928
|
464 quelques princinpes à respecter; ce qui est vrai aussi pour les autres
|
|
romain@928
|
465 outils d'import de projet CVS. À cause de l'absence de ``commit'' atomique
|
|
romain@928
|
466 et gestion de version de l'arboresence, il n'est pas possible de reconstruire
|
|
romain@928
|
467 de manière précise l'ensemble de l'historique. Un travail de ``devinette''
|
|
romain@928
|
468 est donc nécessaire, et les fichiers renommées ne sont pas détectés. Parce
|
|
romain@928
|
469 que une bonne part de l'administration d'un dépôt CVS est effectué manuellement,
|
|
romain@928
|
470 et est donc, sujette à erreur, il est courant que les impots CVS rencontre
|
|
romain@928
|
471 de nombreux problèmes avec les dépôt corrompues (des \textit{timestamps}
|
|
romain@928
|
472 de révision complètement buggé et des fichiers vérouillés depuis des années
|
|
romain@928
|
473 sont deux des problèmes les moins intéressants dont je me souvienne).
|
|
romain@928
|
474
|
|
romain@928
|
475 Mercurial peut importer l'historique depuis un dépôt CVS.
|
|
bos@280
|
476
|
|
bos@221
|
477 \subsection{Commercial tools}
|
|
bos@221
|
478
|
|
bos@221
|
479 Perforce has a centralised client/server architecture, with no
|
|
bos@221
|
480 client-side caching of any data. Unlike modern revision control
|
|
bos@221
|
481 tools, Perforce requires that a user run a command to inform the
|
|
bos@221
|
482 server about every file they intend to edit.
|
|
bos@221
|
483
|
|
bos@221
|
484 The performance of Perforce is quite good for small teams, but it
|
|
bos@221
|
485 falls off rapidly as the number of users grows beyond a few dozen.
|
|
bos@221
|
486 Modestly large Perforce installations require the deployment of
|
|
bos@221
|
487 proxies to cope with the load their users generate.
|
|
bos@16
|
488
|
|
bos@280
|
489
|
|
bos@280
|
490 \subsection{Choosing a revision control tool}
|
|
bos@280
|
491
|
|
bos@280
|
492 With the exception of CVS, all of the tools listed above have unique
|
|
bos@280
|
493 strengths that suit them to particular styles of work. There is no
|
|
bos@280
|
494 single revision control tool that is best in all situations.
|
|
bos@280
|
495
|
|
bos@280
|
496 As an example, Subversion is a good choice for working with frequently
|
|
bos@280
|
497 edited binary files, due to its centralised nature and support for
|
|
bos@318
|
498 file locking.
|
|
bos@280
|
499
|
|
bos@280
|
500 I personally find Mercurial's properties of simplicity, performance,
|
|
bos@280
|
501 and good merge support to be a compelling combination that has served
|
|
bos@280
|
502 me well for several years.
|
|
bos@280
|
503
|
|
bos@280
|
504
|
|
bos@280
|
505 \section{Switching from another tool to Mercurial}
|
|
bos@280
|
506
|
|
bos@280
|
507 Mercurial is bundled with an extension named \hgext{convert}, which
|
|
bos@280
|
508 can incrementally import revision history from several other revision
|
|
bos@280
|
509 control tools. By ``incremental'', I mean that you can convert all of
|
|
bos@280
|
510 a project's history to date in one go, then rerun the conversion later
|
|
bos@280
|
511 to obtain new changes that happened after the initial conversion.
|
|
bos@280
|
512
|
|
bos@280
|
513 The revision control tools supported by \hgext{convert} are as
|
|
bos@280
|
514 follows:
|
|
bos@280
|
515 \begin{itemize}
|
|
bos@280
|
516 \item Subversion
|
|
bos@280
|
517 \item CVS
|
|
bos@280
|
518 \item Git
|
|
bos@280
|
519 \item Darcs
|
|
bos@280
|
520 \end{itemize}
|
|
bos@280
|
521
|
|
bos@280
|
522 In addition, \hgext{convert} can export changes from Mercurial to
|
|
bos@280
|
523 Subversion. This makes it possible to try Subversion and Mercurial in
|
|
bos@280
|
524 parallel before committing to a switchover, without risking the loss
|
|
bos@280
|
525 of any work.
|
|
bos@280
|
526
|
|
bos@280
|
527 The \hgxcmd{conver}{convert} command is easy to use. Simply point it
|
|
bos@280
|
528 at the path or URL of the source repository, optionally give it the
|
|
bos@280
|
529 name of the destination repository, and it will start working. After
|
|
bos@280
|
530 the initial conversion, just run the same command again to import new
|
|
bos@280
|
531 changes.
|
|
bos@280
|
532
|
|
bos@280
|
533
|
|
bos@16
|
534 %%% Local Variables:
|
|
bos@16
|
535 %%% mode: latex
|
|
bos@16
|
536 %%% TeX-master: "00book"
|
|
bos@16
|
537 %%% End:
|
