| 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@924
|
79 La gestion de source 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@924
|
81 acronymes que vous rencontrerez le plus souvent:
|
|
bos@217
|
82 \begin{itemize}
|
|
romain@924
|
83 \item \textit{Revision control (RCS)} ;
|
|
romain@924
|
84 \item Software configuration management (SCM), ou \textit{configuration management} ;
|
|
romain@924
|
85 \item \textit{Source code management} ;
|
|
romain@924
|
86 \item \textit{Source code control}, ou \textit{source control} ;
|
|
romain@924
|
87 \item \textit{Version control (VCS)}.
|
|
bos@217
|
88 \end{itemize}
|
|
romain@924
|
89
|
|
romain@924
|
90 \notebox {
|
|
romain@924
|
91 Note du traducteur : J'ai conservé la liste des noms en anglais pour des raisons de commodité (ils sont plus ``googelable''). J'ai choisi de conserver le terme ``gestion de sources'' comme traduction unique dans l'ensemble du document.
|
|
romain@924
|
92
|
|
romain@924
|
93 En outre, j'ai opté pour conserver l'ensemble des opérations de Mercurial (commit, push, pull,...) en anglais, là aussi pour faciliter la lecture d'autres documents en anglais, et
|
|
romain@924
|
94 aussi son utilisation.
|
|
romain@924
|
95 }
|
|
romain@924
|
96
|
|
romain@924
|
97 Certains personnes prétendent que ces termes ont en fait des sens
|
|
romain@924
|
98 différents mais en pratique ils se recouvrent tellement qu'il n'y a pas
|
|
romain@924
|
99 réellement de manière pertinente de les distinguer.
|
|
romain@924
|
100
|
|
romain@924
|
101 \section{Une courte histoire de la gestion de source}
|
|
romain@924
|
102
|
|
romain@924
|
103 Le plus célèbre des anciens outils de gestion de source est \textit{SCCS (Source
|
|
romain@924
|
104 Code Control System)}, que Marc Rochkind conçu dans les laboratoire de recherche de Bell
|
|
romain@924
|
105 (\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
|
106 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
|
107 des fichiers, et plus tard, oublie de le dévérouiller; empêchant n'importe qui d'autre de
|
|
romain@924
|
108 travailler sur ces fichiers sans l'aide de l'administrateur...
|
|
romain@924
|
109
|
|
romain@924
|
110 Walter Tichy a développé une alternative libre à \textit{SCCS} au début des années 80, qu'il
|
|
romain@924
|
111 nomma \textit{RSC (Revison Control System)}. Comme \textit{SCCS}, \textit{RCS}
|
|
romain@924
|
112 demander aux développeurs de travailler sur le même répertoire partagé, et de vérouiller les
|
|
romain@924
|
113 fichiers pour se prémunir de tout conflit issue de modifications concurrentes.
|
|
romain@924
|
114
|
|
romain@924
|
115 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
|
116
|
|
romain@926
|
117 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
|
118
|
|
romain@926
|
119 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
|
120
|
|
romain@926
|
121 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
|
122
|
|
romain@926
|
123
|
|
romain@926
|
124 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
|
125
|
|
romain@926
|
126 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
|
127
|
|
romain@926
|
128 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
|
129
|
|
romain@926
|
130 \section{Tendances de la gestion de source}
|
|
romain@926
|
131
|
|
romain@926
|
132 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
|
133
|
|
romain@926
|
134 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
|
135
|
|
romain@926
|
136 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
|
137
|
|
romain@926
|
138 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
|
139
|
|
romain@926
|
140 \section{Quelques avantages des gestionnaire de source distribué}
|
|
romain@926
|
141
|
|
romain@926
|
142 Même si les gestionnaire de source distribué sont depuis plusieurs années
|
|
romain@926
|
143 assez robuste et aussi utilisable que leur prédécésseurs, les utilisateurs
|
|
romain@926
|
144 d'autres outils n'ont pas encore étaient sensibilisé. Les gestionnaires
|
|
romain@926
|
145 de sources distribué se distingue particulièrement de leurs équivalents
|
|
romain@926
|
146 centralisé de nombreuse manière.
|
|
romain@926
|
147
|
|
romain@926
|
148 Pour un développeur individuel, ils restent beaucoup plus rapide que les
|
|
romain@926
|
149 outils centralisés. Cela pour une raison simple: un outil centralisé doit
|
|
romain@926
|
150 toujours discuter à travers le réseau pour la plupart des opérations, car
|
|
romain@926
|
151 presque toutes les métadonnées sont stockées sur la seule copie du serveur
|
|
romain@926
|
152 central. Un outil distribué stocke toute ses métadonnées localement. À tâche
|
|
romain@926
|
153 égale, effectuer un échange avec le réseau ajoute un délai aux outils
|
|
romain@926
|
154 centralisés. Ne sous estimez pas la valeur d'un outil rapide: vous allez
|
|
romain@926
|
155 passer beaucoup de temps à interagir avec un logiciel de gestion de sources.
|
|
romain@926
|
156
|
|
romain@926
|
157 Les outils distribué sont complètement indépendant des aléas de votre serveur,
|
|
romain@926
|
158 encore une fois car ils répliquent les métadonnées à tellement d'endoit. Si
|
|
romain@926
|
159 votre serveur central prend feu, vous avez intérêt à ce que les média de
|
|
romain@926
|
160 sauvegarde soient fiable, et que votre dernier ``backup'' soit récent et
|
|
romain@926
|
161 fonctionne sans problème. Avec un outil distribué, vous avez autant de
|
|
romain@926
|
162 ``backup'' que de contributeurs.
|
|
romain@926
|
163
|
|
romain@926
|
164 En outre, la fiabilité de votre réseau affectera beaucoup moins les
|
|
romain@926
|
165 outils distribué. Vous ne pouvez même pas utiliser un outil centralisé
|
|
romain@926
|
166 sans connexion réseau, à l'exception de quelques commandes, très limités.
|
|
romain@926
|
167 Avec un outil distribué, si vous connexion réseau tombe pendant que vous
|
|
romain@926
|
168 travaillez, vous pouvez ne même pas vous en rendre compte. La seule chose
|
|
romain@926
|
169 que vous ne serez pas capable de faire sera de communiquer avec des dépôts
|
|
romain@926
|
170 distants, opération somme toute assez rare par comparaison aux opérations
|
|
romain@926
|
171 locales. Si vous avez une (TODO:far-flung???) équipe de collaborateurs,
|
|
romain@926
|
172 ceci peut être significatif.
|
|
romain@926
|
173
|
|
romain@926
|
174 \subsection{Avantages pour les projets \textit{Open Source}}
|
|
romain@926
|
175
|
|
romain@926
|
176 Si vous prenez goût à un projet \textit{Open Source} et que vous
|
|
romain@926
|
177 décidez de commencer à toucher à son code, et que le projet utilise
|
|
romain@926
|
178 un gestionnaire de source distribué, vous êtes immédiatement un "pair"
|
|
romain@926
|
179 avec les personnes formant le ``coeur'' du projet. Si ils publient
|
|
romain@926
|
180 leurs dépôts, vous pouvez immédiatement copier leurs historiques de
|
|
romain@926
|
181 projet, faire des modifications, enregistrer votre travail en utilisant
|
|
romain@926
|
182 les même outils qu'eux. Par comparaison, avec un outil centralisé, vous
|
|
romain@926
|
183 devez utiliser un logiciel en mode ``lecture seule'' à moins que
|
|
romain@926
|
184 quelqu'un ne vous donne les privilèges de ``commit'' sur le serveur
|
|
romain@926
|
185 central. Avant ça, vous ne serez pas capable d'enregistrer vos
|
|
romain@926
|
186 modifications, et vos propres modifications risqueront de se
|
|
romain@926
|
187 corrompre chaque fois que vous essayerez de mettre à jour à votre
|
|
romain@926
|
188 espace de travail avec le serveur central.
|
|
romain@926
|
189
|
|
romain@926
|
190 \subsubsection{Le non-problème du \textit{fork}}
|
|
romain@926
|
191
|
|
romain@926
|
192 Il a été souvent suggeré que les gestionnaires de source distribués
|
|
romain@926
|
193 posent un risque pour les projets \textit{Open Source} car ils
|
|
romain@926
|
194 facilitent grandement la création de ``fork''\footnote{NdT:Création
|
|
romain@926
|
195 d'une version alternative du logiciel}. %%% TODO: Link to Wikipedia
|
|
romain@926
|
196 Un ``fork'' apparait quand il y des divergences d'opinion ou d'attitude
|
|
romain@926
|
197 au sein d'un groupe de développeurs qui aboutit à la décision de ne
|
|
romain@926
|
198 plus travail ensemble. Chacun parti s'empare d'une copie plus ou moins
|
|
romain@926
|
199 complète du code source du projet et continue dans sa propre direction.
|
|
romain@926
|
200
|
|
romain@926
|
201 Parfois ces différents partis décide de se réconcilier. Avec un
|
|
romain@926
|
202 serveur central, l'aspect \emph{technique} de cette réconciliation
|
|
romain@926
|
203 est un processus douloureux, et essentiellement manuel. Vous devez
|
|
romain@926
|
204 décider quelle modification est ``la gagnante'', et replacer, par un
|
|
romain@926
|
205 moyen ou un autre, les modifications de l'autre équipe dans l'arboresence
|
|
romain@926
|
206 du projet. Ceci implique généralement la perte d'une partie l'historique
|
|
romain@926
|
207 d'un des partie, ou même des deux.
|
|
romain@926
|
208
|
|
romain@926
|
209 Ce que les outils distribués permettent à ce sujet est probablement
|
|
romain@926
|
210 la \emph{meilleur} façon de développer un projet. Chaque modification
|
|
romain@926
|
211 que vous effectué est potentiellement un ``fork''. La grande force de
|
|
romain@926
|
212 cette approche est que les gestionnaire de source distribué doit être
|
|
romain@926
|
213 vraiment très efficase pour \emph{fusionner}\footnote{NdT:j'ai choisi de
|
|
romain@926
|
214 traduire ici \textit{merging} par ``fusionner'' pour des raisons de clarté}
|
|
romain@926
|
215 des ``forks'', car les ``forks'', dans ce contexte, arrivent tout le
|
|
romain@926
|
216 temps.
|
|
romain@926
|
217
|
|
romain@926
|
218 Si chaque altération que n'importe qui effectue, à tout moment, est vu
|
|
romain@926
|
219 comme un ``fork'' à fusionner, alors ce que le monde de l'\textit{Open
|
|
romain@926
|
220 Source} voit comme un ``fork'' devient \emph{uniquement} une problématique
|
|
romain@926
|
221 social. En fait, les outils de gestion de source distribué \emph{réduisent}
|
|
romain@926
|
222 les chances de ``fork'':
|
|
bos@220
|
223 \begin{itemize}
|
|
romain@926
|
224 \item Ils éliminent la distinction social qu'imposent les outils centralisés
|
|
romain@926
|
225 entre les membres du projets (ce qui ont accès au ``comit'') et ceux de l'
|
|
romain@926
|
226 extérieur (ce qui ne l'ont pas).
|
|
romain@926
|
227 \item Ils rendent plus facile la réconciliation après un ``fork'' social, car
|
|
romain@926
|
228 tout ce qu'elle implique est juste une simple fusion.
|
|
bos@220
|
229 \end{itemize}
|
|
bos@220
|
230
|
|
romain@926
|
231 Certaines personnes font de la résistance envers les gestionnaires de source
|
|
romain@926
|
232 distribués parce qu'ils veulent garder un contrôle ferme de leur projet, et
|
|
romain@926
|
233 ils pensent que les outils centralisés leur fournissent ce contrôle. Néanmoins,
|
|
romain@926
|
234 si c'est votre cas, sachez que si vous publier votre dépôt CVS ou Subversion
|
|
romain@926
|
235 de manière publique, il existe une quantité d'outils disponibles pour récupérer
|
|
romain@926
|
236 entièrement votre projet et son historique (quoique lentement) et le récréer
|
|
romain@926
|
237 ailleurs, sans votre contrôle. En fait, votre contrôle sur votre projet est
|
|
romain@926
|
238 illusoire, vous ne faites qu'interdire à vos collaborateurs de travailler
|
|
romain@926
|
239 de manière fluide, en disposant d'un miroir ou d'un ``fork'' de votre
|
|
romain@926
|
240 historique.
|
|
romain@926
|
241 %%%TODO: Fussy, those last sentences are not really well translated:
|
|
romain@926
|
242 %However, if you're of this belief, and you publish your CVS or Subversion
|
|
romain@926
|
243 %repositories publically, there are plenty of tools available that can pull
|
|
romain@926
|
244 %out your entire project's history (albeit slowly) and recreate it somewhere
|
|
romain@926
|
245 %that you don't control. So while your control in this case is illusory, you are
|
|
romain@926
|
246 %forgoing the ability to fluidly collaborate with whatever people feel
|
|
romain@926
|
247 %compelled to mirror and fork your history.
|
|
romain@926
|
248
|
|
romain@926
|
249 \subsection{Avantages pour les projets commerciaux}
|
|
romain@926
|
250
|
|
romain@926
|
251 Beaucoup de projets commerciaux sont réalisé par des équipes éparpillées
|
|
romain@926
|
252 à travers le globe. Les contributeurs qui sont loin du serveur central
|
|
romain@926
|
253 devront subir des commandes lentes et même parfois peu fiable. Les
|
|
romain@926
|
254 solutions propriétaires gestion de source, tentent de palier ce problème
|
|
romain@926
|
255 avec des réplications de site distant qui sont à la fois coûteuses à mettre
|
|
romain@926
|
256 en place et lourdes à administrer. A un système distribué ne souffre pas
|
|
romain@926
|
257 de ce genre de problèmes. En outre, il est très aisé de mettre en place
|
|
romain@926
|
258 plusieurs serveurs de références, disont un par site, de manière à ce qu'il
|
|
romain@926
|
259 n'y est pas de communication redondante entre les dépôts, sur une connexion
|
|
romain@926
|
260 longue distance souvent onéreuse.
|
|
romain@926
|
261
|
|
romain@926
|
262 Les systèmes de gestion de source supportent généralement assez mal la
|
|
romain@926
|
263 monté en charge. Ce n'est pas rare pour un gestionnaire de source centralisé
|
|
romain@926
|
264 pourtant onéreux de s'effondrer sous la charge combinée de juste une douzaine
|
|
romain@926
|
265 d'utilisateurs concurrents. Une fois encore, la réponse à cette problématique
|
|
romain@926
|
266 est généralement encore la mise en place d'un ensemble complexe de serveurs
|
|
romain@926
|
267 synchronisé par un mécanisme de réplication. Dans le cas d'un gestionnaire
|
|
romain@926
|
268 de source distribué, la charge du serveur central--- si vous avez un--- est
|
|
romain@926
|
269 plusieurs fois inférieur (car toutes les données sont déjà répliqués ailleurs),
|
|
romain@926
|
270 un simple server, pas très cher, peut gérer les besoins d'une plus grande
|
|
romain@926
|
271 équipe, et la réplication pour balancer la charge devient simplement le
|
|
romain@926
|
272 travail d'un simple script.
|
|
romain@926
|
273
|
|
romain@926
|
274 Si vous avez des employés sur le terrain, entrain de chercher à résoudre sur
|
|
romain@926
|
275 le site d'un client, ils bénéficieront aussi d'un gestionnaire de source
|
|
romain@926
|
276 distribués. Cet outil leur permettra de générer des versions personnalisées,
|
|
romain@926
|
277 d'essayer différentes solutions, en les isolant aisément les une des autres,
|
|
romain@926
|
278 et de recherche efficasement à travers l'historique des sources, la cause
|
|
romain@926
|
279 des bugs ou des régression, tout ceci sans avoir besoin de la moindre
|
|
romain@926
|
280 connexion au réseau de votre compagnie.
|
|
romain@926
|
281
|
|
romain@926
|
282 \section{Pourquoi choisir Mercurial?}
|
|
romain@926
|
283
|
|
romain@926
|
284 Mercurial a plusieurs caractéristiques qui en font un choix particulièrement
|
|
romain@926
|
285 pertinent pour la gestion de source:
|
|
bos@221
|
286 \begin{itemize}
|
|
romain@926
|
287 \item Il est facile à apprendre et à utiliser ;It is easy to learn and use.
|
|
romain@926
|
288 \item il est léger et performant ;
|
|
romain@926
|
289 \item il monte facilement en charge ;
|
|
romain@926
|
290 \item il est facile à personnaliser ;
|
|
bos@221
|
291 \end{itemize}
|
|
bos@221
|
292
|
|
romain@926
|
293 Si vous êtes déjà familier d'un outil de gestion de source, vous serez
|
|
romain@926
|
294 capable de l'utiliser en moins de 5 minutes. Sinon, ça ne sera pas beaucoup
|
|
romain@926
|
295 plus long\footnote{NdT: Pour appuyer le propos de l'auteur, je signale que
|
|
romain@926
|
296 j'utilise Mercurial comme outil d'initiation à la gestion de contrôle dans
|
|
romain@926
|
297 des travaux pratique à l'ESME Sudria (\url{http://www.esme.fr}) et que les
|
|
romain@926
|
298 élèves le prennent en main sans difficulté majeur malgré l'approche distribuée.}.
|
|
romain@926
|
299 Les commandes utilisées par Mercurial, comme ses fonctionnalités, sont
|
|
romain@926
|
300 généralement uniformes et cohérentes, et vous pouvez donc ainsi garder en tête
|
|
romain@926
|
301 simplement quelques règles générales, plutôt qu'un lot complexe d'exceptions.
|
|
romain@926
|
302
|
|
romain@926
|
303 Sur un petit projet, vous pouvez commencer à travailler avec Mercurial en
|
|
romain@926
|
304 quelques instants. Ajouter des modifications ou des branches, transférer
|
|
romain@926
|
305 ces modifications (localement ou via le réseau), et les opérations
|
|
romain@926
|
306 d'historique ou de statut sont aussi très rapide. Mercurial reste hors de
|
|
romain@926
|
307 votre chemin grâce à sa simplicité d'utilisation et sa rapidité d'exécution.
|
|
romain@926
|
308
|
|
romain@926
|
309 L'utilité de Mercurial ne se limite pas à des petits projets: il est
|
|
romain@926
|
310 aussi utilisé par des projets ayant des centaines ou même des milliers
|
|
romain@926
|
311 de contributeurs, avec plusieurs dizaines de milliers de fichiers, et des
|
|
romain@926
|
312 centaines de méga de code source.
|
|
romain@926
|
313
|
|
romain@926
|
314 Voici une liste non exhaustive des projets complexe ou critique utilisant
|
|
romain@926
|
315 mercurial :
|
|
romain@926
|
316 %TODO
|
|
romain@926
|
317 % For both spanish and english version, add the following examples:
|
|
romain@926
|
318 \begin{itemize}
|
|
romain@926
|
319 \item Firefox ;
|
|
romain@926
|
320 \item OpenSolaris ;
|
|
romain@926
|
321 \item OpenJDK (utilisant en outre l'extension ``forest'' pour gérer
|
|
romain@926
|
322 ses sous modules);
|
|
romain@926
|
323 \end{itemize}
|
|
romain@926
|
324 % TODO: Also add appropriate link.
|
|
romain@926
|
325
|
|
romain@926
|
326 Si les fonctionnalités coeur de Mercurial ne sont pas suffisantes pour vous,
|
|
romain@926
|
327 il est très aisé de construire dessus. Mercurial est adapté à l'utilisation
|
|
romain@926
|
328 au sein de script, et son implémentation interne en python, propre et claire,
|
|
romain@926
|
329 rend encore plus facile l'ajout de fonctionnalité sous forme d'extension. Il
|
|
romain@926
|
330 en existe déjà un certains nombres de très populaires et très utiles,
|
|
romain@926
|
331 dont le périmètre va de la recherche de bugs à l'amélioration des performances.
|
|
bos@221
|
332
|
|
bos@221
|
333 \section{Mercurial compared with other tools}
|
|
bos@221
|
334
|
|
bos@221
|
335 Before you read on, please understand that this section necessarily
|
|
bos@221
|
336 reflects my own experiences, interests, and (dare I say it) biases. I
|
|
bos@221
|
337 have used every one of the revision control tools listed below, in
|
|
bos@221
|
338 most cases for several years at a time.
|
|
bos@221
|
339
|
|
bos@280
|
340
|
|
bos@221
|
341 \subsection{Subversion}
|
|
bos@221
|
342
|
|
bos@221
|
343 Subversion is a popular revision control tool, developed to replace
|
|
bos@221
|
344 CVS. It has a centralised client/server architecture.
|
|
bos@221
|
345
|
|
bos@221
|
346 Subversion and Mercurial have similarly named commands for performing
|
|
bos@280
|
347 the same operations, so if you're familiar with one, it is easy to
|
|
bos@280
|
348 learn to use the other. Both tools are portable to all popular
|
|
bos@221
|
349 operating systems.
|
|
bos@221
|
350
|
|
bos@315
|
351 Prior to version 1.5, Subversion had no useful support for merges.
|
|
bos@315
|
352 At the time of writing, its merge tracking capability is new, and known to be
|
|
bos@315
|
353 \href{http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword}{complicated
|
|
bos@315
|
354 and buggy}.
|
|
bos@256
|
355
|
|
bos@221
|
356 Mercurial has a substantial performance advantage over Subversion on
|
|
bos@221
|
357 every revision control operation I have benchmarked. I have measured
|
|
bos@221
|
358 its advantage as ranging from a factor of two to a factor of six when
|
|
bos@221
|
359 compared with Subversion~1.4.3's \emph{ra\_local} file store, which is
|
|
simon@313
|
360 the fastest access method available. In more realistic deployments
|
|
bos@221
|
361 involving a network-based store, Subversion will be at a substantially
|
|
bos@256
|
362 larger disadvantage. Because many Subversion commands must talk to
|
|
bos@256
|
363 the server and Subversion does not have useful replication facilities,
|
|
bos@280
|
364 server capacity and network bandwidth become bottlenecks for modestly
|
|
bos@280
|
365 large projects.
|
|
bos@280
|
366
|
|
bos@280
|
367 Additionally, Subversion incurs substantial storage overhead to avoid
|
|
bos@280
|
368 network transactions for a few common operations, such as finding
|
|
bos@280
|
369 modified files (\texttt{status}) and displaying modifications against
|
|
bos@280
|
370 the current revision (\texttt{diff}). As a result, a Subversion
|
|
bos@280
|
371 working copy is often the same size as, or larger than, a Mercurial
|
|
bos@280
|
372 repository and working directory, even though the Mercurial repository
|
|
bos@280
|
373 contains a complete history of the project.
|
|
bos@280
|
374
|
|
bos@280
|
375 Subversion is widely supported by third party tools. Mercurial
|
|
bos@280
|
376 currently lags considerably in this area. This gap is closing,
|
|
bos@280
|
377 however, and indeed some of Mercurial's GUI tools now outshine their
|
|
bos@280
|
378 Subversion equivalents. Like Mercurial, Subversion has an excellent
|
|
bos@280
|
379 user manual.
|
|
bos@280
|
380
|
|
bos@280
|
381 Because Subversion doesn't store revision history on the client, it is
|
|
bos@280
|
382 well suited to managing projects that deal with lots of large, opaque
|
|
bos@280
|
383 binary files. If you check in fifty revisions to an incompressible
|
|
bos@280
|
384 10MB file, Subversion's client-side space usage stays constant The
|
|
bos@280
|
385 space used by any distributed SCM will grow rapidly in proportion to
|
|
bos@280
|
386 the number of revisions, because the differences between each revision
|
|
bos@280
|
387 are large.
|
|
bos@280
|
388
|
|
bos@280
|
389 In addition, it's often difficult or, more usually, impossible to
|
|
bos@280
|
390 merge different versions of a binary file. Subversion's ability to
|
|
bos@280
|
391 let a user lock a file, so that they temporarily have the exclusive
|
|
bos@280
|
392 right to commit changes to it, can be a significant advantage to a
|
|
bos@280
|
393 project where binary files are widely used.
|
|
bos@280
|
394
|
|
bos@280
|
395 Mercurial can import revision history from a Subversion repository.
|
|
bos@280
|
396 It can also export revision history to a Subversion repository. This
|
|
bos@280
|
397 makes it easy to ``test the waters'' and use Mercurial and Subversion
|
|
bos@280
|
398 in parallel before deciding to switch. History conversion is
|
|
bos@280
|
399 incremental, so you can perform an initial conversion, then small
|
|
bos@280
|
400 additional conversions afterwards to bring in new changes.
|
|
bos@280
|
401
|
|
bos@221
|
402
|
|
bos@221
|
403 \subsection{Git}
|
|
bos@221
|
404
|
|
bos@221
|
405 Git is a distributed revision control tool that was developed for
|
|
bos@221
|
406 managing the Linux kernel source tree. Like Mercurial, its early
|
|
bos@221
|
407 design was somewhat influenced by Monotone.
|
|
bos@221
|
408
|
|
bos@280
|
409 Git has a very large command set, with version~1.5.0 providing~139
|
|
bos@280
|
410 individual commands. It has something of a reputation for being
|
|
bos@280
|
411 difficult to learn. Compared to Git, Mercurial has a strong focus on
|
|
bos@280
|
412 simplicity.
|
|
bos@280
|
413
|
|
bos@280
|
414 In terms of performance, Git is extremely fast. In several cases, it
|
|
bos@280
|
415 is faster than Mercurial, at least on Linux, while Mercurial performs
|
|
bos@280
|
416 better on other operations. However, on Windows, the performance and
|
|
bos@280
|
417 general level of support that Git provides is, at the time of writing,
|
|
bos@280
|
418 far behind that of Mercurial.
|
|
bos@221
|
419
|
|
bos@221
|
420 While a Mercurial repository needs no maintenance, a Git repository
|
|
bos@221
|
421 requires frequent manual ``repacks'' of its metadata. Without these,
|
|
bos@221
|
422 performance degrades, while space usage grows rapidly. A server that
|
|
bos@221
|
423 contains many Git repositories that are not rigorously and frequently
|
|
bos@221
|
424 repacked will become heavily disk-bound during backups, and there have
|
|
bos@221
|
425 been instances of daily backups taking far longer than~24 hours as a
|
|
bos@221
|
426 result. A freshly packed Git repository is slightly smaller than a
|
|
bos@221
|
427 Mercurial repository, but an unpacked repository is several orders of
|
|
bos@221
|
428 magnitude larger.
|
|
bos@221
|
429
|
|
bos@221
|
430 The core of Git is written in C. Many Git commands are implemented as
|
|
bos@221
|
431 shell or Perl scripts, and the quality of these scripts varies widely.
|
|
bos@280
|
432 I have encountered several instances where scripts charged along
|
|
bos@221
|
433 blindly in the presence of errors that should have been fatal.
|
|
bos@221
|
434
|
|
bos@280
|
435 Mercurial can import revision history from a Git repository.
|
|
bos@280
|
436
|
|
bos@280
|
437
|
|
bos@221
|
438 \subsection{CVS}
|
|
bos@221
|
439
|
|
bos@221
|
440 CVS is probably the most widely used revision control tool in the
|
|
bos@280
|
441 world. Due to its age and internal untidiness, it has been only
|
|
bos@280
|
442 lightly maintained for many years.
|
|
bos@221
|
443
|
|
bos@221
|
444 It has a centralised client/server architecture. It does not group
|
|
bos@221
|
445 related file changes into atomic commits, making it easy for people to
|
|
bos@256
|
446 ``break the build'': one person can successfully commit part of a
|
|
bos@256
|
447 change and then be blocked by the need for a merge, causing other
|
|
bos@256
|
448 people to see only a portion of the work they intended to do. This
|
|
bos@256
|
449 also affects how you work with project history. If you want to see
|
|
bos@256
|
450 all of the modifications someone made as part of a task, you will need
|
|
bos@256
|
451 to manually inspect the descriptions and timestamps of the changes
|
|
bos@256
|
452 made to each file involved (if you even know what those files were).
|
|
bos@256
|
453
|
|
bos@256
|
454 CVS has a muddled notion of tags and branches that I will not attempt
|
|
bos@256
|
455 to even describe. It does not support renaming of files or
|
|
bos@256
|
456 directories well, making it easy to corrupt a repository. It has
|
|
bos@256
|
457 almost no internal consistency checking capabilities, so it is usually
|
|
bos@256
|
458 not even possible to tell whether or how a repository is corrupt. I
|
|
bos@256
|
459 would not recommend CVS for any project, existing or new.
|
|
bos@221
|
460
|
|
bos@221
|
461 Mercurial can import CVS revision history. However, there are a few
|
|
bos@221
|
462 caveats that apply; these are true of every other revision control
|
|
bos@221
|
463 tool's CVS importer, too. Due to CVS's lack of atomic changes and
|
|
bos@221
|
464 unversioned filesystem hierarchy, it is not possible to reconstruct
|
|
bos@221
|
465 CVS history completely accurately; some guesswork is involved, and
|
|
bos@221
|
466 renames will usually not show up. Because a lot of advanced CVS
|
|
bos@221
|
467 administration has to be done by hand and is hence error-prone, it's
|
|
bos@221
|
468 common for CVS importers to run into multiple problems with corrupted
|
|
bos@221
|
469 repositories (completely bogus revision timestamps and files that have
|
|
bos@221
|
470 remained locked for over a decade are just two of the less interesting
|
|
bos@221
|
471 problems I can recall from personal experience).
|
|
bos@221
|
472
|
|
bos@280
|
473 Mercurial can import revision history from a CVS repository.
|
|
bos@280
|
474
|
|
bos@280
|
475
|
|
bos@221
|
476 \subsection{Commercial tools}
|
|
bos@221
|
477
|
|
bos@221
|
478 Perforce has a centralised client/server architecture, with no
|
|
bos@221
|
479 client-side caching of any data. Unlike modern revision control
|
|
bos@221
|
480 tools, Perforce requires that a user run a command to inform the
|
|
bos@221
|
481 server about every file they intend to edit.
|
|
bos@221
|
482
|
|
bos@221
|
483 The performance of Perforce is quite good for small teams, but it
|
|
bos@221
|
484 falls off rapidly as the number of users grows beyond a few dozen.
|
|
bos@221
|
485 Modestly large Perforce installations require the deployment of
|
|
bos@221
|
486 proxies to cope with the load their users generate.
|
|
bos@16
|
487
|
|
bos@280
|
488
|
|
bos@280
|
489 \subsection{Choosing a revision control tool}
|
|
bos@280
|
490
|
|
bos@280
|
491 With the exception of CVS, all of the tools listed above have unique
|
|
bos@280
|
492 strengths that suit them to particular styles of work. There is no
|
|
bos@280
|
493 single revision control tool that is best in all situations.
|
|
bos@280
|
494
|
|
bos@280
|
495 As an example, Subversion is a good choice for working with frequently
|
|
bos@280
|
496 edited binary files, due to its centralised nature and support for
|
|
bos@318
|
497 file locking.
|
|
bos@280
|
498
|
|
bos@280
|
499 I personally find Mercurial's properties of simplicity, performance,
|
|
bos@280
|
500 and good merge support to be a compelling combination that has served
|
|
bos@280
|
501 me well for several years.
|
|
bos@280
|
502
|
|
bos@280
|
503
|
|
bos@280
|
504 \section{Switching from another tool to Mercurial}
|
|
bos@280
|
505
|
|
bos@280
|
506 Mercurial is bundled with an extension named \hgext{convert}, which
|
|
bos@280
|
507 can incrementally import revision history from several other revision
|
|
bos@280
|
508 control tools. By ``incremental'', I mean that you can convert all of
|
|
bos@280
|
509 a project's history to date in one go, then rerun the conversion later
|
|
bos@280
|
510 to obtain new changes that happened after the initial conversion.
|
|
bos@280
|
511
|
|
bos@280
|
512 The revision control tools supported by \hgext{convert} are as
|
|
bos@280
|
513 follows:
|
|
bos@280
|
514 \begin{itemize}
|
|
bos@280
|
515 \item Subversion
|
|
bos@280
|
516 \item CVS
|
|
bos@280
|
517 \item Git
|
|
bos@280
|
518 \item Darcs
|
|
bos@280
|
519 \end{itemize}
|
|
bos@280
|
520
|
|
bos@280
|
521 In addition, \hgext{convert} can export changes from Mercurial to
|
|
bos@280
|
522 Subversion. This makes it possible to try Subversion and Mercurial in
|
|
bos@280
|
523 parallel before committing to a switchover, without risking the loss
|
|
bos@280
|
524 of any work.
|
|
bos@280
|
525
|
|
bos@280
|
526 The \hgxcmd{conver}{convert} command is easy to use. Simply point it
|
|
bos@280
|
527 at the path or URL of the source repository, optionally give it the
|
|
bos@280
|
528 name of the destination repository, and it will start working. After
|
|
bos@280
|
529 the initial conversion, just run the same command again to import new
|
|
bos@280
|
530 changes.
|
|
bos@280
|
531
|
|
bos@280
|
532
|
|
bos@16
|
533 %%% Local Variables:
|
|
bos@16
|
534 %%% mode: latex
|
|
bos@16
|
535 %%% TeX-master: "00book"
|
|
bos@16
|
536 %%% End:
|
