bos@16: \chapter{Introduction}
bos@16: \label{chap:intro}
bos@16: 
romain@923: \section{A propros de la gestion source}
romain@923: 
romain@923: La gestion de source est un processus permettant de gérer différentes
romain@923: version de la même information. Dans sa forme la plus simple, c'est
romain@923: quelquechose que tout le monde fait manuellement : quand vous modifiez
romain@923: un fichier, vous le sauvegarder sous un nouveau nom contenant un numéro,
romain@923: à chaque fois plus grand la précédente version.
romain@923: 
romain@923: Ce genre de gestion de version manuel est cependant sujette facilement
romain@923: à des erreurs, ainsi, depuis longtemps, des logiciels existent pour
romain@923: adresser cette problématique. Les premiers outils de gestion de source
romain@923: étaient destinés à aider un seul utilisateur, à automatiser la gestion
romain@923: des versions d'un seulf fichier. Dans les dernières décades, cette cilble 
romain@923: a largement était agrandie, ils gèrent désormais de multiple fichiers, et
romain@923: aident un grand nombre de personnes à travailler ensemble. Le outils les
romain@923: plus modernes n'ont aucune difficultés à gérer plusieurs milliers de 
romain@923: personnes travaillant ensemble sur des projets regroupant plusieurs 
romain@923: centaines de milliers de fichiers.
romain@923: 
romain@923: \subsection{Pourquoi utiliser un gestionnaire de source ?}
romain@923: 
romain@923: Il y a de nombreuse raisons pour que vous ou votre équipe souhaitiez
romain@923: utiliser un outil automatisant la gestion de version pour votre projet.
bos@217: \begin{itemize}
romain@923: \item L'outil se chargera de suivre l'évolution de votre projet, sans
romain@923: que vous ayez à le faire. Pour chaque modification, vous aurez à votre
romain@923: disposition un journal indiquant \emph{qui} a faient quoi, \emph{pourquoi}
romain@923: ils l'ont fait, \emph{quand} ils l'ont fait, et \emph{ce} qu'ils ont
romain@923: modifiés.
romain@923: \item Quand vous travaillez avec d'autres personnes, les logiciels de 
romain@923: gestion de source facilite le travail collaboratif. Par exemple, quand
romain@923: plusieurs personnes font, plus ou moins simultannéement, des modifications
romain@923: incompatibles, le logiciel vous aidera à identifier et résoudre les conflits.
romain@924: \item L'outil vous aidera à réparer vos erreurs. Si vous effectuez un changement
romain@924: qui se révèlera être une erreur, vous pourrez revenir fiablement à une version
romain@924: antérieur d'une fichier ou même d'un ensemble de fichier. En fait, un outil de
romain@924: gestion de source \emph{vraiment} efficace vous permettra d'identifier à quel
romain@924: moment le problème est apparu (voir la section~\ref{sec:undo:bisect} pour plus
romain@924: de détails).
romain@924: \item L'outil vous permettra aussi de travailler sur plusieurs versions différentes
romain@924: de votre projet et à gérer l'écart entre chaque.
bos@217: \end{itemize}
romain@924: La plupart de ces raisons ont autant d'importances---du moins en théorie--- que
romain@924: vous travailliez sur un projet pour vous, ou avec une centaine d'autres
romain@924: personnes.
romain@924: 
romain@924: Une question fondamental à propos des outils de gestion de source, qu'il s'agisse
romain@924: du projet d'une personne ou d'une grande équipe, est quelles sont ses  
romain@924: \emph{avantages} par rapport à ses \emph{coût}. Un outil qui est difficile à 
romain@924: utiliser ou à comprendre exigera un effort d'adoption.
romain@924: 
romain@924: Un projet de cinq milles personnnes s'effondrera très certainement de lui même
romain@924: sans aucun processus et outil de gestion de source. Dans ce cas, le coût 
romain@924: d'utilisation d'un logiciel de gestion de source est dérisoire, puisque 
romain@924: \emph{sans}, l'échec est presque garanti.
romain@924: 
romain@924: D'un autre coté, un ``rapide hack'' d'une personnne peut sembler un contexte
romain@924: bien pauvre pour utiliser un outil de gestion de source, car, bien évidement
romain@924: le coût d'utilisation dépasse le coût total du projet. N'est ce pas ?
romain@924: 
romain@924: Mercurial supporte ces \emph{deux} échelles de travail. Vous pouvez apprendre
romain@924: les bases en juste quelques minutes, et, grâce à sa performance, vous pouvez
romain@924: l'utiliser avec facilité sur le plus petit des projets. Cette simplicité 
romain@924: signifie que vous n'avez pas de concepts obscures ou de séquence de commandes
romain@924: défiant l'imagination, complètement décorrelé de \emph{ce que vous êtes 
romain@924: vraiment entrain de faire}. En même temps, ces mêmes performances et sa 
romain@924: nature ``peer-to-peer'' vous permet d'augmenter, sans difficulté, son 
romain@924: utilisation à de très grand projet.
romain@924: 
romain@924: Aucun outil de gestion de source ne peut sauver un projet mal mené, mais un
romain@924: bon outil peut faire une grande différence dans la fluidité avec lequel 
romain@924: vous pourrez travailler avec.
romain@924: 
romain@924: \subsection{Les multiples noms de la gestion de source}
romain@924: 
romain@928: La gestion de source\footnote{NdT: J'ai utilisé systématiquement le terme ``gestion de source'' à travers tout l'ouvrage. Ce n'est pas forcement la meilleur traduction, et ceci peut rendre la lecture un peu lourde, mais je pense que le document y gagne en clarté et en précision.} est un domaine divers, tellement qu'il n'existe pas
romain@924: une seul nom ou acronyme pour le désigner. Voilà quelqu'uns des noms ou 
romain@928: acronymes que vous rencontrerez le plus souvent\footnote{NdT: J'ai conservé la liste des noms en anglais pour des raisons de commodité (ils sont plus ``googelable''). En outre, j'ai opté  conserver l'ensemble des opérations de Mercurial (\textit{commit},\textit{push}, \textit{pull},...) en anglais, là aussi pour faciliter la lecture d'autres documents en anglais, et aussi l'utilisation de Mercurial}.
romain@928: 
romain@928: :
bos@217: \begin{itemize}
romain@924: \item \textit{Revision control (RCS)} ;
romain@924: \item Software configuration management (SCM), ou \textit{configuration management} ;
romain@924: \item \textit{Source code management} ;
romain@924: \item \textit{Source code control}, ou \textit{source control} ;
romain@924: \item \textit{Version control (VCS)}.
bos@217: \end{itemize}
romain@924: 
romain@924: Certains personnes prétendent que ces termes ont en fait des sens
romain@924: différents mais en pratique ils se recouvrent tellement qu'il n'y a pas
romain@924: réellement de manière pertinente de les distinguer.
romain@924: 
romain@924: \section{Une courte histoire de la gestion de source}
romain@924: 
romain@924: Le plus célèbre des anciens outils de gestion de source est \textit{SCCS (Source
romain@924: Code Control System)}, que Marc Rochkind conçu dans les laboratoire de recherche de Bell 
romain@924: (\textit{Bell Labs}), dans le début des années 70. \textit{SCCS} ne fonctionner que sur des fichiers individuels, et demandait à personne travaillant sur le projet d'avoir un accès à un répertoire de travail commun, sur un unique système.
romain@924: Seulement une personne pouvait modifier un fichier au même moment, ce fonctionnement était assuré par l'utilisation de verrou (``lock''). Il était courant que des personnes ne vérouille
romain@924: des fichiers, et plus tard, oublie de le dévérouiller; empêchant  n'importe qui d'autre de 
romain@924: travailler sur ces fichiers sans l'aide de l'administrateur...
romain@924: 
romain@924: Walter Tichy a développé une alternative libre à \textit{SCCS} au début des années 80, qu'il
romain@924: nomma \textit{RSC (Revison Control System)}.  Comme \textit{SCCS}, \textit{RCS}
romain@924: demander aux développeurs de travailler sur le même répertoire partagé, et de vérouiller les
romain@924: fichiers pour se prémunir de tout conflit issue de modifications concurrentes.
romain@924: 
romain@924: Un peu plus tard dans les années 1980, Dick Grune utilisa \textit{RCS} comme une brique de base pour un ensemble de scripts \textit{shell} qu'il intitula cmt, avant de la renommer en \textit{CVS (Concurrent Versions System)}.  La grande innovation de CVS était que les développeurs pouvaient travailler simultanéement and indépendament dans leur propre espace de travail. Ces espaces de travail privés assuraient que les développeurs ne se marche mutuellement sur les pieds, comme c'était souvent le cas avec RCS et SCCS. Chaque développeur disposait donc de sa copie de tout les fichiers du projet, et ils pouvaient donc librement les modifier. Ils devaient néanmoins effectuer la ``fusion'' (\textit{``merge''}) de leur fichiers, avant d'effectuer le ``commit'' de leur modification sur le dépôt central.
bos@218: 
romain@926: Brian Berliner repris les scripts de Grune's et les réécris en~C, qu'il publia en 1989. Depuis, ce code a été modifié jusqu'à devenir la version moderne de CVS. CVS a acquis ainsi la capacité de fonctionner en réseau, le transformant son architecture en client/serveur. L'architecture de CVS est centralisée, seul le serveur a une copie de l'historique du projet. L'espace de travail client ne contient qu'une copie de la dernière version du projet, et quelques métadonnées pour indiquer où le serveur se trouve. CVS a été un grand succès, aujourd'hui c'est probablement l'outil de gestion de contrôle le plus utilisé au monde. 
romain@926: 
romain@926: Au début des années 1990, Sun Microsystmes développa un premier outil de gestion de source distribué, nommé TeamWare. Un espace de travail TeamWare contient une copie complète de l'historique du projet. TeamWare n'a pas de notion de dépot central. (CVS utilisé RCS pour le stockage de l'historique, TeamWare utilisé SCCS).
romain@926: 
romain@926: Alors que les années 1990 avancé, les utilisateurs ont pris conscience d'un certain nombre de problème avec CVS. Il enregistrait simultanéement des modifications sur différents fichier individuellement, au lieu de les regrouper dans une seule opération cohérente et atomique. Il ne gère pas bien sa hiérarchie de fichier, il est donc assez aisé de créer le chaos en renommant les fichiers et les répertoires. Pire encore, son code source est difficile à lire et à maintenir, ce qui agrandit largement le ``niveau de souffrance'' associé à la réparation de ces problèmes d'architecture de manière prohibitive. 
romain@926: 
romain@926: 
romain@926: En 2001, Jim Blandy et Karl Fogel, deux développeurs qui avaient travaillé sur CVS, initialisèrent un projet pour le remplacer par un outil qui aurait une meilleur architecture et un code plus propre. Le résultat, Subversion, ne quitte pas le modèle centralisé et client/server de CVS, mais ajoute les opérations de ``commit'' atomique sur de multiples fichier, une meilleur gestion des espaces de noms, et d'autres fonctionnalités qui en font un meilleur outil que CVS. Depuis sa première publication, il est rapidement devenu très populaire.
romain@926: 
romain@926: Plus ou moins de manière simultanné, Graydon Hoare a commencé sur l'ambitieux système de gestion distribué Monotone. Bien que Monotone corrige plusieurs défaut de CVS's tout en offrant une architecture ``peer-to-peer'', il va aussi plus loin que la plupart des outils de révision de manière assez innovante. Il utilise des ``hash'' cryptographique comme identifiant, et il a notion complète de ``confiance'' du code issues de différentes sources.
romain@926: 
romain@926: Mercurial est né en 2005. Bien que très influencé par Monotone, Mercurial se concentre sur la facilité d'utilisation, les performances et la capacité à monter en charge pour de très grand projets.
romain@926: 
romain@926: \section{Tendances de la gestion de source}
romain@926: 
romain@926: Il y a eu une tendance évidente dans le développement et l'utilisation d'outil de gestion de source depuis les quatre dernière décades, au fur et à mesure que les utilisateurs se sont habitués à leur outils et se sont sentis contraint par leur limitations.
romain@926: 
romain@926: La première génération commença simplement par gérer un fichier unique sur un ordinateur individuel. Cependant, même si ces outils présentè-rent une grande avancée par rapport à la gestion manuel des versions, leur modèle de vérouillage et leur utilisation limité à un seul ordinateur rendaient leur utilisation possible uniquement dans une très petite équipe. 
romain@926: 
romain@926: La seconde génération a assoupli ces contraintes en adoptant une architecture réseau et centralisé, permettant de gérer plusieurs projets entiers en même temps. Alors que les projets grandirent en taille, ils rencontrèrent de nouveau problèmes. Avec les clients discutant régulièrement avec le serveurs, la monte en charge devint un réellement problème sur les gros projets. Une connexion réseau peu fiable pouvant empêcher simplement les utilisateurs distant de discuter avec le serveur. Alors que les projets \textit{Open Source} commencèrent à mettre en place des accès en lecture seule disponible anonymement, les utilisateurs sans les privilèges de ``commit'' réalisèrent qu'ils ne pouvaient pas utiliser les outils pour collaboraient naturellement avec le projet, comme ils ne pouvaient pas non plus enregistrer leurs modifications.
romain@926: 
romain@926: La génération actuelle des outils de gestion de source est ``peer-to-peer'' par nature. Tout ces systèmes ont abandonné la dépendance à un serveur central, et ont permis à leur utilisateur de distribué les données de leur gestion de source à qui en a besoin. La collaboration à travers Internet a transformée la contrainte technologique à une simple question de choix et de consencus. Les outils moderne peuvent maintenant fonctionner en mode déconnecté sans limite et de manière autonome, la connexion au réseau n'étant nécessaire que pour synchroniser les modifications avec les autres dépots.
romain@926: 
romain@926: \section{Quelques avantages des gestionnaire de source distribué}
romain@926: 
romain@926: Même si les gestionnaire de source distribué sont depuis plusieurs années
romain@926: assez robuste et aussi utilisable que leur prédécésseurs, les utilisateurs
romain@926: d'autres outils n'ont pas encore étaient sensibilisé. Les gestionnaires
romain@926: de sources distribué se distingue particulièrement de leurs équivalents
romain@926: centralisé de nombreuse manière.
romain@926: 
romain@926: Pour un développeur individuel, ils restent beaucoup plus rapide que les
romain@926: outils centralisés. Cela pour une raison simple: un outil centralisé doit
romain@926: toujours discuter à travers le réseau pour la plupart des opérations, car
romain@926: presque toutes les métadonnées sont stockées sur la seule copie du serveur
romain@926: central. Un outil distribué stocke toute ses métadonnées localement. À tâche
romain@926: égale, effectuer un échange avec le réseau ajoute un délai aux outils 
romain@926: centralisés. Ne sous estimez pas la valeur d'un outil rapide: vous allez
romain@926: passer beaucoup de temps à interagir avec un logiciel de gestion de sources.
romain@926: 
romain@926: Les outils distribué sont complètement indépendant des aléas de votre serveur,
romain@926: encore une fois car ils répliquent les métadonnées à tellement d'endoit. Si
romain@926: votre serveur central prend feu, vous avez intérêt à ce que les média de 
romain@926: sauvegarde soient fiable, et que votre dernier ``backup'' soit récent et
romain@926: fonctionne sans problème. Avec un outil distribué, vous avez autant de 
romain@926: ``backup'' que de contributeurs.
romain@926: 
romain@926: En outre, la fiabilité de votre réseau affectera beaucoup moins les
romain@926: outils distribué. Vous ne pouvez même pas utiliser un outil centralisé
romain@926: sans connexion réseau, à l'exception de quelques commandes, très limités. 
romain@926: Avec un outil distribué, si vous connexion réseau tombe pendant que vous
romain@926: travaillez, vous pouvez ne même pas vous en rendre compte. La seule chose
romain@926: que vous ne serez pas capable de faire sera de communiquer avec des dépôts
romain@926: distants, opération somme toute assez rare par comparaison aux opérations
romain@926: locales. Si vous avez une (TODO:far-flung???) équipe de collaborateurs, 
romain@926: ceci peut être significatif.
romain@926: 
romain@926: \subsection{Avantages pour les projets \textit{Open Source}}
romain@926: 
romain@926: Si vous prenez goût à un projet \textit{Open Source} et que vous
romain@926: décidez de commencer à toucher à son code, et que le projet utilise
romain@926: un gestionnaire de source distribué, vous êtes immédiatement un "pair"
romain@926: avec les personnes formant le ``coeur'' du projet. Si ils publient
romain@926: leurs dépôts, vous pouvez immédiatement copier leurs historiques de
romain@926: projet, faire des modifications, enregistrer votre travail en utilisant
romain@926: les même outils qu'eux. Par comparaison, avec un outil centralisé, vous
romain@926: devez utiliser un logiciel en mode ``lecture seule'' à moins que 
romain@926: quelqu'un ne vous donne les privilèges de ``commit'' sur le serveur
romain@926: central. Avant ça, vous ne serez pas capable d'enregistrer vos 
romain@926: modifications, et vos propres modifications risqueront de se 
romain@926: corrompre chaque fois que vous essayerez de mettre à jour à votre
romain@926: espace de travail avec le serveur central.
romain@926: 
romain@926: \subsubsection{Le non-problème du \textit{fork}}
romain@926: 
romain@926: Il a été souvent suggeré que les gestionnaires de source distribués
romain@926: posent un risque pour les projets \textit{Open Source} car ils 
romain@926: facilitent grandement la création de ``fork''\footnote{NdT:Création 
romain@926: d'une version alternative du logiciel}. %%% TODO: Link to Wikipedia
romain@926: Un ``fork'' apparait quand il y des divergences d'opinion ou d'attitude
romain@926: au sein d'un groupe de développeurs qui aboutit à la décision de ne 
romain@926: plus travail ensemble. Chacun parti s'empare d'une copie plus ou moins
romain@926: complète du code source du projet et continue dans sa propre direction.
romain@926: 
romain@926: Parfois ces différents partis décide de se réconcilier. Avec un 
romain@926: serveur central, l'aspect \emph{technique} de cette réconciliation
romain@926: est un processus douloureux, et essentiellement manuel. Vous devez
romain@926: décider quelle modification est ``la gagnante'', et replacer, par un
romain@926: moyen ou un autre, les modifications de l'autre équipe dans l'arboresence
romain@926: du projet. Ceci implique généralement la perte d'une partie l'historique 
romain@926: d'un des partie, ou même des deux.
romain@926: 
romain@926: Ce que les outils distribués permettent à ce sujet est probablement
romain@926: la \emph{meilleur} façon de développer un projet. Chaque modification
romain@926: que vous effectué est potentiellement un ``fork''. La grande force de 
romain@926: cette approche est que les gestionnaire de source distribué doit être
romain@926: vraiment très efficase pour \emph{fusionner}\footnote{NdT:j'ai choisi de
romain@926: traduire ici \textit{merging} par ``fusionner'' pour des raisons de clarté}
romain@926: des ``forks'', car les ``forks'', dans ce contexte, arrivent tout le
romain@926: temps.
romain@926: 
romain@926: Si chaque altération que n'importe qui effectue, à tout moment, est vu
romain@926: comme un ``fork'' à fusionner, alors ce que le monde de l'\textit{Open 
romain@926: Source} voit comme un ``fork'' devient \emph{uniquement} une problématique 
romain@926: social. En fait, les outils de gestion de source distribué \emph{réduisent} 
romain@926: les chances de ``fork'':
bos@220: \begin{itemize}
romain@926: \item Ils éliminent la distinction social qu'imposent les outils centralisés
romain@926: 	entre les membres du projets (ce qui ont accès au ``comit'') et ceux de l'
romain@926: 	extérieur (ce qui ne l'ont pas).
romain@926: \item Ils rendent plus facile la réconciliation après un ``fork'' social, car
romain@926: 	tout ce qu'elle implique est juste une simple fusion.
bos@220: \end{itemize}
bos@220: 
romain@926: Certaines personnes font de la résistance envers les gestionnaires de source
romain@926: distribués parce qu'ils veulent garder un contrôle ferme de leur projet, et
romain@926: ils pensent que les outils centralisés leur fournissent ce contrôle. Néanmoins,
romain@926: si c'est votre cas, sachez que si vous publier votre dépôt CVS ou Subversion
romain@926: de manière publique, il existe une quantité d'outils disponibles pour récupérer
romain@926: entièrement votre projet et son historique (quoique lentement) et le récréer 
romain@926: ailleurs, sans votre contrôle. En fait, votre contrôle sur votre projet est 
romain@926: illusoire, vous ne faites qu'interdire à vos collaborateurs de travailler
romain@926: de manière fluide, en disposant d'un miroir ou d'un ``fork'' de votre
romain@926: historique.
romain@926: %%%TODO: Fussy, those last sentences are not really well translated:
romain@926: %However, if you're of this belief, and you publish your CVS or Subversion 
romain@926: %repositories publically, there are plenty of tools available that can pull 
romain@926: %out your entire project's history (albeit slowly) and recreate it somewhere 
romain@926: %that you don't control.  So while your control in this case is illusory, you are
romain@926: %forgoing the ability to fluidly collaborate with whatever people feel
romain@926: %compelled to mirror and fork your history.
romain@926: 
romain@926: \subsection{Avantages pour les projets commerciaux}
romain@926: 
romain@926: Beaucoup de projets commerciaux sont réalisé par des équipes éparpillées
romain@926: à travers le globe. Les contributeurs qui sont loin du serveur central
romain@926: devront subir des commandes lentes et même parfois peu fiable. Les 
romain@926: solutions propriétaires gestion de source, tentent de palier ce problème 
romain@926: avec des réplications de site distant qui sont à la fois coûteuses à mettre
romain@926: en place et lourdes à administrer. A un système distribué ne souffre pas
romain@926: de ce genre de problèmes. En outre, il est très aisé de mettre en place
romain@926: plusieurs serveurs de références, disont un par site, de manière à ce qu'il
romain@926: n'y est pas de communication redondante entre les dépôts, sur une connexion
romain@926: longue distance souvent onéreuse.
romain@926: 
romain@926: Les systèmes de gestion de source supportent généralement assez mal la 
romain@926: monté en charge. Ce n'est pas rare pour un gestionnaire de source centralisé 
romain@926: pourtant onéreux de s'effondrer sous la charge combinée de juste une douzaine 
romain@926: d'utilisateurs concurrents. Une fois encore, la réponse à cette problématique 
romain@926: est généralement encore la mise en place d'un ensemble complexe de serveurs
romain@926: synchronisé par un mécanisme de réplication. Dans le cas d'un gestionnaire
romain@926: de source distribué, la charge du serveur central--- si vous avez un--- est
romain@926: plusieurs fois inférieur (car toutes les données sont déjà répliqués ailleurs),
romain@926: un simple server, pas très cher, peut gérer les besoins d'une plus grande
romain@926: équipe, et la réplication pour balancer la charge devient simplement le
romain@926: travail d'un simple script.
romain@926: 
romain@926: Si vous avez des employés sur le terrain, entrain de chercher à résoudre sur
romain@926: le site d'un client, ils bénéficieront aussi d'un gestionnaire de source
romain@926: distribués. Cet outil leur permettra de générer des versions personnalisées,
romain@926: d'essayer différentes solutions, en les isolant aisément les une des autres,
romain@926: et de recherche efficasement à travers l'historique des sources, la cause
romain@926: des bugs ou des régression, tout ceci sans avoir besoin de la moindre 
romain@926: connexion au réseau de votre compagnie.
romain@926: 
romain@926: \section{Pourquoi choisir Mercurial?}
romain@926: 
romain@926: Mercurial a plusieurs caractéristiques qui en font un choix particulièrement
romain@926: pertinent pour la gestion de source:
bos@221: \begin{itemize}
romain@926: 	\item Il est facile à apprendre et à utiliser ;It is easy to learn and use.
romain@926: 	\item il est léger et performant ;
romain@926: 	\item il monte facilement en charge ; 
romain@926: 	\item il est facile à personnaliser ;
bos@221: \end{itemize}
bos@221: 
romain@926: Si vous êtes déjà familier d'un outil de gestion de source, vous serez
romain@926: capable de l'utiliser en moins de 5 minutes. Sinon, ça ne sera pas beaucoup
romain@926: plus long\footnote{NdT: Pour appuyer le propos de l'auteur, je signale que 
romain@926: j'utilise Mercurial comme outil d'initiation à la gestion de contrôle dans
romain@926: des travaux pratique à l'ESME Sudria (\url{http://www.esme.fr}) et que les
romain@926: élèves le prennent en main sans difficulté majeur malgré l'approche distribuée.}. 
romain@926: Les commandes utilisées par Mercurial, comme ses fonctionnalités, sont 
romain@926: généralement uniformes et cohérentes, et vous pouvez donc ainsi garder en tête 
romain@926: simplement quelques règles générales, plutôt qu'un lot complexe d'exceptions.
romain@926: 
romain@926: Sur un petit projet, vous pouvez commencer à travailler avec Mercurial en
romain@926: quelques instants. Ajouter des modifications ou des branches, transférer 
romain@926: ces modifications (localement ou via le réseau), et les opérations 
romain@926: d'historique ou de statut sont aussi très rapide. Mercurial reste hors de 
romain@926: votre chemin grâce à sa simplicité d'utilisation et sa rapidité d'exécution.
romain@926: 
romain@926: L'utilité de Mercurial ne se limite pas à des petits projets: il est 
romain@926: aussi utilisé par des projets ayant des centaines ou même des milliers
romain@926: de contributeurs, avec plusieurs dizaines de milliers de fichiers, et des
romain@926: centaines de méga de code source.
romain@926: 
romain@926: Voici une liste non exhaustive des projets complexe ou critique utilisant 
romain@926: mercurial :
romain@926: %TODO
romain@926: % For both spanish and english version, add the following examples:
romain@926: \begin{itemize}
romain@926: 	\item Firefox ;
romain@926: 	\item OpenSolaris ;
romain@926: 	\item OpenJDK (utilisant en outre l'extension ``forest'' pour gérer
romain@926: 	ses sous modules);
romain@926: \end{itemize}
romain@926: % TODO: Also add appropriate link.
romain@926: 
romain@926: Si les fonctionnalités coeur de Mercurial ne sont pas suffisantes pour vous, 
romain@926: il est très aisé de construire dessus. Mercurial est adapté à l'utilisation
romain@926: au sein de script, et son implémentation interne en python, propre et claire,
romain@926: rend encore plus facile l'ajout de fonctionnalité sous forme d'extension. Il
romain@926: en existe déjà un certains nombres de très populaires et très utiles, 
romain@926: dont le périmètre va de la recherche de bugs à l'amélioration des performances.
bos@221: 
romain@928: \section{Mercurial comparé aux autres outils}
romain@928: 
romain@928: Avant que vous n'alliez plus loin, comprenez bien que cette section
romain@928: reflète mes propres expériences, et elle est donc (j'ose le dire)
romain@928: peu objectives. Néanmoins, j'ai utilisé les outils de gestion de source
romain@928: listé ci dessous, dans la plupart des cas, pendant plusieurs années.
romain@928: %% TODO: Fussy translation.
bos@280: 
bos@221: \subsection{Subversion}
bos@221: 
romain@928: Subversion est un outil de gestion de source les plus populaire, il fût 
romain@928: développé pour remplacer CVS. Il a une architecture client/server centralisée.
romain@928: 
romain@928: Subversion et Mercurial ont des noms de commandes très similaires pour 
romain@928: les mêmes opérations, ainsi si vous êtes familier avec l'un, c'est facile
romain@928: d'apprendre l'autre. Ces deux outils sont portable sur les systèmes 
romain@928: d'exploitation les plus populaires\footnote{NdT:Mercurial fonctionne sans problèmes
romain@928: sur OpenVMS à l'ESME Sudria \url{http://www.esme.fr}, compte tenu que Subversion a été 
romain@928: développé en C, je ne suis pas sûr que son portage aurait été aussi aisé.}.
romain@928: %TODO: Backport this statement in english and spanish 
romain@928: 
romain@928: Avant la version 1.5, Subversion n'offre aucune forme de support pour les fusions. Lors 
romain@928: de l'écriture de ce livre, ces capacités de fusion sont nouvelle, et réputé pour être
romain@928: \href{http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword}{complexes
romain@928: et buggués}.
romain@928: 
romain@928: Mercurial dispose d'un avantages substantiel en terme de performance sur 
romain@928: Subversion sur la plupart des opérations que j'ai pu testé. J'ai mesuré
romain@928: une différence de performance allant de deux à six fois plus rapide avec
romain@928: le système de stockage de fichier local de Subversion~1.4.3 
romain@928: (\emph{ra\_local}), qui la méthode d'accès la plus rapide disponible. Dans
romain@928: un déploiement plus réaliste, impliquant un stockage réseau, Subversion 
romain@928: serait encore plus désavantagé. Parce que la plupart des commandes Subversion
romain@928: doivent communiquer avec le serveur et que Subversion n'a pas de mécanisme
romain@928: de réplication, la capacité du serveur et la bande passante sont devenu des
romain@928: goulots d'étranglement pour les projets de taille moyenne ou grande.
romain@928: 
romain@928: En outre, Subversion implique une surchage substantielle dans le stockage local
romain@928: de certaines données, pour éviter des transactions avec le serveur, pour 
romain@928: certaines opérations communes, tel que la recherche des fichier modifiées
romain@928: (\texttt{status}) et l'affichage des modifications par rapport la révision 
romain@928: courante (\texttt{diff}). En conséquence, un répertoire de travail Subversion
romain@928: a souvent la même taille, ou est plus grand, que un dépôt Mercurial et son
romain@928: espace de travail, bien que le dépôt Mercurial contienne l'intégralité de
romain@928: l'historique.
romain@928: 
romain@928: Subversion est largement supportés par les outils tierses. Mercurial est
romain@928: actuellement encore en retrait de ce point de vue. L'écart se réduit, néanmoins,
romain@928: et en effet certains des outils graphiques sont maintenant supérieur à leurs
romain@928: équivalents Subversion. Comme Mercurial, Subversion dispose d'un excellent
romain@928: manuel utilisateur.
romain@928: 
romain@928: Parce que Subversion ne stocke par l'historique chez ses clients, il est 
romain@928: parfaitement adapté à la gestion de projet qui doivent suivre un ensemble
romain@928: de large fichier binaires et opaques. Si vous suivez une cinquantaine de
romain@928: versions d'un fichier incompressible de 10MB, l'occupation disque coté client
romain@928: d'un projet sous Subversion restera à peu près constante. A l'inverse, 
romain@928: l'occupation disque du même projet sous n'importe lequel des gestionnaire
romain@928: de source distribués grandira rapidement, proportionnellement aux nombres
romain@928: de versions, car les différences entre chaque révision sera très grande.
romain@928: 
romain@928: En outre, c'est souvent difficle ou, généralement, impossible de fusionner
romain@928: des différences dans un fichier binaire. La capacité de Subversion de 
romain@928: vérouiller des fichiers, pour permettre à l'utilisateur d'être le seul
romain@928: à le mettre à jour (``commit'') temporairement, est avantage significatif
romain@928: dans un projet doté de beaucoup de fichiers binaire.
romain@928: 
romain@928: Mercurial peut importer l'historique depuis un dépôt Subversion. Il peut
romain@928: aussi exporter l'ensemble des révisions d'un projet vers un dépôt Subversion.
romain@928: Ceci rend très facile de ``tester l'eau'' et d'utiliser Mercurial et Subversion
romain@928: en parallèle, avant de décider de migrer vers Mercurial. La conversion de 
romain@928: l'historique est incrémental, donc vous pouvez effectuer une conversion 
romain@928: initial, puis de petites additions par la suite pour ajouter les nouvelles
romain@928: modifications.
bos@221: 
bos@221: \subsection{Git}
bos@221: 
romain@928: Git est un outil de gestion de source distribué qui fût développé pour gérer
romain@928: le code source de noyau de Linux. Comme Mercurial, sa conception initial à 
romain@928: était inspiré par Monotone.
romain@928: 
romain@928: Git dispose d'un ensemble conséquent de command, avec plus de~139 commandes
romain@928: individuels pour la version~1.5.0. Il a aussi la réputation d'être difficile
romain@928: à apprendre. Comparé à Git, le point fort de Mercurial est clairement sa 
romain@928: simplicité.
romain@928: 
romain@928: En terme de performance, Git est extrêmement rapide. Dans la plupart des
romain@928: cas, il est plus rapide que Mercurial, tout du moins sur Linux, alors que 
romain@928: Mercurial peut être plus performant sur d'autres opérations. Néanmoins, sur
romain@928: Windows, les performances et le niveau de support général fourni par Git, 
romain@928: au moment de l'écriture de cet ouvrage, bien derrière celui de Mercurial.
romain@928: 
romain@928: Alors que le dépôt Mercurial ne demande aucune maintenance, un dépôt Git
romain@928: exige d'exécuter manuellement et régulièrement la commande ``repacks'' sur
romain@928: ces métadonnées. Sans ceci, les performances de git se dégrade, et la 
romain@928: consommation de l'espace disque augmente rapidement. Un serveur qui contient
romain@928: plusieurs dépôt Git qui ne sont pas régulièrement et fréquement ``repacked''
romain@928: deviendra un vrai problème lors des ``backups'' du disque, et il y eu des
romain@928: cas, où un ``backup'' journalier pouvait durer plus de~24 heures. Un dépôt
romain@928: fraichement ``repacked'' sera légèrement plus petit que un dépôt Mercurial,
romain@928: mais un dépôt non ``repacked'' est beaucoup plus grand.
romain@928: 
romain@928: Le coeur de Git est écrit en C. La plupart des commandes Git sont implémentés
romain@928: sous forme de script Shell ou Perl, et la qualité de ces scripts varient
romain@928: grandement. J'ai plusieurs fois constaté que certains de ces scripts étaient
romain@928: chargé en mémoire aveuglément et que la présence d'erreurs pouvait s'avérer
romain@928: fatal.
romain@928: 
romain@928: Mercurial peut importer l'historique d'un dépôt Git.
bos@280: 
bos@221: \subsection{CVS}
bos@221: 
romain@928: CVS est probablement l'outil de gestion de source le plus utilisé aujourd'hui
romain@928: dans le monde. À cause de son manque de properté interne, il n'est plus 
romain@928: maintenu depuis plusieurs années.
romain@928: 
romain@928: Il a une architecture client/serveur centralisé. Il ne groupe pas les
romain@928: modifications de fichiers dans une opération de ``commit'' atomique, ce
romain@928: qui permet à ses utilisateurs de ``casser le \textit{build}'' assez
romain@928: facilement : une personne peut effectuer une opération de ``commit'' 
romain@928: sans problème puis être bloqué par besoin de fusion, avec comme conséquence
romain@928: néfaste, que les autres utilisateurs ne récupèreront qu'une partie de ses
romain@928: modifications. Ce problème affecte aussi la manière de travailler avec 
romain@928: l'historique du projet. Si vous voulez voir toutes les modifications d'une
romain@928: personne du projet, vous devrez injecter manuellement les descriptions et les
romain@928: \textit{timestamps} des modifications de chacun des fichiers impliqués (si
romain@928: vous savez au moins quels sont ces fichiers).
romain@928: 
romain@928: CVS a une notion étrange des \textit{tags} et des branches que je n'essayerais
romain@928: même de décrire ici. Il ne supporte pas bien les opérations de renommage d'un 
romain@928: fichier ou de répertoire, ce qui facilite la corruption de son dépôt. Il n'a
romain@928: presque pas pour ainsi dire de contrôle de cohérence interne, il est donc 
romain@928: pratiquement impossible de dire si un dépôt est corrompu ni à quel point. Je
romain@928: ne recommanderais pas CVS pour un projet existant ou nouveau.
romain@928: 
romain@928: Mercurial peut importer l'historique d'un projet CVS. Néanmoins, il y a 
romain@928: quelques princinpes à respecter; ce qui est vrai aussi pour les autres
romain@928: outils d'import de projet CVS. À cause de l'absence de ``commit'' atomique
romain@928: et gestion de version de l'arboresence, il n'est pas possible de reconstruire
romain@928: de manière précise l'ensemble de l'historique. Un travail de ``devinette''
romain@928: est donc nécessaire, et les fichiers renommées ne sont pas détectés. Parce 
romain@928: que une bonne part de l'administration d'un dépôt CVS est effectué manuellement, 
romain@928: et est donc, sujette à erreur, il est courant que les impots CVS rencontre 
romain@928: de nombreux problèmes avec les dépôt corrompues (des \textit{timestamps} 
romain@928: de révision complètement buggé et des fichiers vérouillés depuis des années 
romain@928: sont deux des problèmes les moins intéressants dont je me souvienne).
romain@928: 
romain@928: Mercurial peut importer l'historique depuis un dépôt CVS.
bos@280: 
bos@221: \subsection{Commercial tools}
bos@221: 
bos@221: Perforce has a centralised client/server architecture, with no
bos@221: client-side caching of any data.  Unlike modern revision control
bos@221: tools, Perforce requires that a user run a command to inform the
bos@221: server about every file they intend to edit.
bos@221: 
bos@221: The performance of Perforce is quite good for small teams, but it
bos@221: falls off rapidly as the number of users grows beyond a few dozen.
bos@221: Modestly large Perforce installations require the deployment of
bos@221: proxies to cope with the load their users generate.
bos@16: 
bos@280: 
bos@280: \subsection{Choosing a revision control tool}
bos@280: 
bos@280: With the exception of CVS, all of the tools listed above have unique
bos@280: strengths that suit them to particular styles of work.  There is no
bos@280: single revision control tool that is best in all situations.
bos@280: 
bos@280: As an example, Subversion is a good choice for working with frequently
bos@280: edited binary files, due to its centralised nature and support for
bos@318: file locking.
bos@280: 
bos@280: I personally find Mercurial's properties of simplicity, performance,
bos@280: and good merge support to be a compelling combination that has served
bos@280: me well for several years.
bos@280: 
bos@280: 
bos@280: \section{Switching from another tool to Mercurial}
bos@280: 
bos@280: Mercurial is bundled with an extension named \hgext{convert}, which
bos@280: can incrementally import revision history from several other revision
bos@280: control tools.  By ``incremental'', I mean that you can convert all of
bos@280: a project's history to date in one go, then rerun the conversion later
bos@280: to obtain new changes that happened after the initial conversion.
bos@280: 
bos@280: The revision control tools supported by \hgext{convert} are as
bos@280: follows:
bos@280: \begin{itemize}
bos@280: \item Subversion
bos@280: \item CVS
bos@280: \item Git
bos@280: \item Darcs
bos@280: \end{itemize}
bos@280: 
bos@280: In addition, \hgext{convert} can export changes from Mercurial to
bos@280: Subversion.  This makes it possible to try Subversion and Mercurial in
bos@280: parallel before committing to a switchover, without risking the loss
bos@280: of any work.
bos@280: 
bos@280: The \hgxcmd{conver}{convert} command is easy to use.  Simply point it
bos@280: at the path or URL of the source repository, optionally give it the
bos@280: name of the destination repository, and it will start working.  After
bos@280: the initial conversion, just run the same command again to import new
bos@280: changes.
bos@280: 
bos@280: 
bos@16: %%% Local Variables: 
bos@16: %%% mode: latex
bos@16: %%% TeX-master: "00book"
bos@16: %%% End: