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