1 \chapter{Introduction}

2 \label{chap:intro}

3

4 \section{A propros de la gestion source}

5

6 La gestion de source est un processus permettant de gérer différentes

7 version de la même information. Dans sa forme la plus simple, c'est

8 quelquechose 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 la précédente version.

11

12 Ce genre de gestion de version manuel est cependant sujette facilement

13 à des erreurs, ainsi, depuis longtemps, des logiciels existent pour

14 adresser cette problématique. Les premiers outils de gestion de source

15 étaient destinés à aider un seul utilisateur, à automatiser la gestion

16 des versions d'un seulf fichier. Dans les dernières décades, cette cilble

17 a largement était agrandie, ils gèrent désormais de multiple fichiers, et

18 aident un grand nombre de personnes à travailler ensemble. Le 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.

22

23 \subsection{Pourquoi utiliser un gestionnaire de source ?}

24

25 Il y a de nombreuse 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 ayez à le faire. Pour chaque modification, vous aurez à votre

30 disposition un journal indiquant \emph{qui} a faient 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 facilite le travail collaboratif. Par exemple, quand

35 plusieurs personnes font, plus ou moins simultannéement, 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 fiablement à une version

39 antérieur d'une fichier ou même d'un ensemble de fichier. 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 chaque.

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.

49

50 Une question fondamental à 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 effort d'adoption.

54

55 Un projet de cinq milles personnnes 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.

59

60 D'un autre coté, un ``rapide hack'' d'une personnne 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 ?

63

64 Mercurial supporte ces \emph{deux} échelles de travail. Vous pouvez apprendre

65 les bases en juste quelques minutes, 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 obscures ou de séquence de commandes

68 défiant l'imagination, complètement décorrelé de \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.

72

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 lequel

75 vous pourrez travailler avec.

76

77 \subsection{Les multiples noms de la gestion de source}

78

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

80 une seul nom ou acronyme pour le désigner. Voilà quelqu'uns des noms ou

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}.

82

83 :

84 \begin{itemize}

85 \item \textit{Revision control (RCS)} ;

86 \item Software configuration management (SCM), ou \textit{configuration management} ;

87 \item \textit{Source code management} ;

88 \item \textit{Source code control}, ou \textit{source control} ;

89 \item \textit{Version control (VCS)}.

90 \end{itemize}

91

92 Certains personnes prétendent que ces termes ont en fait des sens

93 différents mais en pratique ils se recouvrent tellement qu'il n'y a pas

94 réellement de manière pertinente de les distinguer.

95

96 \section{Une courte histoire de la gestion de source}

97

98 Le plus célèbre des anciens outils de gestion de source est \textit{SCCS (Source

99 Code Control System)}, que Marc Rochkind conçu dans les laboratoire de recherche de Bell

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.

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

102 des fichiers, et plus tard, oublie de le dévérouiller; empêchant n'importe qui d'autre de

103 travailler sur ces fichiers sans l'aide de l'administrateur...

104

105 Walter Tichy a développé une alternative libre à \textit{SCCS} au début des années 80, qu'il

106 nomma \textit{RSC (Revison Control System)}. Comme \textit{SCCS}, \textit{RCS}

107 demander aux développeurs de travailler sur le même répertoire partagé, et de vérouiller les

108 fichiers pour se prémunir de tout conflit issue de modifications concurrentes.

109

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.

111

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.

113

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).

115

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.

117

118

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.

120

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.

122

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.

124

125 \section{Tendances de la gestion de source}

126

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.

128

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.

130

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.

132

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.

134

135 \section{Quelques avantages des gestionnaire de source distribué}

136

137 Même si les gestionnaire de source distribué sont depuis plusieurs années

138 assez robuste et aussi utilisable que leur prédécésseurs, les utilisateurs

139 d'autres outils n'ont pas encore étaient sensibilisé. Les gestionnaires

140 de sources distribué se distingue particulièrement de leurs équivalents

141 centralisé de nombreuse manière.

142

143 Pour un développeur individuel, ils restent beaucoup plus rapide que les

144 outils centralisés. Cela pour une raison simple: un outil centralisé doit

145 toujours discuter à travers le réseau pour la plupart des opérations, car

146 presque toutes les métadonnées sont stockées sur la seule copie du serveur

147 central. Un outil distribué stocke toute ses métadonnées localement. À tâche

148 égale, effectuer un échange avec le réseau ajoute un délai aux outils

149 centralisés. Ne sous estimez pas la valeur d'un outil rapide: vous allez

150 passer beaucoup de temps à interagir avec un logiciel de gestion de sources.

151

152 Les outils distribué sont complètement indépendant des aléas de votre serveur,

153 encore une fois car ils répliquent les métadonnées à tellement d'endoit. Si

154 votre serveur central prend feu, vous avez intérêt à ce que les média de

155 sauvegarde soient fiable, et que votre dernier ``backup'' soit récent et

156 fonctionne sans problème. Avec un outil distribué, vous avez autant de

157 ``backup'' que de contributeurs.

158

159 En outre, la fiabilité de votre réseau affectera beaucoup moins les

160 outils distribué. Vous ne pouvez même pas utiliser un outil centralisé

161 sans connexion réseau, à l'exception de quelques commandes, très limités.

162 Avec un outil distribué, si vous connexion réseau tombe pendant que vous

163 travaillez, vous pouvez ne même pas vous en rendre compte. La seule chose

164 que vous ne serez pas capable de faire sera de communiquer avec des dépôts

165 distants, opération somme toute assez rare par comparaison aux opérations

166 locales. Si vous avez une (TODO:far-flung???) équipe de collaborateurs,

167 ceci peut être significatif.

168

169 \subsection{Avantages pour les projets \textit{Open Source}}

170

171 Si vous prenez goût à un projet \textit{Open Source} et que vous

172 décidez de commencer à toucher à son code, et que le projet utilise

173 un gestionnaire de source distribué, vous êtes immédiatement un "pair"

174 avec les personnes formant le ``coeur'' du projet. Si ils publient

175 leurs dépôts, vous pouvez immédiatement copier leurs historiques de

176 projet, faire des modifications, enregistrer votre travail en utilisant

177 les même outils qu'eux. Par comparaison, avec un outil centralisé, vous

178 devez utiliser un logiciel en mode ``lecture seule'' à moins que

179 quelqu'un ne vous donne les privilèges de ``commit'' sur le serveur

180 central. Avant ça, vous ne serez pas capable d'enregistrer vos

181 modifications, et vos propres modifications risqueront de se

182 corrompre chaque fois que vous essayerez de mettre à jour à votre

183 espace de travail avec le serveur central.

184

185 \subsubsection{Le non-problème du \textit{fork}}

186

187 Il a été souvent suggeré que les gestionnaires de source distribués

188 posent un risque pour les projets \textit{Open Source} car ils

189 facilitent grandement la création de ``fork''\footnote{NdT:Création

190 d'une version alternative du logiciel}. %%% TODO: Link to Wikipedia

191 Un ``fork'' apparait quand il y des divergences d'opinion ou d'attitude

192 au sein d'un groupe de développeurs qui aboutit à la décision de ne

193 plus travail ensemble. Chacun parti s'empare d'une copie plus ou moins

194 complète du code source du projet et continue dans sa propre direction.

195

196 Parfois ces différents partis décide de se réconcilier. Avec un

197 serveur central, l'aspect \emph{technique} de cette réconciliation

198 est un processus douloureux, et essentiellement manuel. Vous devez

199 décider quelle modification est ``la gagnante'', et replacer, par un

200 moyen ou un autre, les modifications de l'autre équipe dans l'arboresence

201 du projet. Ceci implique généralement la perte d'une partie l'historique

202 d'un des partie, ou même des deux.

203

204 Ce que les outils distribués permettent à ce sujet est probablement

205 la \emph{meilleur} façon de développer un projet. Chaque modification

206 que vous effectué est potentiellement un ``fork''. La grande force de

207 cette approche est que les gestionnaire de source distribué doit être

208 vraiment très efficase pour \emph{fusionner}\footnote{NdT:j'ai choisi de

209 traduire ici \textit{merging} par ``fusionner'' pour des raisons de clarté}

210 des ``forks'', car les ``forks'', dans ce contexte, arrivent tout le

211 temps.

212

213 Si chaque altération que n'importe qui effectue, à tout moment, est vu

214 comme un ``fork'' à fusionner, alors ce que le monde de l'\textit{Open

215 Source} voit comme un ``fork'' devient \emph{uniquement} une problématique

216 social. En fait, les outils de gestion de source distribué \emph{réduisent}

217 les chances de ``fork'':

218 \begin{itemize}

219 \item Ils éliminent la distinction social qu'imposent les outils centralisés

