hgbook
annotate fr/ch01-intro.xml @ 983:5e1e70fcdfdb
Corrected some errors.
- Indentation problems
- Syntax errors (missing </para>,...)
- French mistakes
- Indentation problems
- Syntax errors (missing </para>,...)
- French mistakes
| author | Frédéric Bouquet <youshe.jaalon@gmail.com> |
|---|---|
| date | Tue Sep 08 23:42:42 2009 +0200 (2009-09-08) |
| parents | f25ab8d4486f |
| children | 0298bccbb8ee |
| 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 --> |