bos@16: \chapter{Introduction}
bos@16: \label{chap:intro}
bos@16: 
Wilk@933: \section{À propos de la gestion source}
Wilk@933: 
Wilk@933: La gestion de sources est un processus permettant de gérer différentes
Wilk@933: versions de la même information. Dans sa forme la plus simple, c'est
Wilk@933: ce que tout le monde fait manuellement : quand vous modifiez
romain@923: un fichier, vous le sauvegarder sous un nouveau nom contenant un numéro,
Wilk@933: à chaque fois plus grand que celui de la version précédente.
Wilk@933: 
Wilk@933: Ce genre de gestion de version manuelle est cependant facilement sujette 
romain@923: à des erreurs, ainsi, depuis longtemps, des logiciels existent pour
Wilk@933: résoudre cette problématique. Les premiers outils de gestion de sources
romain@923: étaient destinés à aider un seul utilisateur, à automatiser la gestion
Wilk@933: des versions d'un seul fichier. Dans les dernières décades, cette cible 
Wilk@933: s'est largement agrandie, ils gèrent désormais de multiples fichiers, et
Wilk@933: aident un grand nombre de personnes à travailler ensemble. Les 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: 
Wilk@933: Il y a de nombreuses 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
Wilk@933: que vous n'ayez à le faire. Pour chaque modification, vous aurez à votre
Wilk@933: disposition un journal indiquant \emph{qui} a fait 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 
Wilk@933: gestion de source facilitent le travail collaboratif. Par exemple, quand
Wilk@933: plusieurs personnes font, plus ou moins simultanément, 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
Wilk@933: qui se révèlera être une erreur, vous pourrez revenir à une version
Wilk@933: antérieure d'un fichier ou même d'un ensemble de fichiers. 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
Wilk@933: de votre projet et à gérer l'écart entre chacune.
bos@217: \end{itemize}
Wilk@933: 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: 
Wilk@933: Une question fondamentale à 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 à 
belaran@936: utiliser ou à comprendre exigera un lourd effort d'adaptation.
Wilk@933: 
Wilk@933: Un projet de cinq milles personnes 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: 
Wilk@933: D'un autre coté, un ``rapide hack'' d'une personne 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
Wilk@933: les bases en quelques minutes seulement, et, grâce à sa performance, vous pouvez
romain@924: l'utiliser avec facilité sur le plus petit des projets. Cette simplicité 
Wilk@933: signifie que vous n'avez pas de concepts obscurs ou de séquence de commandes
Wilk@933: défiant l'imagination, sans aucune corrélation avec \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
Wilk@933: bon outil peut faire une grande différence dans la fluidité avec laquelle
romain@924: vous pourrez travailler avec.
romain@924: 
romain@924: \subsection{Les multiples noms de la gestion de source}
romain@924: 
Wilk@933: La gestion de source\footnote{NdT: J'ai utilisé systématiquement le terme
Wilk@933: ``gestion de source'' à travers tout l'ouvrage. Ce n'est pas forcement la
Wilk@933: meilleur traduction, et ceci peut rendre la lecture un peu lourde, mais je
Wilk@933: pense que le document y gagne en clarté et en précision.} est un domaine
Wilk@933: divers, tellement qu'il n'existe pas une seul nom ou acronyme pour le désigner.
Wilk@933: Voilà quelqu'uns des noms ou 
Wilk@933: acronymes que vous rencontrerez le plus souvent\footnote{NdT: J'ai conservé la
Wilk@933: liste des noms en anglais pour des raisons de commodité (ils sont plus
Wilk@933: ``googelable''). En outre, j'ai opté  conserver l'ensemble des opérations de
Wilk@933: Mercurial (\textit{commit},\textit{push}, \textit{pull},...) en anglais, là
Wilk@933: aussi pour faciliter la lecture d'autres documents en anglais, et aussi
Wilk@933: 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: 
Wilk@934: Le plus célèbre des anciens outils de gestion de source est \textit{SCCS
Wilk@934: (Source Code Control System)}, que Marc Rochkind conçu dans les laboratoire de
Wilk@934: recherche de Bell (\textit{Bell Labs}), dans le début des années 70.
Wilk@934: \textit{SCCS} ne fonctionnait que sur des fichiers individuels, et obligeait à
Wilk@934: chaque personne travaillant sur le projet d'avoir un accès à un répertoire de
Wilk@934: travail commun, sur le même système.  Seulement une seule personne pouvait
Wilk@934: modifier un fichier au même moment, ce fonctionnement était assuré par
Wilk@934: l'utilisation de verrou (``lock''). Il était courant que des personnes
Wilk@934: verrouillent des fichiers, et plus tard, oublient de le déverrouiller;
Wilk@934: empêchant n'importe qui d'autre de travailler sur ces fichiers sans l'aide de
Wilk@934: l'administrateur...
Wilk@934: 
Wilk@934: Walter Tichy a développé une alternative libre à \textit{SCCS} au début des
Wilk@934: années 80, qu'il nomma \textit{RSC (Revison Control System)}.  Comme
Wilk@934: \textit{SCCS}, \textit{RCS} demander aux développeurs de travailler sur le même
Wilk@934: répertoire partagé, et de verrouiller les
romain@924: fichiers pour se prémunir de tout conflit issue de modifications concurrentes.
romain@924: 
Wilk@934: Un peu plus tard dans les années 1980, Dick Grune utilisa \textit{RCS} comme
Wilk@934: une brique de base pour un ensemble de scripts \textit{shell} qu'il intitula
Wilk@934: cmt, avant de la renommer en \textit{CVS (Concurrent Versions System)}.  La
Wilk@934: grande innovation de CVS était que les développeurs pouvaient travailler
Wilk@934: simultanément et indépendamment dans leur propre espace de travail. Ces espaces
Wilk@934: de travail privés assuraient que les développeurs ne se marchent pas
Wilk@934: mutuellement sur les pieds, comme c'était souvent le cas avec RCS et SCCS.
Wilk@934: Chaque développeur disposait donc de sa copie de tous les fichiers du projet,
Wilk@934: et ils pouvaient donc librement les modifier. Ils devaient néanmoins effectuer
Wilk@934: la ``fusion'' (\textit{``merge''}) de leurs fichiers, avant d'effectuer le
Wilk@934: ``commit'' de leur modifications sur le dépôt central.
Wilk@934: 
Wilk@934: Brian Berliner repris les scripts de Grune's et les réécris en~C, qu'il publia
Wilk@934: en 1989. Depuis, ce code a été modifié jusqu'à devenir la version moderne de
Wilk@934: CVS. CVS a acquis ainsi la capacité de fonctionner en réseau, transformant son
Wilk@934: architecture en client/serveur. L'architecture de CVS est centralisée, seul le
Wilk@934: serveur a une copie de l'historique du projet. L'espace de travail client ne
Wilk@934: contient qu'une copie de la dernière version du projet, et quelques métadonnées
Wilk@934: pour indiquer où le serveur se trouve. CVS a été un grand succès, aujourd'hui
Wilk@934: c'est probablement l'outil de gestion de contrôle le plus utilisé au monde. 
Wilk@934: 
Wilk@934: Au début des années 1990, Sun Microsystmes développa un premier outil de
Wilk@934: gestion de source distribué, nommé TeamWare. Un espace de travail TeamWare
Wilk@934: contient une copie complète de l'historique du projet. TeamWare n'a pas de
Wilk@934: notion de dépôt central. (CVS utilisait RCS pour le stockage de l'historique,
Wilk@934: TeamWare utilisait SCCS).
Wilk@934: 
Wilk@934: Alors que les années 1990 avançaient, les utilisateurs ont pris conscience d'un
Wilk@934: certain nombre de problèmes avec CVS. Il enregistrait simultanément des
Wilk@934: modifications sur différents fichiers individuellement, au lieu de les
Wilk@934: regrouper dans une seule opération cohérente et atomique. Il ne gère pas bien
Wilk@934: sa hiérarchie de fichier, il est donc assez aisé de créer le chaos en renommant
Wilk@934: les fichiers et les répertoires. Pire encore, son code source est difficile à
Wilk@934: lire et à maintenir, ce qui agrandit largement le ``niveau de souffrance''
Wilk@934: associé à la réparation de ces problèmes d'architecture de manière prohibitive. 
Wilk@934: 
Wilk@934: En 2001, Jim Blandy et Karl Fogel, deux développeurs qui avaient travaillés sur
Wilk@934: CVS, initièrent un projet pour le remplacer par un outil qui aurait une
Wilk@934: meilleur architecture et un code plus propre. Le résultat, Subversion, ne
Wilk@934: quitte pas le modèle centralisé et client/server de CVS, mais ajoute les
Wilk@934: opérations de ``commit'' atomique sur de multiples fichiers, une meilleure
Wilk@934: gestion des espaces de noms, et d'autres fonctionnalités qui en font un
Wilk@934: meilleur outil que CVS. Depuis sa première publication, il est rapidement
Wilk@934: devenu très populaire.
Wilk@934: 
Wilk@934: Plus ou moins de simultanément, Graydon Hoare a commencé sur l'ambitieux
Wilk@934: système de gestion distribué Monotone. Bien que Monotone corrige plusieurs
Wilk@934: défaut de CVS's tout en offrant une architecture ``peer-to-peer'', il va aussi
Wilk@934: plus loin que la plupart des outils de révision de manière assez innovante. Il
Wilk@934: utilise des ``hash'' cryptographique comme identifiant, et il a une notion
Wilk@934: complète de ``confiance'' du code issue de différentes sources.
Wilk@934: 
Wilk@934: Mercurial est né en 2005. Bien que très influencé par Monotone, Mercurial se
Wilk@934: concentre sur la facilité d'utilisation, les performances et la capacité à
Wilk@934: monter en charge pour de très gros projets.
romain@926: 
romain@926: \section{Tendances de la gestion de source}
romain@926: 
Wilk@934: Il y a eu une tendance évidente dans le développement et l'utilisation d'outil
Wilk@934: de gestion de source depuis les quatre dernières décades, au fur et à mesure
Wilk@934: que les utilisateurs se sont habitués à leur outils et se sont sentis contraint
Wilk@934: par leur limitations.
Wilk@934: 
Wilk@934: La première génération commença simplement par gérer un fichier unique sur un
Wilk@934: ordinateur individuel. Cependant, même si ces outils présentaient une grande
Wilk@934: avancée par rapport à la gestion manuelle des versions, leur modèle de
Wilk@934: verrouillage et leur utilisation limitée à un seul ordinateur rendait leur
Wilk@934: utilisation possible uniquement dans une très petite équipe. 
Wilk@934: 
Wilk@934: La seconde génération a assoupli ces contraintes en adoptant une architecture
Wilk@934: réseau et centralisé, permettant de gérer plusieurs projets entiers en même
Wilk@934: temps. Alors que les projets grandirent en taille, ils rencontrèrent de nouveau
Wilk@934: problèmes. Avec les clients discutant régulièrement avec le serveurs, la montée
Wilk@934: en charge devint un réel problème sur les gros projets. Une connexion réseau
Wilk@934: peu fiable pouvant complètement empêcher les utilisateurs distant de dialoguer
Wilk@934: avec le serveur. Alors que les projets \textit{Open Source} commencèrent à
Wilk@934: mettre en place des accès en lecture seule disponible anonymement, les
Wilk@934: utilisateurs sans les privilèges de ``commit'' réalisèrent qu'ils ne pouvaient
Wilk@934: pas utiliser les outils pour collaborer naturellement avec le projet, comme ils
Wilk@934: ne pouvaient pas non plus enregistrer leurs modifications.
Wilk@934: 
Wilk@934: La génération actuelle des outils de gestion de source est ``peer-to-peer'' par
Wilk@934: nature. Tout ces systèmes ont abandonné la dépendance à un serveur central, et
Wilk@934: ont permis à leur utilisateur de distribuer les données de leur gestion de
Wilk@934: source à qui en a besoin. La collaboration à travers Internet a transformée la
Wilk@934: contrainte technologique à une simple question de choix et de consencus. Les
Wilk@934: outils moderne peuvent maintenant fonctionner en mode déconnecté sans limite et
Wilk@934: de manière autonome, la connexion au réseau n'étant nécessaire que pour
Wilk@934: synchroniser les modifications avec les autres dépôts.
romain@926: 
romain@926: \section{Quelques avantages des gestionnaire de source distribué}
romain@926: 
Wilk@933: Même si les gestionnaire de source distribués sont depuis plusieurs années
Wilk@933: assez robustes et aussi utilisables que leur prédécesseurs, les utilisateurs
Wilk@933: d'autres outils n'y ont pas encore été sensibilisés. Les gestionnaires
Wilk@933: de sources distribués se distinguent particulièrement de leurs équivalents
Wilk@933: centralisés de nombreuses manières.
Wilk@933: 
Wilk@933: Pour un développeur individuel, ils restent beaucoup plus rapides que les
Wilk@933: outils centralisés. Cela pour une raison simple : un outil centralisé doit
Wilk@933: toujours dialoguer à 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 
Wilk@933: 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: 
Wilk@933: Les outils distribués sont complètement indépendants des aléas de votre serveur,
Wilk@933: d'autant plus qu'ils répliquent les métadonnées à beaucoup d'endroits. Si
Wilk@933: votre serveur central prend feu, vous avez intérêt à ce que les médias de 
Wilk@933: sauvegardes soient fiables, 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
Wilk@933: outils distribués. Vous ne pouvez même pas utiliser un outil centralisé
Wilk@933: sans connexion réseau, à l'exception de quelques commandes, très limitées. 
Wilk@933: Avec un outil distribué, si votre 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
Wilk@933: locales. Si vous avez une équipe de collaborateurs très dispersés ceci peut
Wilk@933: ê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"
Wilk@933: avec les personnes formant le ``cœur'' 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: 
Wilk@933: Il a été souvent suggéré 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 
belaran@936: d'une 
belaran@937: \url{version alternative du logiciel}{http://fr.wikipedia.org/wiki/Fork\#Embranchement\_d.27un\_projet\_informatique}.}
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 
belaran@936: plus travailler ensemble. Chaque 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: 
Wilk@933: Parfois ces différents partis décident 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
Wilk@933: moyen ou un autre, les modifications de l'autre équipe dans l'arborescence
Wilk@933: du projet. Ceci implique généralement la perte d'une partie de 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
Wilk@933: que vous effectuez est potentiellement un ``fork''. La grande force de 
Wilk@933: cette approche est que les gestionnaires de source distribués doivent être
Wilk@933: vraiment très efficasses 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: 
Wilk@933: Si chaque altération que n'importe qui effectue, à tout moment, est vue
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 
Wilk@933: sociale. En fait, les outils de gestions de source distribués \emph{réduisent} 
romain@926: les chances de ``fork'':
bos@220: \begin{itemize}
Wilk@933: \item Ils éliminent la distinction sociale qu'imposent les outils centralisés
Wilk@933: 	entre les membres du projets (ceux qui ont accès au ``commit'') 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:
Wilk@933: %%%no problem for me (wilk)
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: 
Wilk@933: Beaucoup de projets commerciaux sont réalisés par des équipes éparpillées
romain@926: à travers le globe. Les contributeurs qui sont loin du serveur central
Wilk@933: devront subir des commandes lentes et même parfois peu fiables. Les 
Wilk@933: solutions propriétaires de 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
Wilk@933: en place et lourdes à administrer. 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
Wilk@933: plusieurs serveurs de références, disons 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 
Wilk@933: montée en charge. Ce n'est pas rare pour un gestionnaire de source centralisé 
Wilk@933: pourtant onéreux de s'effondrer sous la charge combinée d'une douzaine 
Wilk@933: d'utilisateurs concurrents seulement. 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
Wilk@933: synchronisés par un mécanisme de réplication. Dans le cas d'un gestionnaire
Wilk@933: de source distribué, la charge du serveur central --- si vous avez un--- est
Wilk@933: plusieurs fois inférieure (car toutes les données sont déjà répliquées ailleurs),
Wilk@933: un simple serveur, pas très cher, peut gérer les besoins d'une plus grande
Wilk@933: équipe, et la réplication pour balancer la charge devient le
romain@926: travail d'un simple script.
romain@926: 
Wilk@933: Si vous avez des employés sur le terrain, entrain de chercher à résoudre un soucis 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,
Wilk@933: et de rechercher efficacement à travers l'historique des sources, la cause
Wilk@933: des bugs ou des régressions, 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}
Wilk@933: 	\item Il est facile à apprendre et à utiliser ;
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: 
Wilk@933: Voici une liste non exhaustive des projets complexes ou critiques utilisant 
Wilk@933: Mercurial :
romain@926: %TODO
romain@926: % For both spanish and english version, add the following examples:
romain@926: \begin{itemize}
belaran@937: 	\item \url{Firefox}{https://developer.mozilla.org/en/Mozilla\_Source\_Code\_(Mercurial)} ;
belaran@937: 	\item \url{OpenSolaris}{http://opensolaris.org/os/community/tools/scm/hg\_help/} ;
belaran@936: 	\item \url{OpenJDK}{http://hg.openjdk.java.net/} (utilisant en outre l'extension 
belaran@936: 	``forest'' pour gérer ses sous modules);
romain@926: \end{itemize}
romain@926: 
Wilk@933: Si les fonctionnalités cœur de Mercurial ne sont pas suffisantes pour vous, 
belaran@936: il est très aisé d'en construire d'autres. Mercurial est adapté à l'utilisation
Wilk@933: de scripts, et son implémentation interne en Python, propre et claire,
Wilk@933: rend encore plus facile l'ajout de fonctionnalité sous forme d'extensions. Il
Wilk@933: en existe déjà un certain nombre 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)
Wilk@933: peu objective. 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: 
Wilk@933: Avant la version 1.5, Subversion n'offrait aucune forme de support pour les fusions. Lors 
Wilk@933: de l'écriture de ce livre, ces capacités de fusion étaient nouvelles, et réputés 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: 
Wilk@933: Mercurial dispose d'un avantage substantiel en terme de performance par rapport à 
Wilk@933: Subversion sur la plupart des opérations que j'ai pu tester. 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 
Wilk@933: (\emph{ra\_local}), qui est 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
Wilk@933: goulots d'étranglement pour les projets de tailles moyennes ou grandes.
Wilk@933: 
Wilk@933: En outre, Subversion implique une surcharge 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
Wilk@933: a souvent la même taille, ou est plus grand, qu'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: 
Wilk@933: Subversion est largement supporté par les outils tierces. Mercurial est
romain@928: actuellement encore en retrait de ce point de vue. L'écart se réduit, néanmoins,
Wilk@933: et en effet certains des outils graphiques sont maintenant supérieurs à leurs
romain@928: équivalents Subversion. Comme Mercurial, Subversion dispose d'un excellent
romain@928: manuel utilisateur.
romain@928: 
Wilk@933: Parce que Subversion ne stocke pas l'historique chez ses clients, il est 
Wilk@933: parfaitement adapté à la gestion de projets qui doivent suivre un ensemble
Wilk@933: de larges fichiers 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
Wilk@933: de versions, car les différences entre chaque révisions sera très grande.
Wilk@933: 
Wilk@933: En outre, c'est souvent difficile ou, généralement, impossible de fusionner
romain@928: des différences dans un fichier binaire. La capacité de Subversion de 
Wilk@933: verrouiller des fichiers, pour permettre à l'utilisateur d'être le seul
Wilk@933: à le mettre à jour (``commit'') temporairement, est un avantage significatif
Wilk@933: dans un projet doté de beaucoup de fichiers binaires.
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.
Wilk@933: Ceci rend très facile de ``prendre la température'' et d'utiliser Mercurial et Subversion
romain@928: en parallèle, avant de décider de migrer vers Mercurial. La conversion de 
Wilk@933: l'historique est incrémentale, donc vous pouvez effectuer une conversion 
Wilk@933: initiale, 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
Wilk@933: le code source de noyau de Linux. Comme Mercurial, sa conception initiale à 
Wilk@933: était inspirée par Monotone.
Wilk@933: 
Wilk@933: Git dispose d'un ensemble conséquent de commandes, avec plus de~139 commandes
Wilk@933: individuelles 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, 
Wilk@933: au moment de l'écriture de cet ouvrage, est 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
Wilk@933: plusieurs dépôts Git qui ne sont pas régulièrement et fréquemment ``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
Wilk@933: fraichement ``repacked'' sera légèrement plus petit qu'un dépôt Mercurial,
romain@928: mais un dépôt non ``repacked'' est beaucoup plus grand.
romain@928: 
Wilk@933: Le cœur de Git est écrit en C. La plupart des commandes Git sont implémentées
Wilk@933: sous forme de scripts Shell ou Perl, et la qualité de ces scripts varie
romain@928: grandement. J'ai plusieurs fois constaté que certains de ces scripts étaient
Wilk@933: chargés en mémoire aveuglément et que la présence d'erreurs pouvait s'avérer
Wilk@933: fatale.
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
Wilk@933: dans le monde. À cause de son manque de clarté interne, il n'est plus 
romain@928: maintenu depuis plusieurs années.
romain@928: 
Wilk@933: Il a une architecture client/serveur centralisée. Il ne regroupe 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
Wilk@933: même pas de décrire ici. Il ne supporte pas bien les opérations de renommage d'un 
Wilk@933: fichier ou d'un 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 
Wilk@933: quelques principes à respecter; ce qui est vrai aussi pour les autres
romain@928: outils d'import de projet CVS. À cause de l'absence de ``commit'' atomique
Wilk@933: et gestion de version de l'arborescence, 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 
Wilk@933: qu'une bonne part de l'administration d'un dépôt CVS est effectuée manuellement, 
Wilk@933: et est donc, sujette à erreur, il est courant que les imports CVS rencontrent 
romain@928: de nombreux problèmes avec les dépôt corrompues (des \textit{timestamps} 
Wilk@933: de révision complètement buggé et des fichiers verrouillé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: 
Wilk@933: Perforce a une architecture client/serveur centralisée, sans aucun
Wilk@933: mécanisme de mise en cache de données coté client. Contrairement à la plupart
romain@929: des outils modernes de gestion de source, Perforce exige de ses 
romain@929: utilisateurs d'exécuter une commande pour informer le serveur
romain@929: central de tout fichier qu'il souhaite modifier.
romain@929: 
romain@929: Les performances de Perforce sont plutôt bonnes pour des petites
romain@929: équipes, mais elles s'effondrent rapidement lorsque le nombre 
romain@929: d'utilisateurs augmente au delà de la douzaine. Des installations 
Wilk@933: de Perforce assez larges nécessitent le déploiement de proxies pour 
romain@929: supporter la montée en charge associée.
bos@280: 
Wilk@933: \subsection{Choisir un outil de gestion de source}
Wilk@933: 
Wilk@933: A l'exception de CVS, tous les outils listés ci-dessus ont des 
romain@929: forces qui leur sont propres et qui correspondent à certaines
romain@929: formes de projet. Il n'y a pas un seul meilleur outil de gestion
romain@929: de source qui correspondent le mieux à toutes les situations.
romain@929: 
Wilk@933: Par exemple, Subversion est un très bon choix lorsqu'on travaille
Wilk@933: avec beaucoup de fichiers binaires, qui évoluent régulièrement, grâce
Wilk@933: à sa nature centralisée et sa capacité à verrouiller des fichiers.
romain@929: 
romain@929: Personnellement, je préfère Mercurial pour sa simplicité, ses 
Wilk@933: performances et sa bonne capacité de fusion, et il m'a très bien rendu service
romain@929: de plusieurs années maintenant.
romain@929: 
romain@929: \section{Migrer depuis un outil à Mercurial}
romain@929: 
romain@929: Mercurial est livré avec une extension nommée \hgext{convert}, qui
Wilk@933: peut de manière incrémentale importer des révisions depuis différents
Wilk@933: autres outils de gestion de source. Par ``incrémental'', j'entends que
romain@929: vous pouvez convertir l'historique entier du projet en une seule fois,
romain@929: puis relancer l'outil d'import plus tard pour obtenir les modifications
Wilk@933: effectués depuis votre import initial.
romain@929: 
romain@929: Les outils de gestion de source supportés par \hgext{convert} sont :
bos@280: \begin{itemize}
romain@929: 	\item Subversion
romain@929: 	\item CVS
romain@929: 	\item Git
romain@929: 	\item Darcs
bos@280: \end{itemize}
bos@280: 
romain@929: En outre, \hgext{convert} peut exporter les modifications depuis Mercurial
Wilk@933: vers Subversion. Ceci rend possible d'essayer Subversion en parallèle 
romain@929: avant de choisir une solution définitive, sans aucun risque de perte de
romain@929: données.
romain@929: 
romain@929: La commande \hgxcmd{conver}{convert} est très simple à utiliser. Simplement,
Wilk@933: indiquez le chemin ou l'URL du dépôt de source, en lui indiquant éventuellement
Wilk@933: le nom du chemin de destination, et la conversion se met en route. Après cet
romain@929: import initial, il suffit de relancer la commande encore une fois pour 
romain@929: importer les modifications effectuées depuis.
bos@280: 
bos@16: %%% Local Variables: 
bos@16: %%% mode: latex
bos@16: %%% TeX-master: "00book"
bos@16: %%% End: