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