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