| rev |
line source |
|
belaran@964
|
1 <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
|
|
belaran@964
|
2
|
|
belaran@967
|
3 <chapter id="chap:intro">
|
|
belaran@967
|
4 <?dbhtml filename="how-did-we-get-here.html"?>
|
|
belaran@967
|
5 <title>Comment en est on arrivé là ?</title>
|
|
belaran@964
|
6
|
|
belaran@964
|
7 <sect1>
|
|
Wilk@1004
|
8 <title>À propos de la gestion de révisions. Pourquoi Mercurial ?</title>
|
|
Wilk@1004
|
9
|
|
Wilk@1004
|
10 <para id="x_6d">La gestion de révisions est un processus permettant de gérer différentes
|
|
belaran@964
|
11 versions de la même information. Dans sa forme la plus simple, c'est
|
|
belaran@964
|
12 ce que tout le monde fait manuellement : quand vous modifiez
|
|
belaran@964
|
13 un fichier, vous le sauvegardez sous un nouveau nom contenant un numéro,
|
|
belaran@964
|
14 à chaque fois plus grand que celui de la version précédente.</para>
|
|
belaran@964
|
15
|
|
Wilk@1004
|
16 <para id="x_6e">Ce genre de gestion de révisions manuelle, ne serait-ce que
|
|
Wilk@1004
|
17 d'un seul fichier, est cependant facilement sujette
|
|
youshe@982
|
18 aux erreurs, ainsi, depuis longtemps, des logiciels existent pour
|
|
Wilk@1004
|
19 résoudre cette problématique. Les premiers outils de gestion de révisions
|
|
belaran@964
|
20 étaient destinés à aider un seul utilisateur, à automatiser la gestion
|
|
belaran@964
|
21 des versions d'un seul fichier. Dans les dernières décades, cette cible
|
|
belaran@964
|
22 s'est largement agrandie, ils gèrent désormais de multiples fichiers, et
|
|
belaran@964
|
23 aident un grand nombre de personnes à travailler ensemble. Les outils les
|
|
belaran@964
|
24 plus modernes n'ont aucune difficulté à gérer plusieurs milliers de
|
|
belaran@964
|
25 personnes travaillant ensemble sur des projets regroupant plusieurs
|
|
belaran@964
|
26 centaines de milliers de fichiers.</para>
|
|
belaran@964
|
27
|
|
Wilk@1004
|
28 <para id="x_6f">L'arrivée de la gestion de révisions distribuée est
|
|
belaran@967
|
29 relativement récente, et, pour le moment, ce nouveau domaine a grandi
|
|
youshe@982
|
30 grâce à la volonté des gens d'explorer ces territoires encore inconnus.
|
|
belaran@967
|
31 </para>
|
|
belaran@967
|
32
|
|
Wilk@1004
|
33 <para id="x_70">J'écris un livre sur la gestion de révisions distribuée
|
|
belaran@967
|
34 parce que je pense qu'il s'agit d'un sujet important qui mérite un guide
|
|
Wilk@1004
|
35 de terrain. J'ai choisi d'écrire un livre sur Mercurial car il est
|
|
belaran@967
|
36 l'outil le plus facile pour découvrir ce nouveau domaine, tout en étant
|
|
youshe@982
|
37 un outil efficace qui répond aux demandes d'environnements réels et
|
|
Wilk@1004
|
38 difficiles, là où d'autres outils de gestion de révisions s'effondrent.</para>
|
|
belaran@967
|
39
|
|
belaran@967
|
40 <sect2>
|
|
Wilk@1004
|
41 <title>Pourquoi utiliser un gestionnaire de révisions ?</title>
|
|
belaran@967
|
42
|
|
belaran@967
|
43 <para id="x_71">Il y a de nombreuses raisons pour que vous ou votre équipe souhaitiez
|
|
Wilk@1004
|
44 utiliser un outil automatisant la gestion de révisions pour votre projet.</para>
|
|
belaran@967
|
45
|
|
belaran@967
|
46 <itemizedlist>
|
|
belaran@967
|
47 <listitem><para id="x_72">L'outil se chargera de suivre l'évolution de votre projet, sans
|
|
youshe@982
|
48 que vous ayez à le faire. Pour chaque modification, vous aurez à votre
|
|
belaran@964
|
49 disposition un journal indiquant <emphasis>qui</emphasis> a fait quoi, <emphasis>pourquoi</emphasis>
|
|
youshe@982
|
50 il l'a fait, <emphasis>quand</emphasis> il l'a fait, et
|
|
youshe@982
|
51 <emphasis>ce</emphasis> qu'il a modifié.</para>
|
|
belaran@964
|
52 </listitem>
|
|
belaran@967
|
53 <listitem><para id="x_73">Quand vous travaillez avec d'autres personnes, les logiciels de
|
|
Wilk@1004
|
54 gestion de révisions facilitent le travail collaboratif. Par exemple, quand
|
|
belaran@964
|
55 plusieurs personnes font, plus ou moins simultanément, des modifications
|
|
belaran@964
|
56 incompatibles, le logiciel vous aidera à identifier et à résoudre les conflits.</para>
|
|
belaran@964
|
57 </listitem>
|
|
belaran@967
|
58 <listitem><para id="x_74">L'outil vous aidera à réparer vos erreurs. Si vous effectuez un changement
|
|
belaran@964
|
59 qui se révèle être une erreur, vous pourrez revenir à une version
|
|
belaran@964
|
60 antérieure d'un fichier ou même d'un ensemble de fichiers. En fait, un outil de
|
|
Wilk@1004
|
61 gestion de révisions <emphasis>vraiment</emphasis> efficace vous permettra d'identifier à quel
|
|
belaran@964
|
62 moment le problème est apparu (voir la section <xref linkend="sec:undo:bisect"/> pour plus
|
|
belaran@964
|
63 de détails).</para>
|
|
belaran@964
|
64 </listitem>
|
|
belaran@967
|
65 <listitem><para id="x_75">L'outil vous permettra aussi de travailler sur plusieurs versions différentes
|
|
youshe@982
|
66 de votre projet et de gérer l'écart entre chacune.</para>
|
|
belaran@964
|
67 </listitem></itemizedlist>
|
|
youshe@982
|
68 <para id="x_76">La plupart de ces raisons ont autant d'importances &emdash;du
|
|
Wilk@1004
|
69 moins en théorie&emdash; que vous travailliez seul sur un projet, ou
|
|
youshe@982
|
70 avec une centaine d'autres personnes.
|
|
belaran@964
|
71 </para>
|
|
belaran@964
|
72
|
|
youshe@982
|
73 <para id="x_77">Une question fondamentale à propos des outils de gestion de
|
|
Wilk@1004
|
74 révisions, qu'il s'agisse du projet d'une personne ou d'une grande équipe, est
|
|
Wilk@1004
|
75 quels sont ses <emphasis>gains</emphasis> par rapport à ses
|
|
Wilk@1004
|
76 <emphasis>coût</emphasis>. Un outil qui est difficile à utiliser ou à
|
|
youshe@982
|
77 comprendre exigera un lourd effort d'adaptation.
|
|
belaran@964
|
78 </para>
|
|
belaran@964
|
79
|
|
Wilk@1004
|
80 <para id="x_78">Un projet de cinq milles personnes s'effondrera très
|
|
youshe@982
|
81 certainement de lui même sans aucun processus et outil de gestion de
|
|
Wilk@1004
|
82 révisions. Dans ce cas, le coût d'utilisation d'un logiciel de gestion de
|
|
Wilk@1004
|
83 révisions est dérisoire puisque <emphasis>sans</emphasis>, l'échec est presque
|
|
youshe@982
|
84 garanti.
|
|
belaran@964
|
85 </para>
|
|
belaran@964
|
86
|
|
youshe@982
|
87 <para id="x_79">D'un autre coté, un <quote>rapide hack</quote> d'une personne
|
|
youshe@982
|
88 peut sembler un contexte bien pauvre pour utiliser un outil de gestion de
|
|
Wilk@1004
|
89 révisions, car, bien évidement le coût d'utilisation dépasse le coût total du
|
|
youshe@982
|
90 projet. N'est ce pas ?
|
|
belaran@964
|
91 </para>
|
|
belaran@964
|
92
|
|
youshe@982
|
93 <para id="x_7a">Mercurial supporte ces <emphasis>deux</emphasis>
|
|
youshe@982
|
94 échelles de travail. Vous pouvez apprendre les bases en quelques
|
|
youshe@982
|
95 minutes seulement, et, grâce à sa performance, vous pouvez l'utiliser
|
|
youshe@982
|
96 avec facilité sur le plus petit des projets. Cette simplicité
|
|
Wilk@1004
|
97 signifie que vous n'avez pas de concept obscur ou de séquence de
|
|
youshe@982
|
98 commandes défiant l'imagination, sans aucune corrélation avec
|
|
youshe@982
|
99 <emphasis>ce que vous êtes entrain de faire</emphasis>. En même
|
|
youshe@982
|
100 temps, ces mêmes performances et sa nature
|
|
youshe@982
|
101 <quote>peer-to-peer</quote> vous permettent d'adapter, sans
|
|
youshe@982
|
102 difficulté, son utilisation à de très grands projets.
|
|
belaran@964
|
103 </para>
|
|
belaran@964
|
104
|
|
Wilk@1004
|
105 <para id="x_7b">Aucun outil de gestion de révisions ne peut sauver un
|
|
youshe@982
|
106 projet mal mené, mais un bon outil peut rendre beaucoup plus fluide
|
|
youshe@982
|
107 votre travail.
|
|
belaran@964
|
108 </para>
|
|
belaran@964
|
109
|
|
belaran@967
|
110 </sect2>
|
|
belaran@967
|
111
|
|
belaran@967
|
112 <sect2>
|
|
belaran@967
|
113 <title>Les multiples noms de la gestion de source</title>
|
|
belaran@967
|
114
|
|
youshe@982
|
115 <para id="x_7c">La gestion de source
|
|
youshe@982
|
116 <!-- TODO:<footnote><J'ai utilisé systématiquement le terme
|
|
Wilk@1004
|
117 <quote>gestion de révisions</quote> à travers tout l'ouvrage. Ce
|
|
youshe@982
|
118 n'est pas forcement la meilleure traduction, et ceci peut rendre
|
|
youshe@982
|
119 la lecture un peu lourde, mais je pense que le document y gagne
|
|
youshe@982
|
120 en clarté et en précision. -->
|
|
youshe@982
|
121 est un domaine tellement large qu'il n'existe pas qu'un seul nom ou
|
|
youshe@982
|
122 acronyme pour le désigner. Voici quelques noms ou acronymes que vous
|
|
youshe@982
|
123 rencontrerez le plus souvent.
|
|
youshe@982
|
124 <!-- TODO:<footnote> J'ai conservé la liste des noms en anglais pour
|
|
youshe@982
|
125 des raisons de commodité (ils sont plus <quote>googelable</quote>).
|
|
youshe@982
|
126 En outre, j'ai opté pour conserver l'ensemble des opérations de
|
|
youshe@982
|
127 Mercurial (\textit{commit},\textit{push}, \textit{pull},...) en
|
|
youshe@982
|
128 anglais, là aussi pour faciliter la lecture d'autres documents en
|
|
youshe@982
|
129 anglais, ainsi que l'utilisation de Mercurial. -->
|
|
belaran@964
|
130 </para>
|
|
belaran@964
|
131
|
|
belaran@964
|
132 <para>:
|
|
belaran@964
|
133 </para>
|
|
belaran@967
|
134
|
|
belaran@967
|
135 <itemizedlist>
|
|
belaran@967
|
136 <listitem><para id="x_7d">Revision control (RCS)</para></listitem>
|
|
youshe@982
|
137 <listitem><para id="x_7e">Software configuration management (SCM), ou
|
|
belaran@967
|
138 configuration management</para></listitem>
|
|
belaran@967
|
139 <listitem><para id="x_7f">Source code management</para></listitem>
|
|
youshe@982
|
140 <listitem><para id="x_80">Source code control, ou source control</para></listitem>
|
|
youshe@982
|
141 <listitem><para id="x_81">Version control (VCS)</para></listitem></itemizedlist>
|
|
youshe@982
|
142
|
|
youshe@982
|
143 <para id="x_82">Certaines personnes prétendent que ces termes ont en fait
|
|
youshe@982
|
144 des sens différents mais en pratique ils se recouvrent tellement qu'il n'y
|
|
youshe@982
|
145 a pas réellement de manière pertinente de les distinguer. </para>
|
|
belaran@964
|
146
|
|
belaran@967
|
147 </sect2>
|
|
belaran@967
|
148 </sect1>
|
|
belaran@967
|
149
|
|
belaran@967
|
150 <sect1>
|
|
belaran@967
|
151
|
|
Wilk@1004
|
152 <title>À propos des exemples dans ce livre</title>
|
|
Wilk@1004
|
153
|
|
Wilk@1004
|
154 <para id="x_84">Ce livre prend une approche non usuelle pour les exemples
|
|
youshe@982
|
155 de code. Tous les exemples sont en <quote>live</quote> &emdash; Chacun
|
|
youshe@982
|
156 est actuellement le résultat d'un script shell qui exécute les
|
|
youshe@982
|
157 commandes Mercurial que vous voyez. A chaque fois qu'une image du livre
|
|
Wilk@1004
|
158 est construite à partir des sources, tous les scripts d'exemples sont
|
|
youshe@982
|
159 lancés automatiquement, et leurs résultats effectifs sont comparés aux
|
|
youshe@982
|
160 résultats attendus.</para>
|
|
youshe@982
|
161
|
|
youshe@982
|
162 <para id="x_85">L'avantage de dette approche est que les exemples sont
|
|
youshe@982
|
163 toujours précis ; ils décrivent <emphasis>exactement</emphasis> la
|
|
youshe@982
|
164 conduite de la version de Mercurial qui est mentionnée en entête du
|
|
youshe@982
|
165 livre. Si je met à jour la version de Mercurial que je suis en train de
|
|
youshe@982
|
166 documenter, et que la sortie de certaines commandes change, la
|
|
youshe@982
|
167 construction du livre échoue.</para>
|
|
youshe@982
|
168
|
|
youshe@982
|
169 <para id="x_86">
|
|
youshe@982
|
170 Il existe un petit désavantage à cette approche qui est que les dates et
|
|
youshe@982
|
171 heures que vous verrez dans les exemples tendent à être
|
|
youshe@982
|
172 <quote>écrasés</quote> ensemble, dans le sens où elles ne sont pas
|
|
youshe@982
|
173 celles qu'elles auraient été si un humain avait tapé les commandes. En
|
|
youshe@982
|
174 effet, humain ne peut pas taper plus d'une commande toutes les quelques
|
|
youshe@982
|
175 secondes, avec le temps qui s'écoule, mes scripts d'exemples exécutent
|
|
youshe@982
|
176 plusieurs commandes en une seconde.
|
|
youshe@982
|
177 </para>
|
|
youshe@982
|
178
|
|
youshe@982
|
179 <para id="x_87">Une circonstance de ceci est que plusieurs commits
|
|
youshe@982
|
180 consécutifs dans un exemple peuvent apparaître comme ayant eu lieu
|
|
youshe@982
|
181 durant la même seconde.
|
|
youshe@982
|
182 Vous pouvez observer le phénomène dans l'exemple <literal
|
|
youshe@982
|
183 role="hg-ext">bisect</literal> dans <xref linkend="sec:undo:bisect"/>
|
|
youshe@982
|
184 </para>
|
|
youshe@982
|
185
|
|
youshe@982
|
186 <para id="x_88">Donc, lorsque vous lisez ces exemples, ne prêtez pas trop
|
|
youshe@982
|
187 d'importance aux dates et heures que vous voyez dans la sortie des
|
|
youshe@982
|
188 commandes. Cependant, <emphasis>soyez</emphasis> confiants que le
|
|
Wilk@1004
|
189 comportement que vous voyez est constant et reproductible
|
|
youshe@982
|
190 </para>
|
|
belaran@967
|
191
|
|
belaran@967
|
192 </sect1>
|
|
belaran@967
|
193
|
|
belaran@967
|
194 <!-- The next section has disapper from this part of the book. it may be splaced somewhere else... t-->
|
|
belaran@967
|
195
|
|
belaran@967
|
196 <sect1>
|
|
Wilk@1004
|
197 <title>Tendances de la gestion de révisions</title>
|
|
belaran@967
|
198
|
|
youshe@982
|
199 <para id="x_89">Il y a eu une tendance évidente dans le développement et
|
|
youshe@982
|
200 l'utilisation d'outils de gestion de source depuis les quatre dernières
|
|
youshe@982
|
201 décades, au fur et à mesure que les utilisateurs se sont habitués à
|
|
youshe@982
|
202 leur outils et se sont sentis contraints par leurs limitations.
|
|
youshe@982
|
203 </para>
|
|
youshe@982
|
204
|
|
youshe@982
|
205 <para id="x_8a">La première génération commença simplement par gérer un
|
|
youshe@982
|
206 fichier unique sur un ordinateur individuel. Cependant, même si ces
|
|
youshe@982
|
207 outils présentaient une grande avancée par rapport à la gestion
|
|
youshe@982
|
208 manuelle des versions, leur modèle de verrouillage et leur utilisation
|
|
youshe@982
|
209 limitée à un seul ordinateur rendaient leur utilisation possible
|
|
youshe@982
|
210 uniquement dans une très petite équipe.
|
|
youshe@982
|
211 </para>
|
|
youshe@982
|
212
|
|
youshe@982
|
213 <para id="x_8b">La seconde génération a assoupli ces contraintes en
|
|
youshe@982
|
214 adoptant une architecture réseau et centralisée, permettant de gérer
|
|
youshe@982
|
215 plusieurs projets entiers en même temps. Alors que les projets
|
|
youshe@982
|
216 grandirent en taille, ils rencontrèrent de nouveaux problèmes. Avec les
|
|
Wilk@1004
|
217 clients discutant régulièrement avec le serveur, la montée en charge
|
|
youshe@982
|
218 devint un réel problème sur les gros projets. Une connexion réseau peu
|
|
youshe@982
|
219 fiable pouvait complètement empêcher les utilisateurs distants de
|
|
youshe@982
|
220 dialoguer avec le serveur. Alors que les projets <emphasis
|
|
youshe@982
|
221 remap="it">Open Source</emphasis> commencèrent à mettre en place des
|
|
youshe@982
|
222 accès en lecture seule disponible anonymement, les utilisateurs sans
|
|
youshe@982
|
223 les privilèges de <quote>commit</quote> réalisèrent qu'ils ne pouvaient
|
|
youshe@982
|
224 pas utiliser les outils pour collaborer naturellement avec le projet,
|
|
youshe@982
|
225 comme ils ne pouvaient pas non plus enregistrer leurs modifications.
|
|
youshe@982
|
226 </para>
|
|
youshe@982
|
227
|
|
Wilk@1004
|
228 <para id="x_8c">La génération actuelle des outils de gestion de révisions
|
|
youshe@982
|
229 est <quote>peer-to-peer</quote> par nature. Tous ces systèmes ont
|
|
Wilk@1004
|
230 abandonné la dépendance à un serveur central, et ont permis à leurs
|
|
Wilk@1004
|
231 utilisateurs de distribuer les données de leur gestion de révisions à qui
|
|
youshe@982
|
232 en a besoin. La collaboration à travers Internet a transformé la
|
|
youshe@982
|
233 contrainte technologique en une simple question de choix et de
|
|
youshe@982
|
234 consensus. Les outils modernes peuvent maintenant fonctionner en mode
|
|
youshe@982
|
235 déconnecté sans limite et de manière autonome, la connexion au réseau
|
|
youshe@982
|
236 n'étant nécessaire que pour synchroniser les modifications avec les
|
|
youshe@982
|
237 autres dépôts.
|
|
youshe@982
|
238 </para>
|
|
belaran@967
|
239 </sect1>
|
|
youshe@982
|
240
|
|
belaran@967
|
241 <sect1>
|
|
Wilk@1004
|
242 <title>Quelques avantages des gestionnaires de révisions distribués</title>
|
|
youshe@982
|
243
|
|
Wilk@1004
|
244 <para id="x_8d">Même si les gestionnaire de révisions distribués sont depuis
|
|
youshe@982
|
245 plusieurs années assez robustes et aussi utilisables que leurs
|
|
youshe@982
|
246 prédécesseurs, les utilisateurs d'autres outils n'y ont pas encore été
|
|
Wilk@1004
|
247 sensibilisés. Les gestionnaires de révisions distribués se distinguent
|
|
youshe@982
|
248 particulièrement de leurs équivalents centralisés de nombreuses
|
|
youshe@982
|
249 manières.
|
|
youshe@982
|
250 </para>
|
|
youshe@982
|
251
|
|
youshe@982
|
252 <para id="x_8e">Pour un développeur individuel, ils restent beaucoup plus
|
|
youshe@982
|
253 rapides que les outils centralisés. Cela pour une raison simple : un
|
|
youshe@982
|
254 outil centralisé doit toujours dialoguer à travers le réseau pour la
|
|
youshe@982
|
255 plupart des opérations, car presque toutes les métadonnées sont
|
|
youshe@982
|
256 stockées sur la seule copie du serveur central. Un outil distribué
|
|
youshe@982
|
257 stocke toute ses métadonnées localement. À tâche égale, effectuer un
|
|
youshe@982
|
258 échange avec le réseau ajoute un délai aux outils centralisés. Ne
|
|
youshe@982
|
259 sous-estimez pas la valeur d'un outil rapide : vous allez passer
|
|
Wilk@1004
|
260 beaucoup de temps à interagir avec un logiciel de gestion de révisions.
|
|
youshe@982
|
261 </para>
|
|
youshe@982
|
262
|
|
youshe@982
|
263 <para id="x_8f">Les outils distribués sont complètement indépendants des
|
|
youshe@982
|
264 aléas de votre serveur, d'autant plus qu'ils répliquent les métadonnées
|
|
youshe@982
|
265 à beaucoup d'endroits. Si votre serveur central prend feu, vous avez
|
|
youshe@982
|
266 intérêt à ce que les médias de sauvegardes soient fiables, et que votre
|
|
youshe@982
|
267 dernier <quote>backup</quote> soit récent et fonctionne sans problème.
|
|
Wilk@1004
|
268 Avec un outil distribué, vous avez autant de <quote>backups</quote> que
|
|
youshe@982
|
269 de contributeurs.
|
|
youshe@982
|
270 </para>
|
|
youshe@982
|
271
|
|
youshe@982
|
272 <para id="x_90">En outre, la fiabilité de votre réseau affectera beaucoup
|
|
youshe@982
|
273 moins les outils distribués. Vous ne pouvez même pas utiliser un outil
|
|
youshe@982
|
274 centralisé sans connexion réseau, à l'exception de quelques commandes,
|
|
youshe@982
|
275 très limitées. Avec un outil distribué, si votre connexion réseau tombe
|
|
youshe@982
|
276 pendant que vous travaillez, vous pouvez ne même pas vous en rendre
|
|
youshe@982
|
277 compte. La seule chose que vous ne serez pas capable de faire sera de
|
|
youshe@982
|
278 communiquer avec des dépôts distants, opération somme toute assez rare
|
|
Wilk@1004
|
279 en comparaison des opérations locales. Si vous avez une équipe de
|
|
youshe@982
|
280 collaborateurs très dispersée ceci peut être significatif.
|
|
youshe@982
|
281 </para>
|
|
belaran@967
|
282
|
|
belaran@967
|
283 <sect2>
|
|
belaran@967
|
284 <title>Avantages pour les projets Open Source</title>
|
|
belaran@967
|
285
|
|
youshe@982
|
286 <para id="x_91">Si vous prenez goût à un projet <emphasis
|
|
youshe@982
|
287 remap="it">Open Source</emphasis> et que vous décidez de commencer
|
|
youshe@982
|
288 à toucher à son code, et que le projet utilise un gestionnaire de
|
|
Wilk@1004
|
289 révisions distribué, vous êtes immédiatement un "pair" avec les
|
|
youshe@982
|
290 personnes formant le <quote>cœur</quote> du projet. S'ils publient
|
|
youshe@982
|
291 leurs dépôts, vous pouvez immédiatement copier leurs historiques de
|
|
youshe@982
|
292 projet, faire des modifications, enregistrer votre travail en
|
|
youshe@982
|
293 utilisant les mêmes outils qu'eux. Par comparaison avec un outil
|
|
youshe@982
|
294 centralisé, vous devez utiliser un logiciel en mode <quote>lecture
|
|
youshe@982
|
295 seule</quote> à moins que quelqu'un ne vous donne les privilèges de
|
|
youshe@982
|
296 <quote>commit</quote> sur le serveur central. Avant ça, vous ne serez
|
|
youshe@982
|
297 pas capable d'enregistrer vos modifications, et vos propres
|
|
youshe@982
|
298 modifications risqueront de se corrompre chaque fois que vous
|
|
youshe@982
|
299 essayerez de mettre à jour à votre espace de travail avec le serveur
|
|
youshe@982
|
300 central.
|
|
youshe@982
|
301 </para>
|
|
youshe@982
|
302
|
|
youshe@982
|
303 <sect3>
|
|
youshe@982
|
304 <title>Le non-problème du "fork"</title>
|
|
youshe@982
|
305
|
|
youshe@982
|
306 <para id="x_92">Il a été souvent suggéré que les gestionnaires de
|
|
Wilk@1004
|
307 révisions distribués posent un risque pour les projets <emphasis
|
|
youshe@982
|
308 remap="it">Open Source</emphasis> car ils facilitent grandement la
|
|
youshe@982
|
309 création de <quote>fork</quote>.
|
|
youshe@982
|
310 <!--footnote{NdT:Création d'une <ulink url="version alternative du
|
|
youshe@982
|
311 logiciel">version alternative du
|
|
youshe@982
|
312 logiciel</ulink>{http://fr.wikipedia.org/wiki/Fork#Embranchement_d.27un_projet_informatique}
|
|
youshe@982
|
313 -->
|
|
youshe@982
|
314 Un <quote>fork</quote> apparait quand il y des divergences d'opinion
|
|
youshe@982
|
315 ou d'attitude au sein d'un groupe de développeurs qui aboutissent à
|
|
youshe@982
|
316 la décision de ne plus travailler ensemble. Chaque parti s'empare
|
|
youshe@982
|
317 d'une copie plus ou moins complète du code source du projet et
|
|
youshe@982
|
318 continue dans sa propre direction.
|
|
youshe@982
|
319 </para>
|
|
youshe@982
|
320
|
|
youshe@982
|
321
|
|
youshe@982
|
322 <para id="x_93">Parfois ces différents partis décident de se
|
|
youshe@982
|
323 réconcilier. Avec un serveur central, l'aspect
|
|
youshe@982
|
324 <emphasis>technique</emphasis> de cette réconciliation est un
|
|
youshe@982
|
325 processus douloureux, et essentiellement manuel. Vous devez décider
|
|
youshe@982
|
326 quelle modification est <quote>la gagnante</quote>, et replacer, par
|
|
youshe@982
|
327 un moyen ou un autre, les modifications de l'autre équipe dans
|
|
youshe@982
|
328 l'arborescence du projet. Ceci implique généralement la perte d'une
|
|
youshe@982
|
329 partie de l'historique d'un des partis, ou même des deux.
|
|
youshe@982
|
330 </para>
|
|
youshe@982
|
331
|
|
youshe@982
|
332 <para id="x_94">Ce que les outils distribués permettent à ce sujet est
|
|
youshe@982
|
333 probablement la <emphasis>meilleure</emphasis> façon de développer un
|
|
youshe@982
|
334 projet. Chaque modification que vous effectuez est potentiellement un
|
|
youshe@982
|
335 <quote>fork</quote>. La grande force de cette approche est que les
|
|
Wilk@1004
|
336 gestionnaires de révisions distribués doivent être vraiment très
|
|
youshe@982
|
337 efficaces pour <emphasis>fusionner (merge)</emphasis>
|
|
youshe@982
|
338 <!-- TODO footnote{NdT:j'ai choisi de traduire ici <emphasis
|
|
youshe@982
|
339 remap="it">merging</emphasis> par <quote>fusionner</quote> pour des
|
|
youshe@982
|
340 raisons de clarté} -->
|
|
youshe@982
|
341 des <quote>forks</quote>, car les <quote>forks</quote>, dans ce
|
|
youshe@982
|
342 contexte, arrivent tout le temps.
|
|
youshe@982
|
343 </para>
|
|
youshe@982
|
344
|
|
youshe@982
|
345 <para id="x_95">Si chaque altération que n'importe qui effectue, à tout
|
|
youshe@982
|
346 moment, est vue comme un <quote>fork</quote> à fusionner, alors ce
|
|
youshe@982
|
347 que le monde de l'<emphasis remap="it">Open Source</emphasis> voit
|
|
youshe@982
|
348 comme un <quote>fork</quote> devient <emphasis>uniquement</emphasis>
|
|
Wilk@1004
|
349 une problématique sociale. En fait, les outils de gestions de révisions
|
|
youshe@982
|
350 distribués <emphasis>réduisent</emphasis> les chances de
|
|
youshe@982
|
351 <quote>fork</quote> :
|
|
youshe@982
|
352 </para>
|
|
youshe@982
|
353
|
|
youshe@982
|
354 <itemizedlist>
|
|
youshe@982
|
355 <listitem>
|
|
youshe@982
|
356 <para>Ils éliminent la distinction sociale qu'imposent les outils
|
|
youshe@982
|
357 centralisés entre les membres du projets (ceux qui ont accès au
|
|
Wilk@1004
|
358 <quote>commit</quote>) et ceux de l'extérieur (qui ne l'ont
|
|
youshe@982
|
359 pas).
|
|
youshe@982
|
360 </para>
|
|
youshe@982
|
361 <para>Ils rendent plus facile la réconciliation après un
|
|
youshe@982
|
362 <quote>fork</quote> social, car tout ce qu'elle implique est une
|
|
youshe@982
|
363 simple fusion.
|
|
youshe@982
|
364 </para>
|
|
youshe@982
|
365 </listitem>
|
|
youshe@982
|
366 </itemizedlist>
|
|
youshe@982
|
367
|
|
youshe@982
|
368 <para id="x_98">Certaines personnes font de la résistance envers les
|
|
Wilk@1004
|
369 gestionnaires de révisions distribués parce qu'ils veulent garder un
|
|
youshe@982
|
370 contrôle ferme sur leur projet, et ils pensent que les outils
|
|
youshe@982
|
371 centralisés leur fournissent ce contrôle. Néanmoins, si c'est votre
|
|
youshe@982
|
372 cas, sachez que si vous publiez votre dépôt CVS ou Subversion de
|
|
youshe@982
|
373 manière publique, il existe une quantité d'outils disponibles pour
|
|
youshe@982
|
374 récupérer entièrement votre projet et son historique (quoique
|
|
youshe@982
|
375 lentement) et le récréer ailleurs, sans votre contrôle. En fait,
|
|
youshe@982
|
376 votre contrôle sur votre projet est illusoire, vous ne faites
|
|
youshe@982
|
377 qu'interdire à vos collaborateurs de travailler de manière fluide, en
|
|
youshe@982
|
378 disposant d'un miroir ou d'un <quote>fork</quote> de votre
|
|
youshe@982
|
379 historique.
|
|
youshe@982
|
380 </para>
|
|
youshe@982
|
381
|
|
youshe@982
|
382 </sect3>
|
|
belaran@967
|
383 </sect2>
|
|
belaran@967
|
384 <sect2>
|
|
belaran@967
|
385 <title>Avantages pour les projets commerciaux</title>
|
|
belaran@967
|
386
|
|
youshe@982
|
387 <para id="x_99">Beaucoup de projets commerciaux sont réalisés par des
|
|
youshe@982
|
388 équipes éparpillées à travers le globe. Les contributeurs qui sont
|
|
youshe@982
|
389 loin du serveur central devront subir des commandes lentes et même
|
|
Wilk@1004
|
390 parfois peu fiables. Les solutions propriétaires de gestion de révisions
|
|
youshe@982
|
391 tentent de palier ce problème avec des réplications de sites distants
|
|
youshe@982
|
392 qui sont à la fois coûteuses à mettre en place et lourdes à
|
|
youshe@982
|
393 administrer. Un système distribué ne souffre pas de ce genre de
|
|
youshe@982
|
394 problèmes. En outre, il est très aisé de mettre en place plusieurs
|
|
youshe@982
|
395 serveurs de références, disons un par site, de manière à ce qu'il n'y
|
|
youshe@982
|
396 ait pas de communication redondante entre les dépôts, sur une
|
|
youshe@982
|
397 connexion longue distance souvent onéreuse.
|
|
youshe@982
|
398 </para>
|
|
youshe@982
|
399
|
|
Wilk@1004
|
400 <para id="x_9a">Les systèmes de gestion de révisions supportent
|
|
youshe@982
|
401 généralement assez mal la monté en charge. Il n'est pas rare pour un
|
|
Wilk@1004
|
402 gestionnaire de révisions centralisé pourtant onéreux de s'effondrer
|
|
youshe@982
|
403 sous la charge combinée d'une douzaine d'utilisateurs concurrents
|
|
youshe@982
|
404 seulement. Une fois encore, la réponse à cette problématique est
|
|
youshe@982
|
405 généralement encore la mise en place d'un ensemble complexe de
|
|
youshe@982
|
406 serveurs synchronisés par un mécanisme de réplication. Dans le cas
|
|
Wilk@1004
|
407 d'un gestionnaire de révisions distribué, la charge du serveur central
|
|
Wilk@1004
|
408 &emdash; si vous en avez un&emdash; est largement inférieure (car
|
|
youshe@982
|
409 toutes les données sont déjà répliquées ailleurs), un simple serveur,
|
|
Wilk@1004
|
410 peu onéreux, peut gérer les besoins d'une plus grande équipe, et la
|
|
youshe@982
|
411 réplication pour balancer la charge devient le travail d'un simple
|
|
youshe@982
|
412 script.
|
|
youshe@982
|
413 </para>
|
|
youshe@982
|
414
|
|
youshe@982
|
415 <para id="x_9b">Si vous avez des employés sur le terrain, en train de
|
|
youshe@982
|
416 chercher à résoudre un souci sur le site d'un client, ils
|
|
Wilk@1004
|
417 bénéficieront aussi d'un gestionnaire de révisions distribué. Cet outil
|
|
youshe@982
|
418 leur permettra de générer des versions personnalisées, d'essayer
|
|
youshe@982
|
419 différentes solutions, en les isolant aisément les unes des autres,
|
|
youshe@982
|
420 et de rechercher efficacement à travers l'historique des sources, la
|
|
youshe@982
|
421 cause des bugs ou des régressions, tout ceci sans avoir besoin de la
|
|
youshe@982
|
422 moindre connexion au réseau de votre compagnie.
|
|
youshe@982
|
423 </para>
|
|
belaran@964
|
424
|
|
belaran@967
|
425 </sect2>
|
|
youshe@982
|
426 </sect1>
|
|
youshe@982
|
427 <sect1>
|
|
youshe@982
|
428 <title>Pourquoi choisir Mercurial?</title>
|
|
youshe@982
|
429
|
|
youshe@982
|
430 <para id="x_9c">Mercurial a plusieurs caractéristiques qui en font un
|
|
Wilk@1004
|
431 choix particulièrement pertinent pour la gestion de révisions :
|
|
youshe@982
|
432 </para>
|
|
belaran@967
|
433 <itemizedlist>
|
|
youshe@982
|
434 <listitem><para id="x_9d">Il est simple à apprendre et à utiliser.</para></listitem>
|
|
youshe@982
|
435 <listitem><para id="x_9e">Il est léger.</para></listitem>
|
|
youshe@982
|
436 <listitem><para id="x_9f">Il s'adapte très bien à la charge.</para></listitem>
|
|
youshe@982
|
437 <listitem><para id="x_a0">Il se personnalise facilement.</para></listitem>
|
|
youshe@982
|
438 </itemizedlist>
|
|
youshe@982
|
439
|
|
youshe@982
|
440 <para id="x_a1">Si vous êtes déjà familier d'un outil de gestion de
|
|
Wilk@1004
|
441 révisions, vous serez capable de l'utiliser en moins de 5 minutes. Sinon,
|
|
youshe@982
|
442 ça ne sera pas beaucoup plus long. Les commandes utilisées par
|
|
youshe@982
|
443 Mercurial, comme ses fonctionnalités, sont généralement uniformes et
|
|
youshe@982
|
444 cohérentes, et vous pouvez ainsi garder en tête simplement quelques
|
|
youshe@982
|
445 règles générales, plutôt qu'un lot complexe d'exceptions.
|
|
youshe@982
|
446 </para>
|
|
youshe@982
|
447
|
|
youshe@982
|
448 <para id="x_a2">Sur un petit projet, vous pouvez commencer à travailler
|
|
youshe@982
|
449 avec Mercurial en quelques instants. Ajouter des modifications ou des
|
|
youshe@982
|
450 branches, transférer ces modifications (localement ou via le réseau),
|
|
youshe@982
|
451 et les opérations d'historique ou de statut sont aussi très rapides.
|
|
Wilk@1004
|
452 Mercurial ne vous encombre pas grâce à sa simplicité
|
|
youshe@982
|
453 d'utilisation et sa rapidité d'exécution.
|
|
youshe@982
|
454 </para>
|
|
youshe@982
|
455
|
|
youshe@982
|
456 <para id="x_a3">L'utilité de Mercurial ne se limite pas à de petits
|
|
youshe@982
|
457 projets: il est aussi utilisé par des projets ayant des centaines ou
|
|
youshe@982
|
458 même des milliers de contributeurs, avec plusieurs dizaines de milliers
|
|
youshe@982
|
459 de fichiers, et des centaines de méga octets de code source.
|
|
youshe@982
|
460 </para>
|
|
youshe@982
|
461
|
|
youshe@982
|
462 <para id="x_a4">Si les fonctionnalités au cœur de Mercurial ne sont pas
|
|
youshe@982
|
463 suffisantes pour vous, il est très aisé d'en construire d'autres.
|
|
youshe@982
|
464 Mercurial est adapté à l'utilisation de scripts, et son implémentation
|
|
youshe@982
|
465 interne en Python, propre et claire, rend encore plus facile l'ajout de
|
|
youshe@982
|
466 fonctionnalités sous forme d'extensions. Il en existe déjà un certain
|
|
youshe@982
|
467 nombre de très populaires et très utiles, dont le périmètre va de la
|
|
youshe@982
|
468 recherche de bugs à l'amélioration des performances.
|
|
youshe@982
|
469 </para>
|
|
belaran@964
|
470
|
|
belaran@967
|
471 </sect1>
|
|
belaran@967
|
472 <sect1>
|
|
belaran@967
|
473 <title>Mercurial comparé aux autres outils</title>
|
|
belaran@967
|
474
|
|
youshe@982
|
475 <para id="x_a5">Avant que vous n'alliez plus loin, comprenez bien que
|
|
youshe@982
|
476 cette section reflète mes propres expériences, et elle est donc (j'ose
|
|
youshe@982
|
477 le dire) peu objective. Néanmoins, j'ai utilisé les outils de gestion
|
|
youshe@982
|
478 de source listés ci dessous, dans la plupart des cas, pendant plusieurs
|
|
youshe@982
|
479 années.
|
|
youshe@982
|
480 </para>
|
|
belaran@967
|
481
|
|
belaran@967
|
482 <sect2>
|
|
belaran@967
|
483 <title>Subversion</title>
|
|
belaran@967
|
484
|
|
Wilk@1004
|
485 <para id="x_a6">Subversion est un des outils de gestion de révisions les
|
|
youshe@982
|
486 plus populaire, il fût développé pour remplacer CVS. Il a une
|
|
youshe@982
|
487 architecture client/server centralisée.
|
|
youshe@982
|
488 </para>
|
|
youshe@982
|
489
|
|
youshe@982
|
490 <para id="x_a7">Subversion et Mercurial ont des noms de commandes très
|
|
youshe@982
|
491 similaires pour les mêmes opérations, ainsi si vous êtes familier
|
|
youshe@982
|
492 avec l'un, c'est facile d'apprendre l'autre. Ces deux outils sont
|
|
youshe@982
|
493 portables sur les systèmes d'exploitation les plus populaires.
|
|
youshe@982
|
494 </para>
|
|
youshe@982
|
495
|
|
youshe@982
|
496 <para id="x_a8">Avant la version 1.5, Subversion n'offrait aucune forme
|
|
youshe@982
|
497 de support pour les fusions. Lors de l'écriture de ce livre, ses
|
|
youshe@982
|
498 capacités de fusion étaient nouvelles, et réputées pour être <ulink
|
|
youshe@982
|
499 url="http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword">
|
|
youshe@982
|
500 complexes et buguées</ulink>.
|
|
youshe@982
|
501 </para>
|
|
youshe@982
|
502
|
|
youshe@982
|
503 <para id="x_a9">Mercurial dispose d'un avantage substantiel en terme de
|
|
youshe@982
|
504 performance par rapport à Subversion sur la plupart des opérations
|
|
youshe@982
|
505 que j'ai pu tester. J'ai mesuré une différence de performance allant
|
|
youshe@982
|
506 de deux à six fois plus rapide avec le système de stockage de fichier
|
|
youshe@982
|
507 local de Subversion 1.4.3 (<emphasis>ra_local</emphasis>), qui est la
|
|
youshe@982
|
508 méthode d'accès la plus rapide disponible. Dans un déploiement plus
|
|
youshe@982
|
509 réaliste, impliquant un stockage réseau, Subversion serait encore
|
|
youshe@982
|
510 plus désavantagé. Parce que la plupart des commandes Subversion
|
|
youshe@982
|
511 doivent communiquer avec le serveur et que Subversion n'a pas de
|
|
youshe@982
|
512 mécanisme de réplication, la capacité du serveur et la bande passante
|
|
youshe@982
|
513 sont devenues des goulots d'étranglement pour les projets de taille
|
|
youshe@982
|
514 moyenne ou grande.
|
|
youshe@982
|
515 </para>
|
|
youshe@982
|
516
|
|
youshe@982
|
517 <para id="x_aa">En outre, Subversion implique une surcharge
|
|
youshe@982
|
518 substantielle dans le stockage local de certaines données, pour
|
|
youshe@982
|
519 éviter des transactions avec le serveur, pour certaines opérations
|
|
youshe@982
|
520 communes, telles que la recherche des fichiers modifiés
|
|
youshe@982
|
521 (<literal>status</literal>) et l'affichage des modifications par
|
|
youshe@982
|
522 rapport à la révision courante (<literal>diff</literal>). En
|
|
youshe@982
|
523 conséquence, un répertoire de travail Subversion a souvent la même
|
|
youshe@982
|
524 taille, ou est plus grand, qu'un dépôt Mercurial et son espace de
|
|
youshe@982
|
525 travail, et ceci bien que le dépôt Mercurial contienne l'intégralité
|
|
youshe@982
|
526 de l'historique.
|
|
youshe@982
|
527 </para>
|
|
youshe@982
|
528
|
|
youshe@982
|
529 <para id="x_ab">Subversion est largement supporté par les outils
|
|
youshe@982
|
530 tierces. Mercurial est actuellement encore en retrait de ce point de
|
|
youshe@982
|
531 vue. L'écart se réduit néanmoins, en effet, certains des outils
|
|
youshe@982
|
532 graphiques sont maintenant supérieurs à leurs équivalents Subversion.
|
|
youshe@982
|
533 Comme Mercurial, Subversion dispose d'un excellent manuel
|
|
youshe@982
|
534 utilisateur.
|
|
youshe@982
|
535 </para>
|
|
youshe@982
|
536
|
|
youshe@982
|
537 <para id="x_ac">Parce que Subversion ne stocke pas l'historique chez
|
|
youshe@982
|
538 ses clients, il est parfaitement adapté à la gestion de projets qui
|
|
youshe@982
|
539 doivent suivre un ensemble de larges fichiers binaires et opaques. Si
|
|
youshe@982
|
540 vous suivez une cinquantaine de versions d'un fichier incompressible
|
|
youshe@982
|
541 de 10MB, l'occupation disque coté client d'un projet sous Subversion
|
|
youshe@982
|
542 restera à peu près constante. A l'inverse, l'occupation disque du
|
|
Wilk@1004
|
543 même projet sous n'importe lequel des gestionnaires de révisions
|
|
youshe@982
|
544 distribués grandira rapidement, proportionnellement aux nombres de
|
|
youshe@982
|
545 versions, car les différences entre chaque révisions seront très
|
|
youshe@982
|
546 grandes.
|
|
youshe@982
|
547 </para>
|
|
youshe@982
|
548
|
|
youshe@982
|
549 <para id="x_ad">En outre, c'est souvent difficile ou, généralement,
|
|
youshe@982
|
550 impossible de fusionner des différences dans un fichier binaire. La
|
|
youshe@982
|
551 capacité de Subversion de verrouiller des fichiers, pour permettre à
|
|
youshe@982
|
552 l'utilisateur d'être le seul à le mettre à jour
|
|
youshe@982
|
553 (<quote>commit</quote>) temporairement, est un avantage significatif
|
|
youshe@982
|
554 dans un projet doté de beaucoup de fichiers binaires.
|
|
youshe@982
|
555 </para>
|
|
youshe@982
|
556
|
|
youshe@982
|
557 <para id="x_ae">Mercurial peut importer l'historique depuis un dépôt
|
|
youshe@982
|
558 Subversion. Il peut aussi exporter l'ensemble des révisions d'un
|
|
youshe@982
|
559 projet vers un dépôt Subversion. Ceci rend très facile de
|
|
youshe@982
|
560 <quote>prendre la température</quote> et d'utiliser Mercurial et
|
|
youshe@982
|
561 Subversion en parallèle, avant de décider de migrer vers Mercurial.
|
|
youshe@982
|
562 La conversion de l'historique est incrémentale, donc vous pouvez
|
|
youshe@982
|
563 effectuer une conversion initiale, puis de petites additions par la
|
|
youshe@982
|
564 suite pour ajouter les nouvelle modifications.
|
|
youshe@982
|
565 </para>
|
|
belaran@964
|
566
|
|
belaran@967
|
567
|
|
belaran@967
|
568 </sect2>
|
|
belaran@967
|
569 <sect2>
|
|
belaran@967
|
570 <title>Git</title>
|
|
belaran@967
|
571
|
|
Wilk@1004
|
572 <para id="x_af">Git est un outil de gestion de révisions distribué qui fût
|
|
youshe@982
|
573 développé pour gérer le code source de noyau de Linux. Comme
|
|
youshe@982
|
574 Mercurial, sa conception initiale a été inspirée par Monotone.
|
|
youshe@982
|
575 </para>
|
|
youshe@982
|
576
|
|
youshe@982
|
577 <para id="x_b0">Git dispose d'un ensemble conséquent de commandes, avec
|
|
youshe@982
|
578 plus de 139 commandes individuelles pour la version 1.5.0. Il a aussi
|
|
youshe@982
|
579 la réputation d'être difficile à apprendre. Comparé à Git, le point
|
|
youshe@982
|
580 fort de Mercurial est clairement sa simplicité.
|
|
youshe@982
|
581 </para>
|
|
youshe@982
|
582
|
|
youshe@982
|
583 <para id="x_b1">En terme de performance, Git est extrêmement rapide.
|
|
youshe@982
|
584 Dans la plupart des cas, il est plus rapide que Mercurial, tout du
|
|
youshe@982
|
585 moins sur Linux, alors que Mercurial peut être plus performant sur
|
|
youshe@982
|
586 d'autres opérations. Néanmoins, sur Windows, les performances et le
|
|
youshe@982
|
587 niveau de support général fourni par Git, au moment de l'écriture de
|
|
youshe@982
|
588 cet ouvrage, est bien derrière celui de Mercurial.
|
|
youshe@982
|
589 </para>
|
|
youshe@982
|
590
|
|
youshe@982
|
591 <para id="x_b2">Alors que le dépôt Mercurial ne demande aucune
|
|
youshe@982
|
592 maintenance, un dépôt Git exige d'exécuter manuellement et
|
|
youshe@982
|
593 régulièrement la commande <quote>repacks</quote> sur ses métadonnées.
|
|
youshe@982
|
594 Sans ceci, les performances de git se dégradent et la consommation de
|
|
youshe@982
|
595 l'espace disque augmente rapidement. Un serveur qui contient
|
|
youshe@982
|
596 plusieurs dépôts Git qui ne sont pas régulièrement et fréquemment
|
|
youshe@982
|
597 <quote>repacked</quote> deviendra un vrai problème lors des
|
|
youshe@982
|
598 <quote>backups</quote> du disque, et il y eu des cas, où un
|
|
youshe@982
|
599 <quote>backup</quote> journalier pouvait durer plus de 24 heures. Un
|
|
youshe@982
|
600 dépôt fraichement <quote>repacked</quote> sera légèrement plus petit
|
|
youshe@982
|
601 qu'un dépôt Mercurial, mais un dépôt non <quote>repacked</quote> est
|
|
youshe@982
|
602 beaucoup plus grand.
|
|
youshe@982
|
603 </para>
|
|
youshe@982
|
604
|
|
youshe@982
|
605 <para id="x_b3">Le cœur de Git est écrit en C. La plupart des commandes
|
|
youshe@982
|
606 Git sont implémentées sous forme de scripts Shell ou Perl, et la
|
|
youshe@982
|
607 qualité de ces scripts varie grandement. J'ai plusieurs fois constaté
|
|
youshe@982
|
608 que certains de ces scripts étaient chargés en mémoire aveuglément et
|
|
Wilk@1004
|
609 que la présence d'erreurs pouvait s'avérer fatale.
|
|
youshe@982
|
610 </para>
|
|
youshe@982
|
611
|
|
youshe@982
|
612 <para id="x_b4">Mercurial peut importer l'historique d'un dépôt Git.</para>
|
|
belaran@967
|
613
|
|
belaran@967
|
614 </sect2>
|
|
belaran@967
|
615 <sect2>
|
|
belaran@967
|
616 <title>CVS</title>
|
|
belaran@967
|
617
|
|
Wilk@1004
|
618 <para id="x_b5">CVS est probablement l'outil de gestion de révisions le
|
|
youshe@982
|
619 plus utilisé aujourd'hui dans le monde. À cause de son manque de
|
|
youshe@982
|
620 clarté interne, il n'est plus maintenu depuis plusieurs années.
|
|
youshe@982
|
621 </para>
|
|
youshe@982
|
622
|
|
youshe@982
|
623 <para id="x_b6">Il a une architecture client/serveur centralisée. Il ne
|
|
youshe@982
|
624 regroupe pas les modifications de fichiers dans une opération de
|
|
youshe@982
|
625 <quote>commit</quote> atomique, ce qui permet à ses utilisateurs de
|
|
Wilk@1004
|
626 <quote>casser le <emphasis>build</emphasis></quote> assez facilement :
|
|
Wilk@1004
|
627 une personne peut effectuer une opération de <quote>commit</quote>
|
|
youshe@982
|
628 sans problème puis être bloquée par besoin de fusion, avec comme
|
|
youshe@982
|
629 conséquence néfaste, que les autres utilisateurs ne récupèreront
|
|
youshe@982
|
630 qu'une partie de ses modifications. Ce problème affecte aussi la
|
|
youshe@982
|
631 manière de travailler avec l'historique du projet. Si vous voulez
|
|
youshe@982
|
632 voir toutes les modifications d'une personne du projet, vous devrez
|
|
youshe@982
|
633 injecter manuellement les descriptions et les <emphasis
|
|
youshe@982
|
634 remap="it">timestamps</emphasis> des modifications de chacun des
|
|
youshe@982
|
635 fichiers impliqués (si vous savez au moins quels sont ces fichiers).
|
|
youshe@982
|
636 </para>
|
|
belaran@964
|
637
|
|
belaran@967
|
638 <para id="x_b7">CVS a une notion étrange des <emphasis
|
|
youshe@982
|
639 remap="it">tags</emphasis> et des branches que je n'essayerai même
|
|
youshe@982
|
640 pas de décrire ici. Il ne supporte pas bien les opérations de
|
|
youshe@982
|
641 renommage d'un fichier ou d'un répertoire, ce qui facilite la
|
|
youshe@982
|
642 corruption de son dépôt. Il n'a presque pas pour ainsi dire de
|
|
youshe@982
|
643 contrôle de cohérence interne, il est donc pratiquement impossible de
|
|
youshe@982
|
644 dire si un dépôt est corrompu ni à quel point. Je ne recommanderai
|
|
youshe@982
|
645 pas CVS pour un projet existant ou nouveau.
|
|
youshe@982
|
646 </para>
|
|
youshe@982
|
647
|
|
youshe@982
|
648 <para id="x_b8">Mercurial peut importer l'historique d'un projet CVS.
|
|
youshe@982
|
649 Néanmoins, il y a quelques principes à respecter; ce qui est vrai
|
|
youshe@982
|
650 aussi pour les autres outils d'import de projet CVS. À cause de
|
|
Wilk@1004
|
651 l'absence de <quote>commit</quote> atomique et gestion de versions de
|
|
youshe@982
|
652 l'arborescence, il n'est pas possible de reconstruire de manière
|
|
youshe@982
|
653 précise l'ensemble de l'historique. Un travail de
|
|
youshe@982
|
654 <quote>devinette</quote> est donc nécessaire, et les fichiers
|
|
youshe@982
|
655 renommés ne sont pas détectés. Parce qu'une bonne part de
|
|
youshe@982
|
656 l'administration d'un dépôt CVS est effectuée manuellement, et est
|
|
youshe@982
|
657 donc, sujette à erreur, il est courant que les imports CVS
|
|
youshe@982
|
658 rencontrent de nombreux problèmes avec les dépôt corrompus (des
|
|
youshe@982
|
659 <emphasis remap="it">timestamps</emphasis> de révision complètement
|
|
youshe@982
|
660 buggés et des fichiers verrouillés depuis des années sont deux des
|
|
youshe@982
|
661 problèmes les moins intéressants dont je me souvienne).
|
|
youshe@982
|
662 </para>
|
|
belaran@967
|
663
|
|
belaran@967
|
664 <para id="x_b9">Mercurial peut importer l'historique depuis un dépôt CVS.
|
|
youshe@982
|
665 </para>
|
|
belaran@967
|
666
|
|
belaran@967
|
667
|
|
belaran@967
|
668 </sect2>
|
|
belaran@967
|
669 <sect2>
|
|
belaran@967
|
670 <title>Outils propriétaires</title>
|
|
belaran@967
|
671
|
|
youshe@982
|
672 <para id="x_ba">Perforce a une architecture client/serveur centralisée,
|
|
youshe@982
|
673 sans aucun mécanisme de mise en cache de données coté client.
|
|
Wilk@1004
|
674 Contrairement à la plupart des outils modernes de gestion de révisions,
|
|
youshe@982
|
675 Perforce exige de ses utilisateurs d'exécuter une commande pour
|
|
youshe@982
|
676 informer le serveur central de tout fichier qu'ils souhaitent
|
|
youshe@982
|
677 modifier.
|
|
youshe@982
|
678 </para>
|
|
youshe@982
|
679
|
|
youshe@982
|
680 <para id="x_bb">Les performances de Perforce sont plutôt bonnes pour
|
|
youshe@982
|
681 des petites équipes, mais elles s'effondrent rapidement lorsque le
|
|
youshe@982
|
682 nombre d'utilisateurs augmente au delà de la douzaine. Des
|
|
youshe@982
|
683 installations de Perforce assez larges nécessitent le déploiement de
|
|
youshe@982
|
684 proxies pour supporter la montée en charge associée.
|
|
youshe@982
|
685 </para>
|
|
belaran@967
|
686
|
|
belaran@967
|
687 </sect2>
|
|
belaran@967
|
688 <sect2>
|
|
Wilk@1004
|
689 <title>Choisir un outil de gestion de révisions</title>
|
|
belaran@967
|
690
|
|
youshe@982
|
691 <para id="x_bc">A l'exception de CVS, tous les outils listés ci-dessus
|
|
Wilk@1004
|
692 ont des forces qui leurs sont propres et qui correspondent à certaines
|
|
youshe@982
|
693 formes de projet. Il n'y a pas un seul meilleur outil de gestion de
|
|
Wilk@1004
|
694 révisions qui correspondrait le mieux à toutes les situations.
|
|
youshe@982
|
695 </para>
|
|
youshe@982
|
696
|
|
youshe@982
|
697 <para id="x_bd">En guise exemple, Subversion est un très bon choix
|
|
youshe@982
|
698 lorsqu'on travaille avec beaucoup de fichiers binaires, qui évoluent
|
|
youshe@982
|
699 régulièrement, grâce à sa nature centralisée et sa capacité à
|
|
youshe@982
|
700 verrouiller des fichiers.
|
|
youshe@982
|
701 </para>
|
|
youshe@982
|
702
|
|
youshe@982
|
703 <para id="x_be">Personnellement, je préfère Mercurial pour sa
|
|
youshe@982
|
704 simplicité, ses performances et sa bonne capacité de fusion, et il
|
|
youshe@982
|
705 m'a très bien rendu service de plusieurs années maintenant.
|
|
youshe@982
|
706 </para>
|
|
belaran@967
|
707
|
|
belaran@967
|
708 </sect2>
|
|
belaran@967
|
709 </sect1>
|
|
belaran@967
|
710 <sect1>
|
|
belaran@967
|
711 <title>Migrer depuis un outil à Mercurial</title>
|
|
belaran@967
|
712
|
|
youshe@982
|
713 <para id="x_bf">Mercurial est livré avec une extension nommée <literal
|
|
youshe@982
|
714 role="hg-ext">convert</literal>, qui peut, de manière incrémentale
|
|
youshe@982
|
715 importer des révisions depuis différents autres outils de gestion de
|
|
youshe@982
|
716 source. Par <quote>incrémental</quote>, j'entends que vous pouvez
|
|
youshe@982
|
717 convertir l'historique entier du projet en une seule fois, puis
|
|
youshe@982
|
718 relancer l'outil d'import plus tard pour obtenir les modifications
|
|
youshe@982
|
719 effectuées depuis votre import initial.
|
|
youshe@982
|
720 </para>
|
|
youshe@982
|
721
|
|
Wilk@1004
|
722 <para id="x_c0">Les outils de gestion de révisions supportés par <literal
|
|
youshe@982
|
723 role="hg-ext">convert</literal> sont :
|
|
youshe@982
|
724 </para>
|
|
belaran@967
|
725 <itemizedlist>
|
|
belaran@967
|
726 <listitem><para id="x_c1">Subversion</para></listitem>
|
|
belaran@967
|
727 <listitem><para id="x_c2">CVS</para></listitem>
|
|
belaran@967
|
728 <listitem><para id="x_c3">Git</para></listitem>
|
|
youshe@982
|
729 <listitem><para id="x_c4">Darcs</para></listitem>
|
|
youshe@982
|
730 </itemizedlist>
|
|
youshe@982
|
731
|
|
youshe@982
|
732 <para id="x_c5">En outre, <literal role="hg-ext">convert</literal> peut
|
|
youshe@982
|
733 exporter les modifications depuis Mercurial vers Subversion. Ceci rend
|
|
youshe@982
|
734 possible d'essayer Subversion en parallèle avant de choisir une
|
|
youshe@982
|
735 solution définitive, sans aucun risque de perte de données.
|
|
youshe@982
|
736 </para>
|
|
youshe@982
|
737
|
|
youshe@982
|
738 <para id="x_c6">La commande <command
|
|
youshe@982
|
739 role="hg-ext-conver">convert</command> est très simple à utiliser.
|
|
youshe@982
|
740 Simplement, indiquez le chemin ou l'URL du dépôt de source, en lui
|
|
youshe@982
|
741 indiquant éventuellement le nom du chemin de destination, et la
|
|
youshe@982
|
742 conversion se met en route. Après cet import initial, il suffit de
|
|
youshe@982
|
743 relancer la commande encore une fois pour importer les modifications
|
|
youshe@982
|
744 effectuées depuis.
|
|
youshe@982
|
745 </para>
|
|
belaran@967
|
746 </sect1>
|
|
belaran@967
|
747
|
|
belaran@967
|
748 <sect1>
|
|
Wilk@1004
|
749 <title>Une courte histoire de la gestion de révisions</title>
|
|
Wilk@1004
|
750
|
|
Wilk@1004
|
751 <para id="x_c7">Le plus célèbre des anciens outils de gestion de révisions
|
|
youshe@982
|
752 est <emphasis remap="it">SCCS</emphasis> (Source Code Control System)},
|
|
youshe@982
|
753 que Marc Rochkind conçu dans les laboratoires de recherche de Bell
|
|
youshe@982
|
754 (<emphasis remap="it">Bell Labs</emphasis>), dans le début des années
|
|
youshe@982
|
755 70. <emphasis remap="it">SCCS</emphasis> ne fonctionnait que sur des
|
|
youshe@982
|
756 fichiers individuels, et obligeait chaque personne travaillant sur le
|
|
youshe@982
|
757 projet d'avoir un accès à un répertoire de travail commun, sur le même
|
|
youshe@982
|
758 système. Seulement une seule personne pouvait modifier un fichier au
|
|
youshe@982
|
759 même moment, ce fonctionnement était assuré par l'utilisation de verrou
|
|
youshe@982
|
760 (<quote>lock</quote>). Il était courant que des personnes verrouillent
|
|
youshe@982
|
761 des fichiers, et plus tard, oublient de le déverrouiller ; empêchant
|
|
youshe@982
|
762 n'importe qui d'autre de travailler sur ces fichiers sans l'aide de
|
|
youshe@982
|
763 l'administrateur...
|
|
youshe@982
|
764 </para>
|
|
belaran@967
|
765
|
|
belaran@967
|
766 <para id="x_c8">Walter Tichy a développé une alternative libre à
|
|
youshe@982
|
767 <emphasis remap="it">SCCS</emphasis> au début des années 80, qu'il
|
|
youshe@982
|
768 nomma <emphasis remap="it">RCS (Revision Control System)</emphasis>.
|
|
youshe@982
|
769 Comme <emphasis remap="it">SCCS</emphasis>, <emphasis
|
|
youshe@982
|
770 remap="it">RCS</emphasis> demandait aux développeurs de travailler
|
|
youshe@982
|
771 sur le même répertoire partagé, et de verrouiller les fichiers pour se
|
|
youshe@982
|
772 prémunir de tout conflit issu de modifications concurrentes.
|
|
youshe@982
|
773 </para>
|
|
youshe@982
|
774
|
|
youshe@982
|
775 <para id="x_c9">Un peu plus tard dans les années 1980, Dick Grune utilisa
|
|
youshe@982
|
776 <emphasis remap="it">RCS</emphasis> comme une brique de base pour un
|
|
youshe@982
|
777 ensemble de scripts <emphasis remap="it">shell</emphasis> qu'il
|
|
youshe@982
|
778 intitula cmt, avant de la renommer en <emphasis remap="it">CVS
|
|
youshe@982
|
779 (Concurrent Versions System)</emphasis>. La grande innovation de CVS
|
|
youshe@982
|
780 était que les développeurs pouvaient travailler simultanément et
|
|
youshe@982
|
781 indépendamment dans leur propre espace de travail. Ces espaces de
|
|
youshe@982
|
782 travail privés assuraient que les développeurs ne se marchent pas
|
|
youshe@982
|
783 mutuellement sur les pieds, comme c'était souvent le cas avec RCS et
|
|
youshe@982
|
784 SCCS. Tous les développeurs disposaient donc de leur copie de tous les
|
|
youshe@982
|
785 fichiers du projet, et ils pouvaient donc librement les modifier. Ils
|
|
youshe@982
|
786 devaient néanmoins effectuer la <quote>fusion</quote> (<emphasis
|
|
youshe@982
|
787 remap="it"><quote>merge</quote></emphasis>) de leurs fichiers, avant
|
|
youshe@982
|
788 d'effectuer le <quote>commit</quote> de leurs modifications sur le dépôt
|
|
youshe@982
|
789 central.
|
|
youshe@982
|
790 </para>
|
|
youshe@982
|
791
|
|
youshe@982
|
792 <para>Brian Berliner reprit les scripts de Grune's et les réécrit en C,
|
|
youshe@982
|
793 qu'il publia en 1989. Depuis, ce code a été modifié jusqu'à devenir la
|
|
youshe@982
|
794 version moderne de CVS. CVS a acquis ainsi la capacité de fonctionner
|
|
youshe@982
|
795 en réseau, transformant son architecture en client/serveur.
|
|
youshe@982
|
796 L'architecture de CVS est centralisée, seul le serveur a une copie de
|
|
youshe@982
|
797 l'historique du projet. L'espace de travail client ne contient qu'une
|
|
youshe@982
|
798 copie de la dernière version du projet, et quelques métadonnées pour
|
|
youshe@982
|
799 indiquer où le serveur se trouve. CVS a été un grand succès,
|
|
Wilk@1004
|
800 aujourd'hui il est probablement l'outil de gestion de révisions le plus
|
|
youshe@982
|
801 utilisé au monde.
|
|
youshe@982
|
802 </para>
|
|
youshe@982
|
803
|
|
youshe@982
|
804 <para>Au début des années 1990, Sun Microsystems développa un premier
|
|
Wilk@1004
|
805 outil de gestion de révisions distribué, nommé TeamWare. Un espace de
|
|
youshe@982
|
806 travail TeamWare contient une copie complète de l'historique du projet.
|
|
youshe@982
|
807 TeamWare n'a pas de notion de dépôt central. (CVS utilisait RCS pour le
|
|
youshe@982
|
808 stockage de l'historique, TeamWare utilisait SCCS).
|
|
youshe@982
|
809 </para>
|
|
youshe@982
|
810
|
|
youshe@982
|
811 <para>Alors que les années 1990 avançaient, les utilisateurs ont pris
|
|
youshe@982
|
812 conscience d'un certain nombre de problèmes avec CVS. Il enregistrait
|
|
youshe@982
|
813 simultanément des modifications sur différents fichiers
|
|
youshe@982
|
814 individuellement, au lieu de les regrouper dans une seule opération
|
|
youshe@982
|
815 cohérente et atomique. Il ne gère pas bien sa hiérarchie de fichier, il
|
|
youshe@982
|
816 est donc assez aisé de créer le chaos en renommant les fichiers et les
|
|
youshe@982
|
817 répertoires. Pire encore, son code source est difficile à lire et à
|
|
youshe@982
|
818 maintenir, ce qui agrandit largement le <quote>niveau de
|
|
youshe@982
|
819 souffrance</quote> associé à la réparation de ces problèmes
|
|
youshe@982
|
820 d'architecture de manière prohibitive.
|
|
youshe@982
|
821 </para>
|
|
youshe@982
|
822
|
|
youshe@982
|
823 <para>En 2001, Jim Blandy et Karl Fogel, deux développeurs qui avaient
|
|
youshe@982
|
824 travaillé sur CVS, initièrent un projet pour le remplacer par un outil
|
|
youshe@982
|
825 qui aurait une meilleure architecture et un code plus propre. Le
|
|
youshe@982
|
826 résultat, Subversion, ne quitte pas le modèle centralisé et
|
|
youshe@982
|
827 client/server de CVS, mais ajoute les opérations de
|
|
youshe@982
|
828 <quote>commit</quote> atomique sur de multiples fichiers, une meilleure
|
|
youshe@982
|
829 gestion des espaces de noms, et d'autres fonctionnalités qui en font un
|
|
youshe@982
|
830 meilleur outil que CVS. Depuis sa première publication, il est
|
|
youshe@982
|
831 rapidement devenu très populaire.
|
|
youshe@982
|
832 </para>
|
|
youshe@982
|
833
|
|
youshe@982
|
834 <para>Plus ou moins simultanément, Graydon Hoare a commencé sur
|
|
Wilk@1004
|
835 l'ambitieux système de gestion distribuée Monotone. Bien que Monotone
|
|
youshe@982
|
836 corrige plusieurs défauts de CVS tout en offrant une architecture
|
|
youshe@982
|
837 <quote>peer-to-peer</quote>, il va aussi plus loin que la plupart des
|
|
Wilk@1004
|
838 outils de gestion de révisions de manière assez innovante. Il utilise des
|
|
youshe@982
|
839 <quote>hashs</quote> cryptographiques comme identifiants, et il a une
|
|
youshe@982
|
840 notion complète de <quote>confiance</quote> du code issu des
|
|
youshe@982
|
841 différentes sources.
|
|
youshe@982
|
842 </para>
|
|
youshe@982
|
843
|
|
youshe@982
|
844 <para>Mercurial est né en 2005. Bien que très influencé par Monotone,
|
|
youshe@982
|
845 Mercurial se concentre sur la facilité d'utilisation, les performances
|
|
Wilk@1004
|
846 et la capacité à monter en charge sur de très gros projets.
|
|
youshe@982
|
847 </para>
|
|
youshe@982
|
848
|
|
youshe@982
|
849 </sect1>
|
|
belaran@967
|
850
|
|
belaran@964
|
851 </chapter>
|
|
belaran@964
|
852
|
|
belaran@964
|
853 <!--
|
|
belaran@964
|
854 local variables:
|
|
belaran@964
|
855 sgml-parent-document: ("00book.xml" "book" "chapter")
|
|
belaran@964
|
856 end:
|
|
belaran@967
|
857 -->
|
