belaran@964: <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
belaran@964: 
belaran@967: <chapter id="chap:intro">
belaran@967:   <?dbhtml filename="how-did-we-get-here.html"?>
andre@1014:   <title>Comment en est-on arrivé là ?</title>
belaran@964: 
belaran@964: <sect1>
Wilk@1004: <title>À propos de la gestion de révisions. Pourquoi Mercurial ?</title>
Wilk@1004: 
Wilk@1004:     <para id="x_6d">La gestion de révisions est un processus permettant de gérer différentes
belaran@964: versions de la même information. Dans sa forme la plus simple, c'est
belaran@964: ce que tout le monde fait manuellement : quand vous modifiez
belaran@964: un fichier, vous le sauvegardez sous un nouveau nom contenant un numéro,
belaran@964: à chaque fois plus grand que celui de la version précédente.</para>
belaran@964: 
Wilk@1004:     <para id="x_6e">Ce genre de gestion de révisions manuelle, ne serait-ce que 
Wilk@1004:         d'un seul fichier, est cependant facilement sujette
youshe@982: aux erreurs, ainsi, depuis longtemps, des logiciels existent pour
Wilk@1004: résoudre cette problématique. Les premiers outils de gestion de révisions
belaran@964: étaient destinés à aider un seul utilisateur, à automatiser la gestion
andre@1014: des versions d'un seul fichier. Durant les dernières décennies, cette cible
belaran@964: s'est largement agrandie, ils gèrent désormais de multiples fichiers, et
belaran@964: aident un grand nombre de personnes à travailler ensemble. Les outils les
belaran@964: plus modernes n'ont aucune difficulté à gérer plusieurs milliers de
belaran@964: personnes travaillant ensemble sur des projets regroupant plusieurs
belaran@964: centaines de milliers de fichiers.</para>
belaran@964: 
Wilk@1004:     <para id="x_6f">L'arrivée de la gestion de révisions distribuée est
belaran@967:     relativement récente, et, pour le moment, ce nouveau domaine a grandi
youshe@982:     grâce à la volonté des gens d'explorer ces territoires encore inconnus.
belaran@967:     </para>
belaran@967: 
Wilk@1004:     <para id="x_70">J'écris un livre sur la gestion de révisions distribuée
belaran@967:     parce que je pense qu'il s'agit d'un sujet important qui mérite un guide
Wilk@1004:     de terrain. J'ai choisi d'écrire un livre sur Mercurial car il est
belaran@967:     l'outil le plus facile pour découvrir ce nouveau domaine, tout en étant
youshe@982:     un outil efficace qui répond aux demandes d'environnements réels et
Wilk@1004:     difficiles, là où d'autres outils de gestion de révisions s'effondrent.</para>
belaran@967: 
belaran@967:     <sect2>
Wilk@1004:       <title>Pourquoi utiliser un gestionnaire de révisions ?</title>
belaran@967: 
belaran@967:       <para id="x_71">Il y a de nombreuses raisons pour que vous ou votre équipe souhaitiez
Wilk@1004: utiliser un outil automatisant la gestion de révisions pour votre projet.</para>
belaran@967: 
belaran@967:       <itemizedlist>
belaran@967: 	<listitem><para id="x_72">L'outil se chargera de suivre l'évolution de votre projet, sans
youshe@982: que vous ayez à le faire. Pour chaque modification, vous aurez à votre
belaran@964: disposition un journal indiquant <emphasis>qui</emphasis> a fait quoi, <emphasis>pourquoi</emphasis>
youshe@982: il l'a fait, <emphasis>quand</emphasis> il l'a fait, et
youshe@982: <emphasis>ce</emphasis> qu'il a modifié.</para>
belaran@964: </listitem>
belaran@967: <listitem><para id="x_73">Quand vous travaillez avec d'autres personnes, les logiciels de
Wilk@1004: gestion de révisions facilitent le travail collaboratif. Par exemple, quand
belaran@964: plusieurs personnes font, plus ou moins simultanément, des modifications
belaran@964: incompatibles, le logiciel vous aidera à identifier et à résoudre les conflits.</para>
belaran@964: </listitem>
belaran@967: <listitem><para id="x_74">L'outil vous aidera à réparer vos erreurs. Si vous effectuez un changement
belaran@964: qui se révèle être une erreur, vous pourrez revenir à une version
belaran@964: antérieure d'un fichier ou même d'un ensemble de fichiers. En fait, un outil de
Wilk@1004: gestion de révisions <emphasis>vraiment</emphasis> efficace vous permettra d'identifier à quel
belaran@964: moment le problème est apparu (voir la section <xref linkend="sec:undo:bisect"/> pour plus
belaran@964: de détails).</para>
belaran@964: </listitem>
belaran@967: <listitem><para id="x_75">L'outil vous permettra aussi de travailler sur plusieurs versions différentes
youshe@982: de votre projet et de gérer l'écart entre chacune.</para>
belaran@964: </listitem></itemizedlist>
youshe@982: <para id="x_76">La plupart de ces raisons ont autant d'importances &emdash;du
Wilk@1004:   moins en théorie&emdash; que vous travailliez seul sur un projet, ou
youshe@982:   avec une centaine d'autres personnes.
belaran@964: </para>
belaran@964: 
youshe@982: <para id="x_77">Une question fondamentale à propos des outils de gestion de
Wilk@1004:   révisions, qu'il s'agisse du projet d'une personne ou d'une grande équipe, est
Wilk@1004:   quels sont ses <emphasis>gains</emphasis> par rapport à ses
andre@1014:   <emphasis>coûts</emphasis>. Un outil qui est difficile à utiliser ou à
youshe@982:   comprendre exigera un lourd effort d'adaptation.
belaran@964: </para>
belaran@964: 
andre@1014: <para id="x_78">Un projet de cinq mille personnes s'effondrera très
youshe@982:   certainement de lui même sans aucun processus et outil de gestion de
Wilk@1004:   révisions. Dans ce cas, le coût d'utilisation d'un logiciel de gestion de
andre@1014:   révisions est dérisoire puisque <emphasis>sans</emphasis> celui-ci, l'échec est presque
youshe@982:   garanti.
belaran@964: </para>
belaran@964: 
youshe@982: <para id="x_79">D'un autre coté, un <quote>rapide hack</quote> d'une personne
youshe@982:   peut sembler un contexte bien pauvre pour utiliser un outil de gestion de
Wilk@1004:   révisions, car, bien évidement le coût d'utilisation dépasse le coût total du
andre@1014:   projet. N'est-ce pas ?
belaran@964: </para>
belaran@964: 
youshe@982:       <para id="x_7a">Mercurial supporte ces <emphasis>deux</emphasis>
youshe@982:         échelles de travail. Vous pouvez apprendre les bases en quelques
youshe@982:         minutes seulement, et, grâce à sa performance, vous pouvez l'utiliser
youshe@982:         avec facilité sur le plus petit des projets. Cette simplicité
Wilk@1004:         signifie que vous n'avez pas de concept obscur ou de séquence de
youshe@982:         commandes défiant l'imagination, sans aucune corrélation avec
andre@1014:         ce que vous êtes <emphasis>réellement</emphasis> en train de faire. En même
andre@1014:         temps, ses mêmes performances et sa nature
youshe@982:         <quote>peer-to-peer</quote> vous permettent d'adapter, sans
youshe@982:         difficulté, son utilisation à de très grands projets.
belaran@964: </para>
belaran@964: 
Wilk@1004:       <para id="x_7b">Aucun outil de gestion de révisions ne peut sauver un
youshe@982:         projet mal mené, mais un bon outil peut rendre beaucoup plus fluide
youshe@982:         votre travail.
belaran@964: </para>
belaran@964: 
belaran@967:     </sect2>
belaran@967: 
belaran@967:     <sect2>
belaran@967:       <title>Les multiples noms de la gestion de source</title>
belaran@967: 
youshe@982:       <para id="x_7c">La gestion de source
youshe@982:         <!-- TODO:<footnote><J'ai utilisé systématiquement le terme
Wilk@1004:             <quote>gestion de révisions</quote> à travers tout l'ouvrage. Ce
youshe@982:             n'est pas forcement la meilleure traduction, et ceci peut rendre
youshe@982:             la lecture un peu lourde, mais je pense que le document y gagne
youshe@982:             en clarté et en précision. -->
youshe@982:         est un domaine tellement large qu'il n'existe pas qu'un seul nom ou
youshe@982:         acronyme pour le désigner. Voici quelques noms ou acronymes que vous
youshe@982:         rencontrerez le plus souvent.
youshe@982:         <!-- TODO:<footnote> J'ai conservé la liste des noms en anglais pour
youshe@982:           des raisons de commodité (ils sont plus <quote>googelable</quote>).
youshe@982:           En outre, j'ai opté  pour conserver l'ensemble des opérations de
youshe@982:           Mercurial (\textit{commit},\textit{push}, \textit{pull},...) en
youshe@982:           anglais, là aussi pour faciliter la lecture d'autres documents en
youshe@982:           anglais, ainsi que l'utilisation de Mercurial. -->
belaran@964: </para>
belaran@964: 
belaran@964: <para>:
belaran@964: </para>
belaran@967: 
belaran@967:       <itemizedlist>
belaran@967: 	<listitem><para id="x_7d">Revision control (RCS)</para></listitem>
youshe@982: 	<listitem><para id="x_7e">Software configuration management (SCM), ou
belaran@967: 	    configuration management</para></listitem>
belaran@967: 	<listitem><para id="x_7f">Source code management</para></listitem>
youshe@982: 	<listitem><para id="x_80">Source code control, ou source control</para></listitem>
youshe@982: 	<listitem><para id="x_81">Version control (VCS)</para></listitem></itemizedlist>
youshe@982: 
youshe@982:  <para id="x_82">Certaines personnes prétendent que ces termes ont en fait
youshe@982:    des sens différents mais en pratique ils se recouvrent tellement qu'il n'y
youshe@982:    a pas réellement de manière pertinente de les distinguer. </para>
belaran@964: 
belaran@967:     </sect2>
belaran@967:   </sect1>
belaran@967: 
belaran@967:   <sect1>
belaran@967: 
Wilk@1004: <title>À propos des exemples dans ce livre</title>
Wilk@1004: 
Wilk@1004:     <para id="x_84">Ce livre prend une approche non usuelle pour les exemples
andre@1014:       de code. Tous les exemples sont en <quote>live</quote> &emdash; chacun
youshe@982:       est actuellement le résultat d'un script shell qui exécute les
andre@1014:       commandes Mercurial que vous voyez. Chaque fois qu'une image du livre
Wilk@1004:       est construite à partir des sources, tous les scripts d'exemples sont
youshe@982:       lancés automatiquement, et leurs résultats effectifs sont comparés aux
youshe@982:       résultats attendus.</para>
youshe@982: 
andre@1014:     <para id="x_85">L'avantage de cette approche est que les exemples sont
youshe@982:       toujours précis ; ils décrivent <emphasis>exactement</emphasis> la
andre@1014:       comportement de la version de Mercurial qui est mentionnée en entête du
andre@1014:       livre. Si je mets à jour la version de Mercurial que je suis en train de
youshe@982:       documenter, et que la sortie de certaines commandes change, la
youshe@982:       construction du livre échoue.</para>
youshe@982: 
youshe@982:     <para id="x_86">
youshe@982:       Il existe un petit désavantage à cette approche qui est que les dates et
youshe@982:       heures que vous verrez dans les exemples tendent à être
youshe@982:       <quote>écrasés</quote> ensemble, dans le sens où elles ne sont pas
youshe@982:       celles qu'elles auraient été si un humain avait tapé les commandes. En
andre@1014:       effet, un humain ne peut pas taper plus d'une commande toutes les quelques
youshe@982:       secondes, avec le temps qui s'écoule, mes scripts d'exemples exécutent
youshe@982:       plusieurs commandes en une seconde.
youshe@982:     </para>
youshe@982: 
andre@1014:     <para id="x_87">Comme exemple de ceci, plusieurs commits
youshe@982:       consécutifs dans un exemple peuvent apparaître comme ayant eu lieu
youshe@982:       durant la même seconde.
youshe@982:       Vous pouvez observer le phénomène dans l'exemple <literal
youshe@982:         role="hg-ext">bisect</literal> dans <xref linkend="sec:undo:bisect"/>
youshe@982:     </para>
youshe@982: 
youshe@982:     <para id="x_88">Donc, lorsque vous lisez ces exemples, ne prêtez pas trop
youshe@982:       d'importance aux dates et heures que vous voyez dans la sortie des
youshe@982:       commandes. Cependant, <emphasis>soyez</emphasis> confiants que le
andre@1014:       comportement que vous voyez est cohérent et reproductible. 
youshe@982:     </para>
belaran@967: 
belaran@967:   </sect1>
belaran@967: 
belaran@967: <!-- The next section has disapper from this part of the book. it may be splaced somewhere else... t-->
belaran@967: 
belaran@967:   <sect1>
Wilk@1004:     <title>Tendances de la gestion de révisions</title>
belaran@967: 
youshe@982:     <para id="x_89">Il y a eu une tendance évidente dans le développement et
youshe@982:       l'utilisation d'outils de gestion de source depuis les quatre dernières
andre@1014:       décennies, au fur et à mesure que les utilisateurs se sont habitués à
youshe@982:       leur outils et se sont sentis contraints par leurs limitations.
youshe@982:     </para>
youshe@982: 
youshe@982:     <para id="x_8a">La première génération commença simplement par gérer un
youshe@982:       fichier unique sur un ordinateur individuel. Cependant, même si ces
youshe@982:       outils présentaient une grande avancée par rapport à la gestion
youshe@982:       manuelle des versions, leur modèle de verrouillage et leur utilisation
youshe@982:       limitée à un seul ordinateur rendaient leur utilisation possible
youshe@982:       uniquement dans une très petite équipe.
youshe@982:     </para>
youshe@982: 
youshe@982:     <para id="x_8b">La seconde génération a assoupli ces contraintes en
youshe@982:       adoptant une architecture réseau et centralisée, permettant de gérer
youshe@982:       plusieurs projets entiers en même temps. Alors que les projets
youshe@982:       grandirent en taille, ils rencontrèrent de nouveaux problèmes. Avec les
Wilk@1004:       clients discutant régulièrement avec le serveur, la montée en charge
youshe@982:       devint un réel problème sur les gros projets. Une connexion réseau peu
youshe@982:       fiable pouvait complètement empêcher les utilisateurs distants de
youshe@982:       dialoguer avec le serveur. Alors que les projets <emphasis
youshe@982:         remap="it">Open Source</emphasis> commencèrent à mettre en place des
youshe@982:       accès en lecture seule disponible anonymement, les utilisateurs sans
youshe@982:       les privilèges de <quote>commit</quote> réalisèrent qu'ils ne pouvaient
youshe@982:       pas utiliser les outils pour collaborer naturellement avec le projet,
youshe@982:       comme ils ne pouvaient pas non plus enregistrer leurs modifications.
youshe@982:     </para>
youshe@982: 
Wilk@1004:     <para id="x_8c">La génération actuelle des outils de gestion de révisions
youshe@982:       est <quote>peer-to-peer</quote> par nature. Tous ces systèmes ont
Wilk@1004:       abandonné la dépendance à un serveur central, et ont permis à leurs
Wilk@1004:       utilisateurs de distribuer les données de leur gestion de révisions à qui
youshe@982:       en a besoin. La collaboration à travers Internet a transformé la
youshe@982:       contrainte technologique en une simple question de choix et de
youshe@982:       consensus. Les outils modernes peuvent maintenant fonctionner en mode
youshe@982:       déconnecté sans limite et de manière autonome, la connexion au réseau
youshe@982:       n'étant nécessaire que pour synchroniser les modifications avec les
youshe@982:       autres dépôts.
youshe@982:     </para>
belaran@967:   </sect1>
youshe@982:     
belaran@967:   <sect1>
Wilk@1004:     <title>Quelques avantages des gestionnaires de révisions distribués</title>
youshe@982:       
Wilk@1004:     <para id="x_8d">Même si les gestionnaire de révisions distribués sont depuis
youshe@982:       plusieurs années assez robustes et aussi utilisables que leurs
youshe@982:       prédécesseurs, les utilisateurs d'autres outils n'y ont pas encore été
Wilk@1004:       sensibilisés. Les gestionnaires de révisions distribués se distinguent
youshe@982:       particulièrement de leurs équivalents centralisés de nombreuses
youshe@982:       manières.
youshe@982:     </para>
youshe@982: 
youshe@982:     <para id="x_8e">Pour un développeur individuel, ils restent beaucoup plus
youshe@982:       rapides que les outils centralisés. Cela pour une raison simple : un
youshe@982:       outil centralisé doit toujours dialoguer à travers le réseau pour la
youshe@982:       plupart des opérations, car presque toutes les métadonnées sont
youshe@982:       stockées sur la seule copie du serveur central. Un outil distribué
youshe@982:       stocke toute ses métadonnées localement. À tâche égale, effectuer un
youshe@982:       échange avec le réseau ajoute un délai aux outils centralisés. Ne
youshe@982:       sous-estimez pas la valeur d'un outil rapide : vous allez passer
Wilk@1004:       beaucoup de temps à interagir avec un logiciel de gestion de révisions.
youshe@982:     </para>
youshe@982: 
youshe@982:     <para id="x_8f">Les outils distribués sont complètement indépendants des
youshe@982:       aléas de votre serveur, d'autant plus qu'ils répliquent les métadonnées
youshe@982:       à beaucoup d'endroits. Si votre serveur central prend feu, vous avez
youshe@982:       intérêt à ce que les médias de sauvegardes soient fiables, et que votre
youshe@982:       dernier <quote>backup</quote> soit récent et fonctionne sans problème.
Wilk@1004:       Avec un outil distribué, vous avez autant de <quote>backups</quote> que
youshe@982:       de contributeurs.
youshe@982:     </para>
youshe@982: 
youshe@982:     <para id="x_90">En outre, la fiabilité de votre réseau affectera beaucoup
youshe@982:       moins les outils distribués. Vous ne pouvez même pas utiliser un outil
youshe@982:       centralisé sans connexion réseau, à l'exception de quelques commandes,
youshe@982:       très limitées. Avec un outil distribué, si votre connexion réseau tombe
youshe@982:       pendant que vous travaillez, vous pouvez ne même pas vous en rendre
youshe@982:       compte. La seule chose que vous ne serez pas capable de faire sera de
youshe@982:       communiquer avec des dépôts distants, opération somme toute assez rare
Wilk@1004:       en comparaison des opérations locales. Si vous avez une équipe de
youshe@982:       collaborateurs très dispersée ceci peut être significatif.
youshe@982:     </para>
belaran@967: 
belaran@967:     <sect2>
belaran@967:       <title>Avantages pour les projets Open Source</title>
belaran@967: 
youshe@982:       <para id="x_91">Si vous prenez goût à un projet <emphasis
youshe@982:           remap="it">Open Source</emphasis> et que vous décidez de commencer
youshe@982:         à toucher à son code, et que le projet utilise un gestionnaire de
Wilk@1004:         révisions distribué, vous êtes immédiatement un "pair" avec les
youshe@982:         personnes formant le <quote>cœur</quote> du projet. S'ils publient
youshe@982:         leurs dépôts, vous pouvez immédiatement copier leurs historiques de
youshe@982:         projet, faire des modifications, enregistrer votre travail en
youshe@982:         utilisant les mêmes outils qu'eux. Par comparaison avec un outil
youshe@982:         centralisé, vous devez utiliser un logiciel en mode <quote>lecture
youshe@982:           seule</quote> à moins que quelqu'un ne vous donne les privilèges de
youshe@982:         <quote>commit</quote> sur le serveur central. Avant ça, vous ne serez
youshe@982:         pas capable d'enregistrer vos modifications, et vos propres
youshe@982:         modifications risqueront de se corrompre chaque fois que vous
youshe@982:         essayerez de mettre à jour à votre espace de travail avec le serveur
youshe@982:         central.
youshe@982:       </para>
youshe@982: 
youshe@982:     <sect3>
youshe@982:       <title>Le non-problème du "fork"</title>
youshe@982:       
youshe@982:       <para id="x_92">Il a été souvent suggéré que les gestionnaires de
Wilk@1004:         révisions distribués posent un risque pour les projets <emphasis
youshe@982:           remap="it">Open Source</emphasis> car ils facilitent grandement la
youshe@982:         création de <quote>fork</quote>.
youshe@982:         <!--footnote{NdT:Création d'une <ulink url="version alternative du
youshe@982:           logiciel">version alternative du
youshe@982:           logiciel</ulink>{http://fr.wikipedia.org/wiki/Fork#Embranchement_d.27un_projet_informatique}
youshe@982:         -->
youshe@982:         Un <quote>fork</quote> apparait quand il y des divergences d'opinion
youshe@982:         ou d'attitude au sein d'un groupe de développeurs qui aboutissent à
youshe@982:         la décision de ne plus travailler ensemble. Chaque parti s'empare
youshe@982:         d'une copie plus ou moins complète du code source du projet et
youshe@982:         continue dans sa propre direction.
youshe@982:       </para>
youshe@982: 
youshe@982: 
youshe@982:       <para id="x_93">Parfois ces différents partis décident de se
youshe@982:         réconcilier. Avec un serveur central, l'aspect
youshe@982:         <emphasis>technique</emphasis> de cette réconciliation est un
youshe@982:         processus douloureux, et essentiellement manuel. Vous devez décider
youshe@982:         quelle modification est <quote>la gagnante</quote>, et replacer, par
youshe@982:         un moyen ou un autre, les modifications de l'autre équipe dans
youshe@982:         l'arborescence du projet. Ceci implique généralement la perte d'une
youshe@982:         partie de l'historique d'un des partis, ou même des deux.
youshe@982:       </para>
youshe@982:     
youshe@982:       <para id="x_94">Ce que les outils distribués permettent à ce sujet est
youshe@982:         probablement la <emphasis>meilleure</emphasis> façon de développer un
youshe@982:         projet. Chaque modification que vous effectuez est potentiellement un
youshe@982:         <quote>fork</quote>. La grande force de cette approche est que les
Wilk@1004:         gestionnaires de révisions distribués doivent être vraiment très
youshe@982:         efficaces pour <emphasis>fusionner (merge)</emphasis>
youshe@982:         <!-- TODO footnote{NdT:j'ai choisi de traduire ici <emphasis
youshe@982:           remap="it">merging</emphasis> par <quote>fusionner</quote> pour des
youshe@982:         raisons de clarté} -->
youshe@982:         des <quote>forks</quote>, car les <quote>forks</quote>, dans ce
youshe@982:         contexte, arrivent tout le temps.
youshe@982:       </para>
youshe@982:       
youshe@982:       <para id="x_95">Si chaque altération que n'importe qui effectue, à tout
youshe@982:         moment, est vue comme un <quote>fork</quote> à fusionner, alors ce
youshe@982:         que le monde de l'<emphasis remap="it">Open Source</emphasis> voit
youshe@982:         comme un <quote>fork</quote> devient <emphasis>uniquement</emphasis>
Wilk@1004:         une problématique sociale. En fait, les outils de gestions de révisions
youshe@982:         distribués <emphasis>réduisent</emphasis> les chances de
youshe@982:         <quote>fork</quote> :
youshe@982:       </para>
youshe@982:         
youshe@982:       <itemizedlist>
youshe@982:         <listitem>
youshe@982:         <para>Ils éliminent la distinction sociale qu'imposent les outils
youshe@982:           centralisés entre les membres du projets (ceux qui ont accès au
Wilk@1004:           <quote>commit</quote>) et ceux de l'extérieur (qui ne l'ont
youshe@982:           pas).
youshe@982:         </para>
youshe@982:         <para>Ils rendent plus facile la réconciliation après un
youshe@982:           <quote>fork</quote> social, car tout ce qu'elle implique est une
youshe@982:           simple fusion.
youshe@982:         </para>
youshe@982:         </listitem>
youshe@982:       </itemizedlist>
youshe@982: 
youshe@982:       <para id="x_98">Certaines personnes font de la résistance envers les
Wilk@1004:         gestionnaires de révisions distribués parce qu'ils veulent garder un
youshe@982:         contrôle ferme sur leur projet, et ils pensent que les outils
youshe@982:         centralisés leur fournissent ce contrôle. Néanmoins, si c'est votre
youshe@982:         cas, sachez que si vous publiez votre dépôt CVS ou Subversion de
youshe@982:         manière publique, il existe une quantité d'outils disponibles pour
youshe@982:         récupérer entièrement votre projet et son historique (quoique
youshe@982:         lentement) et le récréer ailleurs, sans votre contrôle. En fait,
youshe@982:         votre contrôle sur votre projet est illusoire, vous ne faites
youshe@982:         qu'interdire à vos collaborateurs de travailler de manière fluide, en
youshe@982:         disposant d'un miroir ou d'un <quote>fork</quote> de votre
youshe@982:         historique.
youshe@982:       </para>
youshe@982: 
youshe@982:     </sect3>
belaran@967:     </sect2>
belaran@967:     <sect2>
belaran@967:       <title>Avantages pour les projets commerciaux</title>
belaran@967: 
youshe@982:       <para id="x_99">Beaucoup de projets commerciaux sont réalisés par des
youshe@982:         équipes éparpillées à travers le globe. Les contributeurs qui sont
youshe@982:         loin du serveur central devront subir des commandes lentes et même
Wilk@1004:         parfois peu fiables. Les solutions propriétaires de gestion de révisions
youshe@982:         tentent de palier ce problème avec des réplications de sites distants
youshe@982:         qui sont à la fois coûteuses à mettre en place et lourdes à
youshe@982:         administrer. Un système distribué ne souffre pas de ce genre de
youshe@982:         problèmes. En outre, il est très aisé de mettre en place plusieurs
youshe@982:         serveurs de références, disons un par site, de manière à ce qu'il n'y
youshe@982:         ait pas de communication redondante entre les dépôts, sur une
youshe@982:         connexion longue distance souvent onéreuse.
youshe@982:       </para>
youshe@982: 
Wilk@1004:       <para id="x_9a">Les systèmes de gestion de révisions supportent
andre@1014:         généralement assez mal la montée en charge. Il n'est pas rare pour un
Wilk@1004:         gestionnaire de révisions centralisé pourtant onéreux de s'effondrer
andre@1014:         sous la charge combinée de quelques dizaines d'utilisateurs concurrents
youshe@982:         seulement. Une fois encore, la réponse à cette problématique est
youshe@982:         généralement encore la mise en place d'un ensemble complexe de
youshe@982:         serveurs synchronisés par un mécanisme de réplication. Dans le cas
Wilk@1004:         d'un gestionnaire de révisions distribué, la charge du serveur central
Wilk@1004:         &emdash; si vous en avez un&emdash; est largement inférieure (car
youshe@982:         toutes les données sont déjà répliquées ailleurs), un simple serveur,
Wilk@1004:         peu onéreux, peut gérer les besoins d'une plus grande équipe, et la
andre@1014:         réplication pour répartir la charge devient le travail d'un simple
youshe@982:         script.
youshe@982:       </para>
youshe@982: 
youshe@982:       <para id="x_9b">Si vous avez des employés sur le terrain, en train de
youshe@982:         chercher à résoudre un souci sur le site d'un client, ils
Wilk@1004:         bénéficieront aussi d'un gestionnaire de révisions distribué. Cet outil
youshe@982:         leur permettra de générer des versions personnalisées, d'essayer
youshe@982:         différentes solutions, en les isolant aisément les unes des autres,
youshe@982:         et de rechercher efficacement à travers l'historique des sources, la
youshe@982:         cause des bugs ou des régressions, tout ceci sans avoir besoin de la
andre@1014:         moindre connexion au réseau de votre société.
youshe@982:       </para>
belaran@964: 
belaran@967:     </sect2>
youshe@982:     </sect1>
youshe@982:     <sect1>
youshe@982:       <title>Pourquoi choisir Mercurial?</title>
youshe@982: 
youshe@982:       <para id="x_9c">Mercurial a plusieurs caractéristiques qui en font un
Wilk@1004:         choix particulièrement pertinent pour la gestion de révisions :
youshe@982:       </para>
belaran@967:     <itemizedlist>
youshe@982:       <listitem><para id="x_9d">Il est simple à apprendre et à utiliser.</para></listitem>
youshe@982:       <listitem><para id="x_9e">Il est léger.</para></listitem>
youshe@982:       <listitem><para id="x_9f">Il s'adapte très bien à la charge.</para></listitem>
youshe@982:       <listitem><para id="x_a0">Il se personnalise facilement.</para></listitem>
youshe@982:     </itemizedlist>
youshe@982: 
youshe@982:     <para id="x_a1">Si vous êtes déjà familier d'un outil de gestion de
Wilk@1004:       révisions, vous serez capable de l'utiliser en moins de 5 minutes. Sinon,
youshe@982:       ça ne sera pas beaucoup plus long. Les commandes utilisées par
youshe@982:       Mercurial, comme ses fonctionnalités, sont généralement uniformes et
youshe@982:       cohérentes, et vous pouvez ainsi garder en tête simplement quelques
andre@1014:       règles générales, plutôt que de nombreuses exceptions.
youshe@982:     </para>
youshe@982: 
youshe@982:     <para id="x_a2">Sur un petit projet, vous pouvez commencer à travailler
youshe@982:       avec Mercurial en quelques instants. Ajouter des modifications ou des
youshe@982:       branches, transférer ces modifications (localement ou via le réseau),
youshe@982:       et les opérations d'historique ou de statut sont aussi très rapides.
Wilk@1004:       Mercurial ne vous encombre pas grâce à sa simplicité
youshe@982:       d'utilisation et sa rapidité d'exécution.
youshe@982:     </para>
youshe@982: 
youshe@982:     <para id="x_a3">L'utilité de Mercurial ne se limite pas à de petits
andre@1014:       projets : il est aussi utilisé par des projets ayant des centaines ou
youshe@982:       même des milliers de contributeurs, avec plusieurs dizaines de milliers
youshe@982:       de fichiers, et des centaines de méga octets de code source.
youshe@982:     </para>
youshe@982: 
youshe@982:     <para id="x_a4">Si les fonctionnalités au cœur de Mercurial ne sont pas
youshe@982:       suffisantes pour vous, il est très aisé d'en construire d'autres.
youshe@982:       Mercurial est adapté à l'utilisation de scripts, et son implémentation
youshe@982:       interne en Python, propre et claire, rend encore plus facile l'ajout de
youshe@982:       fonctionnalités sous forme d'extensions. Il en existe déjà un certain
youshe@982:       nombre de très populaires et très utiles, dont le périmètre va de la
youshe@982:       recherche de bugs à l'amélioration des performances.
youshe@982:     </para>
belaran@964: 
belaran@967:   </sect1>
belaran@967:   <sect1>
belaran@967:     <title>Mercurial comparé aux autres outils</title>
belaran@967: 
youshe@982:     <para id="x_a5">Avant que vous n'alliez plus loin, comprenez bien que
youshe@982:       cette section reflète mes propres expériences, et elle est donc (j'ose
youshe@982:       le dire) peu objective. Néanmoins, j'ai utilisé les outils de gestion
youshe@982:       de source listés ci dessous, dans la plupart des cas, pendant plusieurs
youshe@982:       années.
youshe@982:     </para>
belaran@967: 
belaran@967:     <sect2>
belaran@967:       <title>Subversion</title>
belaran@967: 
Wilk@1004:       <para id="x_a6">Subversion est un des outils de gestion de révisions les
andre@1014:         plus populaire, développé pour remplacer CVS. Il a une
andre@1014:         architecture client/serveur centralisée.
youshe@982:       </para>
youshe@982: 
youshe@982:       <para id="x_a7">Subversion et Mercurial ont des noms de commandes très
youshe@982:         similaires pour les mêmes opérations, ainsi si vous êtes familier
youshe@982:         avec l'un, c'est facile d'apprendre l'autre. Ces deux outils sont
andre@1014:         portables sur tous les systèmes d'exploitation populaires.
youshe@982:       </para>
youshe@982: 
youshe@982:       <para id="x_a8">Avant la version 1.5, Subversion n'offrait aucune forme
youshe@982:         de support pour les fusions. Lors de l'écriture de ce livre, ses
youshe@982:         capacités de fusion étaient nouvelles, et réputées pour être <ulink
youshe@982:           url="http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword">
youshe@982:           complexes et buguées</ulink>.
youshe@982:       </para>
youshe@982: 
youshe@982:       <para id="x_a9">Mercurial dispose d'un avantage substantiel en terme de
youshe@982:         performance par rapport à Subversion sur la plupart des opérations
youshe@982:         que j'ai pu tester. J'ai mesuré une différence de performance allant
youshe@982:         de deux à six fois plus rapide avec le système de stockage de fichier
youshe@982:         local de Subversion 1.4.3 (<emphasis>ra_local</emphasis>), qui est la
youshe@982:         méthode d'accès la plus rapide disponible. Dans un déploiement plus
youshe@982:         réaliste, impliquant un stockage réseau, Subversion serait encore
youshe@982:         plus désavantagé. Parce que la plupart des commandes Subversion
youshe@982:         doivent communiquer avec le serveur et que Subversion n'a pas de
youshe@982:         mécanisme de réplication, la capacité du serveur et la bande passante
youshe@982:         sont devenues des goulots d'étranglement pour les projets de taille
youshe@982:         moyenne ou grande.
youshe@982:       </para>
youshe@982: 
youshe@982:       <para id="x_aa">En outre, Subversion implique une surcharge
youshe@982:         substantielle dans le stockage local de certaines données, pour
youshe@982:         éviter des transactions avec le serveur, pour certaines opérations
youshe@982:         communes, telles que la recherche des fichiers modifiés
youshe@982:         (<literal>status</literal>) et l'affichage des modifications par
youshe@982:         rapport à la révision courante (<literal>diff</literal>). En
youshe@982:         conséquence, un répertoire de travail Subversion a souvent la même
youshe@982:         taille, ou est plus grand, qu'un dépôt Mercurial et son espace de
youshe@982:         travail, et ceci bien que le dépôt Mercurial contienne l'intégralité
youshe@982:         de l'historique.
youshe@982:       </para>
youshe@982: 
youshe@982:       <para id="x_ab">Subversion est largement supporté par les outils
andre@1014:         tiers. Mercurial est actuellement encore en retrait de ce point de
youshe@982:         vue. L'écart se réduit néanmoins, en effet, certains des outils
youshe@982:         graphiques sont maintenant supérieurs à leurs équivalents Subversion.
youshe@982:         Comme Mercurial, Subversion dispose d'un excellent manuel
youshe@982:         utilisateur.
youshe@982:       </para>
youshe@982: 
youshe@982:       <para id="x_ac">Parce que Subversion ne stocke pas l'historique chez
youshe@982:         ses clients, il est parfaitement adapté à la gestion de projets qui
youshe@982:         doivent suivre un ensemble de larges fichiers binaires et opaques. Si
youshe@982:         vous suivez une cinquantaine de versions d'un fichier incompressible
youshe@982:         de 10MB, l'occupation disque coté client d'un projet sous Subversion
andre@1014:         restera à peu près constante. À l'inverse, l'occupation disque du
Wilk@1004:         même projet sous n'importe lequel des gestionnaires de révisions
youshe@982:         distribués grandira rapidement, proportionnellement aux nombres de
andre@1014:         versions, car les différences entre chaque révision seront très
youshe@982:         grandes.
youshe@982:       </para>
youshe@982: 
youshe@982:       <para id="x_ad">En outre, c'est souvent difficile ou, généralement,
youshe@982:         impossible de fusionner des différences dans un fichier binaire. La
youshe@982:         capacité de Subversion de verrouiller des fichiers, pour permettre à
youshe@982:         l'utilisateur d'être le seul à le mettre à jour
youshe@982:         (<quote>commit</quote>) temporairement, est un avantage significatif
youshe@982:         dans un projet doté de beaucoup de fichiers binaires.
youshe@982:       </para>
youshe@982: 
youshe@982:       <para id="x_ae">Mercurial peut importer l'historique depuis un dépôt
youshe@982:         Subversion. Il peut aussi exporter l'ensemble des révisions d'un
youshe@982:         projet vers un dépôt Subversion. Ceci rend très facile de
youshe@982:         <quote>prendre la température</quote> et d'utiliser Mercurial et
youshe@982:         Subversion en parallèle, avant de décider de migrer vers Mercurial.
youshe@982:         La conversion de l'historique est incrémentale, donc vous pouvez
youshe@982:         effectuer une conversion initiale, puis de petites additions par la
youshe@982:         suite pour ajouter les nouvelle modifications.
youshe@982:       </para>
belaran@964: 
belaran@967: 
belaran@967:     </sect2>
belaran@967:     <sect2>
belaran@967:       <title>Git</title>
belaran@967: 
andre@1014:       <para id="x_af">Git est un outil de gestion de révisions distribué qui a été
youshe@982:         développé pour gérer le code source de noyau de Linux. Comme
youshe@982:         Mercurial, sa conception initiale a été inspirée par Monotone.
youshe@982:       </para>
youshe@982: 
youshe@982:       <para id="x_b0">Git dispose d'un ensemble conséquent de commandes, avec
youshe@982:         plus de 139 commandes individuelles pour la version 1.5.0. Il a aussi
youshe@982:         la réputation d'être difficile à apprendre. Comparé à Git, le point
youshe@982:         fort de Mercurial est clairement sa simplicité.
youshe@982:       </para>
youshe@982: 
youshe@982:       <para id="x_b1">En terme de performance, Git est extrêmement rapide.
youshe@982:         Dans la plupart des cas, il est plus rapide que Mercurial, tout du
youshe@982:         moins sur Linux, alors que Mercurial peut être plus performant sur
youshe@982:         d'autres opérations. Néanmoins, sur Windows, les performances et le
youshe@982:         niveau de support général fourni par Git, au moment de l'écriture de
youshe@982:         cet ouvrage, est bien derrière celui de Mercurial.
youshe@982:       </para>
youshe@982: 
youshe@982:       <para id="x_b2">Alors que le dépôt Mercurial ne demande aucune
youshe@982:         maintenance, un dépôt Git exige d'exécuter manuellement et
youshe@982:         régulièrement la commande <quote>repacks</quote> sur ses métadonnées.
youshe@982:         Sans ceci, les performances de git se dégradent et la consommation de
youshe@982:         l'espace disque augmente rapidement. Un serveur qui contient
youshe@982:         plusieurs dépôts Git qui ne sont pas régulièrement et fréquemment
youshe@982:         <quote>repacked</quote> deviendra un vrai problème lors des
youshe@982:         <quote>backups</quote> du disque, et il y eu des cas, où un
youshe@982:         <quote>backup</quote> journalier pouvait durer plus de 24 heures. Un
youshe@982:         dépôt fraichement <quote>repacked</quote> sera légèrement plus petit
youshe@982:         qu'un dépôt Mercurial, mais un dépôt non <quote>repacked</quote> est
youshe@982:         beaucoup plus grand.
youshe@982:       </para>
youshe@982: 
youshe@982:       <para id="x_b3">Le cœur de Git est écrit en C. La plupart des commandes
youshe@982:         Git sont implémentées sous forme de scripts Shell ou Perl, et la
youshe@982:         qualité de ces scripts varie grandement. J'ai plusieurs fois constaté
youshe@982:         que certains de ces scripts étaient chargés en mémoire aveuglément et
Wilk@1004:         que la présence d'erreurs pouvait s'avérer fatale.
youshe@982:       </para>
youshe@982: 
youshe@982:       <para id="x_b4">Mercurial peut importer l'historique d'un dépôt Git.</para>
belaran@967: 
belaran@967:     </sect2>
belaran@967:     <sect2>
belaran@967:       <title>CVS</title>
belaran@967: 
Wilk@1004:       <para id="x_b5">CVS est probablement l'outil de gestion de révisions le
youshe@982:         plus utilisé aujourd'hui dans le monde. À cause de son manque de
youshe@982:         clarté interne, il n'est plus maintenu depuis plusieurs années.
youshe@982:       </para>
youshe@982: 
youshe@982:       <para id="x_b6">Il a une architecture client/serveur centralisée. Il ne
youshe@982:         regroupe pas les modifications de fichiers dans une opération de
youshe@982:         <quote>commit</quote> atomique, ce qui permet à ses utilisateurs de
Wilk@1004:         <quote>casser le <emphasis>build</emphasis></quote> assez facilement :
Wilk@1004:         une personne peut effectuer une opération de <quote>commit</quote>
youshe@982:         sans problème puis être bloquée par besoin de fusion, avec comme
youshe@982:         conséquence néfaste, que les autres utilisateurs ne récupèreront
youshe@982:         qu'une partie de ses modifications. Ce problème affecte aussi la
youshe@982:         manière de travailler avec l'historique du projet. Si vous voulez
youshe@982:         voir toutes les modifications d'une personne du projet, vous devrez
youshe@982:         injecter manuellement les descriptions et les <emphasis
youshe@982:           remap="it">timestamps</emphasis> des modifications de chacun des
youshe@982:         fichiers impliqués (si vous savez au moins quels sont ces fichiers).
youshe@982:       </para>
belaran@964: 
belaran@967:       <para id="x_b7">CVS a une notion étrange des <emphasis
youshe@982:           remap="it">tags</emphasis> et des branches que je n'essayerai même
youshe@982:         pas de décrire ici. Il ne supporte pas bien les opérations de
youshe@982:         renommage d'un fichier ou d'un répertoire, ce qui facilite la
youshe@982:         corruption de son dépôt. Il n'a presque pas pour ainsi dire de
youshe@982:         contrôle de cohérence interne, il est donc pratiquement impossible de
youshe@982:         dire si un dépôt est corrompu ni à quel point. Je ne recommanderai
youshe@982:         pas CVS pour un projet existant ou nouveau.
youshe@982:       </para>
youshe@982: 
youshe@982:       <para id="x_b8">Mercurial peut importer l'historique d'un projet CVS.
andre@1014:         Néanmoins, il y a quelques principes à respecter ; ce qui est vrai
youshe@982:         aussi pour les autres outils d'import de projet CVS. À cause de
Wilk@1004:         l'absence de <quote>commit</quote> atomique et gestion de versions de
youshe@982:         l'arborescence, il n'est pas possible de reconstruire de manière
youshe@982:         précise l'ensemble de l'historique. Un travail de
youshe@982:         <quote>devinette</quote> est donc nécessaire, et les fichiers
youshe@982:         renommés ne sont pas détectés. Parce qu'une bonne part de
youshe@982:         l'administration d'un dépôt CVS est effectuée manuellement, et est
youshe@982:         donc, sujette à erreur, il est courant que les imports CVS
youshe@982:         rencontrent de nombreux problèmes avec les dépôt corrompus (des
youshe@982:         <emphasis remap="it">timestamps</emphasis> de révision complètement
youshe@982:         buggés et des fichiers verrouillés depuis des années sont deux des
youshe@982:         problèmes les moins intéressants dont je me souvienne).
youshe@982:       </para>
belaran@967: 
belaran@967:       <para id="x_b9">Mercurial peut importer l'historique depuis un dépôt CVS.
youshe@982:       </para>
belaran@967: 
belaran@967: 
belaran@967:     </sect2>
belaran@967:     <sect2>
belaran@967:       <title>Outils propriétaires</title>
belaran@967: 
youshe@982:       <para id="x_ba">Perforce a une architecture client/serveur centralisée,
andre@1014:         sans aucun mécanisme de mise en cache de données côté client.
Wilk@1004:         Contrairement à la plupart des outils modernes de gestion de révisions,
youshe@982:         Perforce exige de ses utilisateurs d'exécuter une commande pour
youshe@982:         informer le serveur central de tout fichier qu'ils souhaitent
youshe@982:         modifier.
youshe@982:       </para>
youshe@982: 
youshe@982:       <para id="x_bb">Les performances de Perforce sont plutôt bonnes pour
youshe@982:         des petites équipes, mais elles s'effondrent rapidement lorsque le
andre@1014:         nombre d'utilisateurs augmente au delà de quelques dizaines. Des
youshe@982:         installations de Perforce assez larges nécessitent le déploiement de
youshe@982:         proxies pour supporter la montée en charge associée.
youshe@982:       </para>
belaran@967: 
belaran@967:     </sect2>
belaran@967:     <sect2>
Wilk@1004:       <title>Choisir un outil de gestion de révisions</title>
belaran@967: 
andre@1014:       <para id="x_bc">À l'exception de CVS, tous les outils listés ci-dessus
Wilk@1004:         ont des forces qui leurs sont propres et qui correspondent à certaines
youshe@982:         formes de projet. Il n'y a pas un seul meilleur outil de gestion de
Wilk@1004:         révisions qui correspondrait le mieux à toutes les situations.
youshe@982:       </para>
youshe@982: 
youshe@982:       <para id="x_bd">En guise exemple, Subversion est un très bon choix
youshe@982:         lorsqu'on travaille avec beaucoup de fichiers binaires, qui évoluent
youshe@982:         régulièrement, grâce à sa nature centralisée et sa capacité à
youshe@982:         verrouiller des fichiers.
youshe@982:       </para>
youshe@982: 
youshe@982:       <para id="x_be">Personnellement, je préfère Mercurial pour sa
youshe@982:         simplicité, ses performances et sa bonne capacité de fusion, et il
youshe@982:         m'a très bien rendu service de plusieurs années maintenant.
youshe@982:       </para>
belaran@967: 
belaran@967:     </sect2>
belaran@967:   </sect1>
belaran@967:   <sect1>
andre@1014:     <title>Migrer depuis un outil vers Mercurial</title>
belaran@967: 
youshe@982:     <para id="x_bf">Mercurial est livré avec une extension nommée <literal
youshe@982:         role="hg-ext">convert</literal>, qui peut, de manière incrémentale
youshe@982:       importer des révisions depuis différents autres outils de gestion de
youshe@982:       source. Par <quote>incrémental</quote>, j'entends que vous pouvez
youshe@982:       convertir l'historique entier du projet en une seule fois, puis
youshe@982:       relancer l'outil d'import plus tard pour obtenir les modifications
youshe@982:       effectuées depuis votre import initial.
youshe@982:     </para>
youshe@982: 
Wilk@1004:     <para id="x_c0">Les outils de gestion de révisions supportés par <literal
youshe@982:         role="hg-ext">convert</literal> sont :
youshe@982:     </para>
belaran@967:     <itemizedlist>
belaran@967:       <listitem><para id="x_c1">Subversion</para></listitem>
belaran@967:       <listitem><para id="x_c2">CVS</para></listitem>
belaran@967:       <listitem><para id="x_c3">Git</para></listitem>
youshe@982:       <listitem><para id="x_c4">Darcs</para></listitem>
youshe@982:     </itemizedlist>
youshe@982: 
youshe@982:     <para id="x_c5">En outre, <literal role="hg-ext">convert</literal> peut
youshe@982:       exporter les modifications depuis Mercurial vers Subversion. Ceci rend
youshe@982:       possible d'essayer Subversion en parallèle avant de choisir une
youshe@982:       solution définitive, sans aucun risque de perte de données.
youshe@982:     </para>
youshe@982: 
youshe@982:     <para id="x_c6">La commande <command
youshe@982:         role="hg-ext-conver">convert</command> est très simple à utiliser.
youshe@982:       Simplement, indiquez le chemin ou l'URL du dépôt de source, en lui
youshe@982:       indiquant éventuellement le nom du chemin de destination, et la
youshe@982:       conversion se met en route. Après cet import initial, il suffit de
youshe@982:       relancer la commande encore une fois pour importer les modifications
youshe@982:       effectuées depuis.
youshe@982:     </para>
belaran@967:   </sect1>
belaran@967: 
belaran@967:   <sect1>
Wilk@1004:     <title>Une courte histoire de la gestion de révisions</title>
Wilk@1004: 
Wilk@1004:     <para id="x_c7">Le plus célèbre des anciens outils de gestion de révisions
youshe@982:       est <emphasis remap="it">SCCS</emphasis> (Source Code Control System)},
youshe@982:       que Marc Rochkind conçu dans les laboratoires de recherche de Bell
youshe@982:       (<emphasis remap="it">Bell Labs</emphasis>), dans le début des années
youshe@982:       70. <emphasis remap="it">SCCS</emphasis> ne fonctionnait que sur des
youshe@982:       fichiers individuels, et obligeait chaque personne travaillant sur le
youshe@982:       projet d'avoir un accès à un répertoire de travail commun, sur le même
youshe@982:       système. Seulement une seule personne pouvait modifier un fichier au
youshe@982:       même moment, ce fonctionnement était assuré par l'utilisation de verrou
youshe@982:       (<quote>lock</quote>). Il était courant que des personnes verrouillent
youshe@982:       des fichiers, et plus tard, oublient de le déverrouiller ; empêchant
youshe@982:       n'importe qui d'autre de travailler sur ces fichiers sans l'aide de
youshe@982:       l'administrateur...
youshe@982:     </para>
belaran@967: 
belaran@967:     <para id="x_c8">Walter Tichy a développé une alternative libre à
youshe@982:       <emphasis remap="it">SCCS</emphasis> au début des années 80, qu'il
youshe@982:       nomma <emphasis remap="it">RCS (Revision Control System)</emphasis>.
youshe@982:       Comme <emphasis remap="it">SCCS</emphasis>, <emphasis
youshe@982:         remap="it">RCS</emphasis> demandait aux développeurs de travailler
youshe@982:       sur le même répertoire partagé, et de verrouiller les fichiers pour se
youshe@982:       prémunir de tout conflit issu de modifications concurrentes.
youshe@982:     </para>
youshe@982: 
youshe@982:     <para id="x_c9">Un peu plus tard dans les années 1980, Dick Grune utilisa
youshe@982:       <emphasis remap="it">RCS</emphasis> comme une brique de base pour un
youshe@982:       ensemble de scripts <emphasis remap="it">shell</emphasis> qu'il
youshe@982:       intitula cmt, avant de la renommer en <emphasis remap="it">CVS
youshe@982:         (Concurrent Versions System)</emphasis>.  La grande innovation de CVS
youshe@982:       était que les développeurs pouvaient travailler simultanément et
youshe@982:       indépendamment dans leur propre espace de travail. Ces espaces de
youshe@982:       travail privés assuraient que les développeurs ne se marchent pas
youshe@982:       mutuellement sur les pieds, comme c'était souvent le cas avec RCS et
youshe@982:       SCCS. Tous les développeurs disposaient donc de leur copie de tous les
youshe@982:       fichiers du projet, et ils pouvaient donc librement les modifier. Ils
youshe@982:       devaient néanmoins effectuer la <quote>fusion</quote> (<emphasis
youshe@982:         remap="it"><quote>merge</quote></emphasis>) de leurs fichiers, avant
youshe@982:       d'effectuer le <quote>commit</quote> de leurs modifications sur le dépôt
youshe@982:       central.
youshe@982:     </para>
youshe@982:     
andre@1014:     <para id="x_ca">Brian Berliner reprit les scripts de Grune's et les réécrit en C,
youshe@982:       qu'il publia en 1989. Depuis, ce code a été modifié jusqu'à devenir la
youshe@982:       version moderne de CVS. CVS a acquis ainsi la capacité de fonctionner
youshe@982:       en réseau, transformant son architecture en client/serveur.
youshe@982:       L'architecture de CVS est centralisée, seul le serveur a une copie de
youshe@982:       l'historique du projet. L'espace de travail client ne contient qu'une
youshe@982:       copie de la dernière version du projet, et quelques métadonnées pour
youshe@982:       indiquer où le serveur se trouve. CVS a été un grand succès,
Wilk@1004:       aujourd'hui il est probablement l'outil de gestion de révisions le plus
youshe@982:       utilisé au monde.
youshe@982:     </para>
youshe@982:     
andre@1014:     <para id="x_cb">Au début des années 1990, Sun Microsystems développa un premier
Wilk@1004:       outil de gestion de révisions distribué, nommé TeamWare. Un espace de
youshe@982:       travail TeamWare contient une copie complète de l'historique du projet.
youshe@982:       TeamWare n'a pas de notion de dépôt central. (CVS utilisait RCS pour le
youshe@982:       stockage de l'historique, TeamWare utilisait SCCS).
youshe@982:     </para>
youshe@982:     
andre@1014:     <para id="x_cc">Alors que les années 1990 avançaient, les utilisateurs ont pris
youshe@982:       conscience d'un certain nombre de problèmes avec CVS. Il enregistrait
youshe@982:       simultanément des modifications sur différents fichiers
youshe@982:       individuellement, au lieu de les regrouper dans une seule opération
andre@1014:       cohérente et atomique. Il ne gère pas bien sa hiérarchie de fichiers, il
youshe@982:       est donc assez aisé de créer le chaos en renommant les fichiers et les
youshe@982:       répertoires. Pire encore, son code source est difficile à lire et à
andre@1014:       maintenir, ce qui augmente largement le <quote>niveau de
youshe@982:         souffrance</quote> associé à la réparation de ces problèmes
youshe@982:       d'architecture de manière prohibitive.
youshe@982:     </para>
youshe@982:     
andre@1014:     <para id="x_cd">En 2001, Jim Blandy et Karl Fogel, deux développeurs qui avaient
youshe@982:       travaillé sur CVS, initièrent un projet pour le remplacer par un outil
youshe@982:       qui aurait une meilleure architecture et un code plus propre. Le
youshe@982:       résultat, Subversion, ne quitte pas le modèle centralisé et
andre@1014:       client/serveur de CVS, mais ajoute les opérations de
youshe@982:       <quote>commit</quote> atomique sur de multiples fichiers, une meilleure
youshe@982:       gestion des espaces de noms, et d'autres fonctionnalités qui en font un
youshe@982:       meilleur outil que CVS. Depuis sa première publication, il est
youshe@982:       rapidement devenu très populaire.
youshe@982:     </para>
youshe@982:     
andre@1014:     <para id="x_ce">Plus ou moins simultanément, Graydon Hoare a commencé sur
Wilk@1004:       l'ambitieux système de gestion distribuée Monotone. Bien que Monotone
youshe@982:       corrige plusieurs défauts de CVS tout en offrant une architecture
youshe@982:       <quote>peer-to-peer</quote>, il va aussi plus loin que la plupart des
Wilk@1004:       outils de gestion de révisions de manière assez innovante. Il utilise des
youshe@982:       <quote>hashs</quote> cryptographiques comme identifiants, et il a une
youshe@982:       notion complète de <quote>confiance</quote> du code issu des
youshe@982:       différentes sources.
youshe@982:     </para>
youshe@982:     
andre@1014:     <para id="x_cf">Mercurial est né en 2005. Bien que très influencé par Monotone,
youshe@982:       Mercurial se concentre sur la facilité d'utilisation, les performances
Wilk@1004:       et la capacité à monter en charge sur de très gros projets.
youshe@982:     </para>
youshe@982:   
youshe@982:   </sect1>
belaran@967: 
belaran@964: </chapter>
belaran@964: 
belaran@964: <!--
belaran@964: local variables: 
belaran@964: sgml-parent-document: ("00book.xml" "book" "chapter")
belaran@964: end:
belaran@967: -->