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