220 entre les membres du projets (ce qui ont accès au ``comit'') et ceux de l'

221 extérieur (ce qui ne l'ont pas).

222 \item Ils rendent plus facile la réconciliation après un ``fork'' social, car

223 tout ce qu'elle implique est juste une simple fusion.

224 \end{itemize}

225

226 Certaines personnes font de la résistance envers les gestionnaires de source

227 distribués parce qu'ils veulent garder un contrôle ferme de leur projet, et

228 ils pensent que les outils centralisés leur fournissent ce contrôle. Néanmoins,

229 si c'est votre cas, sachez que si vous publier votre dépôt CVS ou Subversion

230 de manière publique, il existe une quantité d'outils disponibles pour récupérer

231 entièrement votre projet et son historique (quoique lentement) et le récréer

232 ailleurs, sans votre contrôle. En fait, votre contrôle sur votre projet est

233 illusoire, vous ne faites qu'interdire à vos collaborateurs de travailler

234 de manière fluide, en disposant d'un miroir ou d'un ``fork'' de votre

235 historique.

236 %%%TODO: Fussy, those last sentences are not really well translated:

237 %However, if you're of this belief, and you publish your CVS or Subversion

238 %repositories publically, there are plenty of tools available that can pull

239 %out your entire project's history (albeit slowly) and recreate it somewhere

240 %that you don't control. So while your control in this case is illusory, you are

241 %forgoing the ability to fluidly collaborate with whatever people feel

242 %compelled to mirror and fork your history.

243

244 \subsection{Avantages pour les projets commerciaux}

245

246 Beaucoup de projets commerciaux sont réalisé par des équipes éparpillées

247 à travers le globe. Les contributeurs qui sont loin du serveur central

248 devront subir des commandes lentes et même parfois peu fiable. Les

249 solutions propriétaires gestion de source, tentent de palier ce problème

250 avec des réplications de site distant qui sont à la fois coûteuses à mettre

251 en place et lourdes à administrer. A un système distribué ne souffre pas

252 de ce genre de problèmes. En outre, il est très aisé de mettre en place

253 plusieurs serveurs de références, disont un par site, de manière à ce qu'il

254 n'y est pas de communication redondante entre les dépôts, sur une connexion

255 longue distance souvent onéreuse.

256

257 Les systèmes de gestion de source supportent généralement assez mal la

258 monté en charge. Ce n'est pas rare pour un gestionnaire de source centralisé

259 pourtant onéreux de s'effondrer sous la charge combinée de juste une douzaine

260 d'utilisateurs concurrents. Une fois encore, la réponse à cette problématique

261 est généralement encore la mise en place d'un ensemble complexe de serveurs

262 synchronisé par un mécanisme de réplication. Dans le cas d'un gestionnaire

263 de source distribué, la charge du serveur central--- si vous avez un--- est

264 plusieurs fois inférieur (car toutes les données sont déjà répliqués ailleurs),

265 un simple server, pas très cher, peut gérer les besoins d'une plus grande

266 équipe, et la réplication pour balancer la charge devient simplement le

267 travail d'un simple script.

268

269 Si vous avez des employés sur le terrain, entrain de chercher à résoudre sur

270 le site d'un client, ils bénéficieront aussi d'un gestionnaire de source

271 distribués. Cet outil leur permettra de générer des versions personnalisées,

272 d'essayer différentes solutions, en les isolant aisément les une des autres,

273 et de recherche efficasement à travers l'historique des sources, la cause

274 des bugs ou des régression, tout ceci sans avoir besoin de la moindre

275 connexion au réseau de votre compagnie.

276

277 \section{Pourquoi choisir Mercurial?}

278

279 Mercurial a plusieurs caractéristiques qui en font un choix particulièrement

280 pertinent pour la gestion de source:

281 \begin{itemize}

282 \item Il est facile à apprendre et à utiliser ;It is easy to learn and use.

283 \item il est léger et performant ;

284 \item il monte facilement en charge ;

285 \item il est facile à personnaliser ;

286 \end{itemize}

287

288 Si vous êtes déjà familier d'un outil de gestion de source, vous serez

289 capable de l'utiliser en moins de 5 minutes. Sinon, ça ne sera pas beaucoup

290 plus long\footnote{NdT: Pour appuyer le propos de l'auteur, je signale que

291 j'utilise Mercurial comme outil d'initiation à la gestion de contrôle dans

292 des travaux pratique à l'ESME Sudria (\url{http://www.esme.fr}) et que les

293 élèves le prennent en main sans difficulté majeur malgré l'approche distribuée.}.

294 Les commandes utilisées par Mercurial, comme ses fonctionnalités, sont

295 généralement uniformes et cohérentes, et vous pouvez donc ainsi garder en tête

296 simplement quelques règles générales, plutôt qu'un lot complexe d'exceptions.

297

298 Sur un petit projet, vous pouvez commencer à travailler avec Mercurial en

299 quelques instants. Ajouter des modifications ou des branches, transférer

300 ces modifications (localement ou via le réseau), et les opérations

301 d'historique ou de statut sont aussi très rapide. Mercurial reste hors de

302 votre chemin grâce à sa simplicité d'utilisation et sa rapidité d'exécution.

303

304 L'utilité de Mercurial ne se limite pas à des petits projets: il est

305 aussi utilisé par des projets ayant des centaines ou même des milliers

306 de contributeurs, avec plusieurs dizaines de milliers de fichiers, et des

307 centaines de méga de code source.

308

309 Voici une liste non exhaustive des projets complexe ou critique utilisant

310 mercurial :

311 %TODO

312 % For both spanish and english version, add the following examples:

313 \begin{itemize}

314 \item Firefox ;

315 \item OpenSolaris ;

316 \item OpenJDK (utilisant en outre l'extension ``forest'' pour gérer

317 ses sous modules);

318 \end{itemize}

319 % TODO: Also add appropriate link.

320

321 Si les fonctionnalités coeur de Mercurial ne sont pas suffisantes pour vous,

322 il est très aisé de construire dessus. Mercurial est adapté à l'utilisation

323 au sein de script, et son implémentation interne en python, propre et claire,

324 rend encore plus facile l'ajout de fonctionnalité sous forme d'extension. Il

325 en existe déjà un certains nombres de très populaires et très utiles,

326 dont le périmètre va de la recherche de bugs à l'amélioration des performances.

327

328 \section{Mercurial comparé aux autres outils}

329

330 Avant que vous n'alliez plus loin, comprenez bien que cette section

331 reflète mes propres expériences, et elle est donc (j'ose le dire)

332 peu objectives. Néanmoins, j'ai utilisé les outils de gestion de source

333 listé ci dessous, dans la plupart des cas, pendant plusieurs années.

334 %% TODO: Fussy translation.

335

336 \subsection{Subversion}

337

338 Subversion est un outil de gestion de source les plus populaire, il fût

339 développé pour remplacer CVS. Il a une architecture client/server centralisée.

340

341 Subversion et Mercurial ont des noms de commandes très similaires pour

342 les mêmes opérations, ainsi si vous êtes familier avec l'un, c'est facile

343 d'apprendre l'autre. Ces deux outils sont portable sur les systèmes

344 d'exploitation les plus populaires\footnote{NdT:Mercurial fonctionne sans problèmes

345 sur OpenVMS à l'ESME Sudria \url{http://www.esme.fr}, compte tenu que Subversion a été

346 développé en C, je ne suis pas sûr que son portage aurait été aussi aisé.}.

347 %TODO: Backport this statement in english and spanish

348

349 Avant la version 1.5, Subversion n'offre aucune forme de support pour les fusions. Lors

350 de l'écriture de ce livre, ces capacités de fusion sont nouvelle, et réputé pour être

351 \href{http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword}{complexes

352 et buggués}.

353

354 Mercurial dispose d'un avantages substantiel en terme de performance sur

355 Subversion sur la plupart des opérations que j'ai pu testé. J'ai mesuré

356 une différence de performance allant de deux à six fois plus rapide avec

357 le système de stockage de fichier local de Subversion~1.4.3

358 (\emph{ra\_local}), qui la méthode d'accès la plus rapide disponible. Dans

359 un déploiement plus réaliste, impliquant un stockage réseau, Subversion

360 serait encore plus désavantagé. Parce que la plupart des commandes Subversion

361 doivent communiquer avec le serveur et que Subversion n'a pas de mécanisme

362 de réplication, la capacité du serveur et la bande passante sont devenu des

363 goulots d'étranglement pour les projets de taille moyenne ou grande.

364

365 En outre, Subversion implique une surchage substantielle dans le stockage local

366 de certaines données, pour éviter des transactions avec le serveur, pour

367 certaines opérations communes, tel que la recherche des fichier modifiées

368 (\texttt{status}) et l'affichage des modifications par rapport la révision

369 courante (\texttt{diff}). En conséquence, un répertoire de travail Subversion

370 a souvent la même taille, ou est plus grand, que un dépôt Mercurial et son

371 espace de travail, bien que le dépôt Mercurial contienne l'intégralité de

372 l'historique.

373

374 Subversion est largement supportés par les outils tierses. Mercurial est

375 actuellement encore en retrait de ce point de vue. L'écart se réduit, néanmoins,

376 et en effet certains des outils graphiques sont maintenant supérieur à leurs

377 équivalents Subversion. Comme Mercurial, Subversion dispose d'un excellent

378 manuel utilisateur.

379

380 Parce que Subversion ne stocke par l'historique chez ses clients, il est

381 parfaitement adapté à la gestion de projet qui doivent suivre un ensemble

382 de large fichier binaires et opaques. Si vous suivez une cinquantaine de

383 versions d'un fichier incompressible de 10MB, l'occupation disque coté client

384 d'un projet sous Subversion restera à peu près constante. A l'inverse,

385 l'occupation disque du même projet sous n'importe lequel des gestionnaire

386 de source distribués grandira rapidement, proportionnellement aux nombres

387 de versions, car les différences entre chaque révision sera très grande.

388

389 En outre, c'est souvent difficle ou, généralement, impossible de fusionner

390 des différences dans un fichier binaire. La capacité de Subversion de

391 vérouiller des fichiers, pour permettre à l'utilisateur d'être le seul

392 à le mettre à jour (``commit'') temporairement, est avantage significatif

393 dans un projet doté de beaucoup de fichiers binaire.

394

395 Mercurial peut importer l'historique depuis un dépôt Subversion. Il peut

396 aussi exporter l'ensemble des révisions d'un projet vers un dépôt Subversion.

397 Ceci rend très facile de ``tester l'eau'' et d'utiliser Mercurial et Subversion

398 en parallèle, avant de décider de migrer vers Mercurial. La conversion de

399 l'historique est incrémental, donc vous pouvez effectuer une conversion

400 initial, puis de petites additions par la suite pour ajouter les nouvelles

401 modifications.

402

403 \subsection{Git}

404

405 Git est un outil de gestion de source distribué qui fût développé pour gérer

406 le code source de noyau de Linux. Comme Mercurial, sa conception initial à

407 était inspiré par Monotone.

408

409 Git dispose d'un ensemble conséquent de command, avec plus de~139 commandes

410 individuels pour la version~1.5.0. Il a aussi la réputation d'être difficile

411 à apprendre. Comparé à Git, le point fort de Mercurial est clairement sa

412 simplicité.

413

414 En terme de performance, Git est extrêmement rapide. Dans la plupart des

415 cas, il est plus rapide que Mercurial, tout du moins sur Linux, alors que

416 Mercurial peut être plus performant sur d'autres opérations. Néanmoins, sur

417 Windows, les performances et le niveau de support général fourni par Git,

418 au moment de l'écriture de cet ouvrage, bien derrière celui de Mercurial.

419

420 Alors que le dépôt Mercurial ne demande aucune maintenance, un dépôt Git

421 exige d'exécuter manuellement et régulièrement la commande ``repacks'' sur

422 ces métadonnées. Sans ceci, les performances de git se dégrade, et la

423 consommation de l'espace disque augmente rapidement. Un serveur qui contient

424 plusieurs dépôt Git qui ne sont pas régulièrement et fréquement ``repacked''

425 deviendra un vrai problème lors des ``backups'' du disque, et il y eu des

426 cas, où un ``backup'' journalier pouvait durer plus de~24 heures. Un dépôt

427 fraichement ``repacked'' sera légèrement plus petit que un dépôt Mercurial,

428 mais un dépôt non ``repacked'' est beaucoup plus grand.

429

430 Le coeur de Git est écrit en C. La plupart des commandes Git sont implémentés

431 sous forme de script Shell ou Perl, et la qualité de ces scripts varient

432 grandement. J'ai plusieurs fois constaté que certains de ces scripts étaient

433 chargé en mémoire aveuglément et que la présence d'erreurs pouvait s'avérer

434 fatal.

435

436 Mercurial peut importer l'historique d'un dépôt Git.

437

438 \subsection{CVS}

439

440 CVS est probablement l'outil de gestion de source le plus utilisé aujourd'hui

441 dans le monde. À cause de son manque de properté interne, il n'est plus

442 maintenu depuis plusieurs années.

443

444 Il a une architecture client/serveur centralisé. Il ne groupe pas les

445 modifications de fichiers dans une opération de ``commit'' atomique, ce

446 qui permet à ses utilisateurs de ``casser le \textit{build}'' assez

447 facilement : une personne peut effectuer une opération de ``commit''

448 sans problème puis être bloqué par besoin de fusion, avec comme conséquence

449 néfaste, que les autres utilisateurs ne récupèreront qu'une partie de ses

450 modifications. Ce problème affecte aussi la manière de travailler avec

451 l'historique du projet. Si vous voulez voir toutes les modifications d'une

452 personne du projet, vous devrez injecter manuellement les descriptions et les

453 \textit{timestamps} des modifications de chacun des fichiers impliqués (si

454 vous savez au moins quels sont ces fichiers).

455

456 CVS a une notion étrange des \textit{tags} et des branches que je n'essayerais

457 même de décrire ici. Il ne supporte pas bien les opérations de renommage d'un

458 fichier ou de répertoire, ce qui facilite la corruption de son dépôt. Il n'a

459 presque pas pour ainsi dire de contrôle de cohérence interne, il est donc

460 pratiquement impossible de dire si un dépôt est corrompu ni à quel point. Je

461 ne recommanderais pas CVS pour un projet existant ou nouveau.

462

463 Mercurial peut importer l'historique d'un projet CVS. Néanmoins, il y a

464 quelques princinpes à respecter; ce qui est vrai aussi pour les autres

465 outils d'import de projet CVS. À cause de l'absence de ``commit'' atomique

466 et gestion de version de l'arboresence, il n'est pas possible de reconstruire

467 de manière précise l'ensemble de l'historique. Un travail de ``devinette''

468 est donc nécessaire, et les fichiers renommées ne sont pas détectés. Parce

469 que une bonne part de l'administration d'un dépôt CVS est effectué manuellement,

470 et est donc, sujette à erreur, il est courant que les impots CVS rencontre

471 de nombreux problèmes avec les dépôt corrompues (des \textit{timestamps}

472 de révision complètement buggé et des fichiers vérouillés depuis des années

473 sont deux des problèmes les moins intéressants dont je me souvienne).

474

475 Mercurial peut importer l'historique depuis un dépôt CVS.

476

477 \subsection{Commercial tools}

478

479 Perforce has a centralised client/server architecture, with no

480 client-side caching of any data. Unlike modern revision control

481 tools, Perforce requires that a user run a command to inform the

482 server about every file they intend to edit.

483

484 The performance of Perforce is quite good for small teams, but it

485 falls off rapidly as the number of users grows beyond a few dozen.

486 Modestly large Perforce installations require the deployment of

487 proxies to cope with the load their users generate.

488

489

490 \subsection{Choosing a revision control tool}

491

492 With the exception of CVS, all of the tools listed above have unique

493 strengths that suit them to particular styles of work. There is no

494 single revision control tool that is best in all situations.

495

496 As an example, Subversion is a good choice for working with frequently

497 edited binary files, due to its centralised nature and support for

498 file locking.

499

500 I personally find Mercurial's properties of simplicity, performance,

501 and good merge support to be a compelling combination that has served

502 me well for several years.

503

504

505 \section{Switching from another tool to Mercurial}

506

507 Mercurial is bundled with an extension named \hgext{convert}, which

508 can incrementally import revision history from several other revision

509 control tools. By ``incremental'', I mean that you can convert all of

510 a project's history to date in one go, then rerun the conversion later

511 to obtain new changes that happened after the initial conversion.

512

513 The revision control tools supported by \hgext{convert} are as

514 follows:

515 \begin{itemize}

516 \item Subversion

517 \item CVS

518 \item Git

519 \item Darcs

520 \end{itemize}

521

522 In addition, \hgext{convert} can export changes from Mercurial to

523 Subversion. This makes it possible to try Subversion and Mercurial in

524 parallel before committing to a switchover, without risking the loss

525 of any work.

526

527 The \hgxcmd{conver}{convert} command is easy to use. Simply point it

528 at the path or URL of the source repository, optionally give it the

529 name of the destination repository, and it will start working. After

530 the initial conversion, just run the same command again to import new

531 changes.

532

533

534 %%% Local Variables:

535 %%% mode: latex

536 %%% TeX-master: "00book"

537 %%% End: