belaran@964: belaran@964: belaran@964: belaran@964: Introduction belaran@964: \label{chap:intro} belaran@964: belaran@964: belaran@964: À propos de la gestion source belaran@964: belaran@964: La gestion de sources 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. belaran@964: belaran@964: Ce genre de gestion de version manuelle est cependant facilement sujette belaran@964: à des erreurs, ainsi, depuis longtemps, des logiciels existent pour belaran@964: résoudre cette problématique. Les premiers outils de gestion de sources belaran@964: étaient destinés à aider un seul utilisateur, à automatiser la gestion belaran@964: des versions d'un seul fichier. Dans les dernières décades, 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. belaran@964: belaran@964: belaran@964: Pourquoi utiliser un gestionnaire de source ? belaran@964: belaran@964: Il y a de nombreuses raisons pour que vous ou votre équipe souhaitiez belaran@964: utiliser un outil automatisant la gestion de version pour votre projet. belaran@964: belaran@964: L'outil se chargera de suivre l'évolution de votre projet, sans belaran@964: que vous n'ayez à le faire. Pour chaque modification, vous aurez à votre belaran@964: disposition un journal indiquant qui a fait quoi, pourquoi belaran@964: ils l'ont fait, quand ils l'ont fait, et ce qu'ils ont belaran@964: modifiés. belaran@964: belaran@964: Quand vous travaillez avec d'autres personnes, les logiciels de belaran@964: gestion de source 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. belaran@964: belaran@964: 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 belaran@964: gestion de source vraiment efficace vous permettra d'identifier à quel belaran@964: moment le problème est apparu (voir la section pour plus belaran@964: de détails). belaran@964: belaran@964: L'outil vous permettra aussi de travailler sur plusieurs versions différentes belaran@964: de votre projet et à gérer l'écart entre chacune. belaran@964: belaran@964: La plupart de ces raisons ont autant d'importances &emdash;du moins en théorie&emdash; que belaran@964: vous travailliez sur un projet pour vous, ou avec une centaine d'autres belaran@964: personnes. belaran@964: belaran@964: belaran@964: Une question fondamentale à propos des outils de gestion de source, qu'il s'agisse belaran@964: du projet d'une personne ou d'une grande équipe, est quels sont ses belaran@964: avantages par rapport à ses coûts. Un outil qui est difficile à belaran@964: utiliser ou à comprendre exigera un lourd effort d'adaptation. belaran@964: belaran@964: belaran@964: Un projet de cinq milles personnes s'effondrera très certainement de lui même belaran@964: sans aucun processus et outil de gestion de source. Dans ce cas, le coût belaran@964: d'utilisation d'un logiciel de gestion de source est dérisoire puisque belaran@964: sans, l'échec est presque garanti. belaran@964: belaran@964: belaran@964: D'un autre coté, un rapide hack d'une personne peut sembler un contexte belaran@964: bien pauvre pour utiliser un outil de gestion de source, car, bien évidement belaran@964: le coût d'utilisation dépasse le coût total du projet. N'est ce pas ? belaran@964: belaran@964: belaran@964: Mercurial supporte ces deux échelles de travail. Vous pouvez apprendre belaran@964: les bases en quelques minutes seulement, et, grâce à sa performance, vous pouvez belaran@964: l'utiliser avec facilité sur le plus petit des projets. Cette simplicité belaran@964: signifie que vous n'avez pas de concept obscurs ou de séquence de commandes belaran@964: défiant l'imagination, sans aucune corrélation avec \emph{ce que vous êtes belaran@964: vraiment en train de faire}. En même temps, ces mêmes performances et sa belaran@964: nature peer-to-peer vous permettent d'augmenter, sans difficulté, son belaran@964: utilisation à de très grands projets. belaran@964: belaran@964: belaran@964: Aucun outil de gestion de source ne peut sauver un projet mal mené, mais un belaran@964: bon outil peut rendre beaucoup plus fluide votre travail. belaran@964: belaran@964: belaran@964: belaran@964: belaran@964: Les multiples noms de la gestion de source belaran@964: belaran@964: La gestion de source\footnote{NdT: J'ai utilisé systématiquement le terme belaran@964: gestion de source à travers tout l'ouvrage. Ce n'est pas forcement la belaran@964: meilleure traduction, et ceci peut rendre la lecture un peu lourde, mais je belaran@964: pense que le document y gagne en clarté et en précision.} est un domaine belaran@964: divers, tellement qu'il n'existe pas une seul nom ou acronyme pour le désigner. belaran@964: Voilà quelqu'uns des noms ou belaran@964: acronymes que vous rencontrerez le plus souvent\footnote{NdT: J'ai conservé la belaran@964: liste des noms en anglais pour des raisons de commodité (ils sont plus belaran@964: googelable). En outre, j'ai opté pour conserver l'ensemble des opérations de belaran@964: Mercurial (\textit{commit},\textit{push}, \textit{pull},...) en anglais, là belaran@964: aussi pour faciliter la lecture d'autres documents en anglais, ainsi que belaran@964: l'utilisation de Mercurial}. belaran@964: belaran@964: belaran@964: : belaran@964: belaran@964: belaran@964: \textit{Revision control (RCS)} ; belaran@964: belaran@964: belaran@964: Software configuration management (SCM), ou \textit{configuration management} ; belaran@964: belaran@964: belaran@964: \textit{Source code management} ; belaran@964: belaran@964: belaran@964: \textit{Source code control}, ou \textit{source control} ; belaran@964: belaran@964: belaran@964: \textit{Version control (VCS)}. belaran@964: belaran@964: belaran@964: belaran@964: Certaines personnes prétendent que ces termes ont en fait des sens belaran@964: différents mais en pratique ils se recouvrent tellement qu'il n'y a pas belaran@964: réellement de manière pertinente de les distinguer. belaran@964: belaran@964: belaran@964: belaran@964: belaran@964: belaran@964: Une courte histoire de la gestion de source belaran@964: belaran@964: Le plus célèbre des anciens outils de gestion de source est \textit{SCCS belaran@964: (Source Code Control System)}, que Marc Rochkind conçu dans les laboratoires de belaran@964: recherche de Bell (\textit{Bell Labs}), dans le début des années 70. belaran@964: \textit{SCCS} ne fonctionnait que sur des fichiers individuels, et obligeait chaque belaran@964: personne travaillant sur le projet d'avoir un accès à un répertoire de belaran@964: travail commun, sur le même système. Seulement une seule personne pouvait belaran@964: modifier un fichier au même moment, ce fonctionnement était assuré par belaran@964: l'utilisation de verrou (lock). Il était courant que des personnes belaran@964: verrouillent des fichiers, et plus tard, oublient de le déverrouiller; belaran@964: empêchant n'importe qui d'autre de travailler sur ces fichiers sans l'aide de belaran@964: l'administrateur... belaran@964: belaran@964: belaran@964: Walter Tichy a développé une alternative libre à \textit{SCCS} au début des belaran@964: années 80, qu'il nomma \textit{RSC (Revison Control System)}. Comme belaran@964: \textit{SCCS}, \textit{RCS} demandait aux développeurs de travailler sur le même belaran@964: répertoire partagé, et de verrouiller les belaran@964: fichiers pour se prémunir de tout conflit issu de modifications concurrentes. belaran@964: belaran@964: belaran@964: Un peu plus tard dans les années 1980, Dick Grune utilisa \textit{RCS} comme belaran@964: une brique de base pour un ensemble de scripts \textit{shell} qu'il intitula belaran@964: cmt, avant de la renommer en \textit{CVS (Concurrent Versions System)}. La belaran@964: grande innovation de CVS était que les développeurs pouvaient travailler belaran@964: simultanément et indépendamment dans leur propre espace de travail. Ces espaces belaran@964: de travail privés assuraient que les développeurs ne se marchent pas belaran@964: mutuellement sur les pieds, comme c'était souvent le cas avec RCS et SCCS. belaran@964: Chaque développeur disposait donc de sa copie de tous les fichiers du projet, belaran@964: et ils pouvaient donc librement les modifier. Ils devaient néanmoins effectuer belaran@964: la fusion (\textit{merge}) de leurs fichiers, avant d'effectuer le belaran@964: commit de leur modifications sur le dépôt central. belaran@964: belaran@964: belaran@964: Brian Berliner reprit les scripts de Grune's et les réécrit en C, qu'il publia belaran@964: en 1989. Depuis, ce code a été modifié jusqu'à devenir la version moderne de belaran@964: CVS. CVS a acquis ainsi la capacité de fonctionner en réseau, transformant son belaran@964: architecture en client/serveur. L'architecture de CVS est centralisée, seul le belaran@964: serveur a une copie de l'historique du projet. L'espace de travail client ne belaran@964: contient qu'une copie de la dernière version du projet, et quelques métadonnées belaran@964: pour indiquer où le serveur se trouve. CVS a été un grand succès, aujourd'hui belaran@964: il est probablement l'outil de gestion de contrôle le plus utilisé au monde. belaran@964: belaran@964: belaran@964: Au début des années 1990, Sun Microsystmes développa un premier outil de belaran@964: gestion de source distribué, nommé TeamWare. Un espace de travail TeamWare belaran@964: contient une copie complète de l'historique du projet. TeamWare n'a pas de belaran@964: notion de dépôt central. (CVS utilisait RCS pour le stockage de l'historique, belaran@964: TeamWare utilisait SCCS). belaran@964: belaran@964: belaran@964: Alors que les années 1990 avançaient, les utilisateurs ont pris conscience d'un belaran@964: certain nombre de problèmes avec CVS. Il enregistrait simultanément des belaran@964: modifications sur différents fichiers individuellement, au lieu de les belaran@964: regrouper dans une seule opération cohérente et atomique. Il ne gère pas bien belaran@964: sa hiérarchie de fichier, il est donc assez aisé de créer le chaos en renommant belaran@964: les fichiers et les répertoires. Pire encore, son code source est difficile à belaran@964: lire et à maintenir, ce qui agrandit largement le niveau de souffrance belaran@964: associé à la réparation de ces problèmes d'architecture de manière prohibitive. belaran@964: belaran@964: belaran@964: En 2001, Jim Blandy et Karl Fogel, deux développeurs qui avaient travaillé sur belaran@964: CVS, initièrent un projet pour le remplacer par un outil qui aurait une belaran@964: meilleure architecture et un code plus propre. Le résultat, Subversion, ne belaran@964: quitte pas le modèle centralisé et client/server de CVS, mais ajoute les belaran@964: opérations de commit atomique sur de multiples fichiers, une meilleure belaran@964: gestion des espaces de noms, et d'autres fonctionnalités qui en font un belaran@964: meilleur outil que CVS. Depuis sa première publication, il est rapidement belaran@964: devenu très populaire. belaran@964: belaran@964: belaran@964: Plus ou moins simultanément, Graydon Hoare a commencé sur l'ambitieux belaran@964: système de gestion distribué Monotone. Bien que Monotone corrige plusieurs belaran@964: défauts de CVS's tout en offrant une architecture peer-to-peer, il va aussi belaran@964: plus loin que la plupart des outils de révision de manière assez innovante. Il belaran@964: utilise des hash cryptographiques comme identifiants, et il a une notion belaran@964: complète de confiance du code issu des différentes sources. belaran@964: belaran@964: belaran@964: Mercurial est né en 2005. Bien que très influencé par Monotone, Mercurial se belaran@964: concentre sur la facilité d'utilisation, les performances et la capacité à belaran@964: monter en charge pour de très gros projets. belaran@964: belaran@964: belaran@964: belaran@964: belaran@964: Tendances de la gestion de source belaran@964: belaran@964: Il y a eu une tendance évidente dans le développement et l'utilisation d'outils belaran@964: de gestion de source depuis les quatre dernières décades, au fur et à mesure belaran@964: que les utilisateurs se sont habitués à leur outils et se sont sentis contraints belaran@964: par leurs limitations. belaran@964: belaran@964: belaran@964: La première génération commença simplement par gérer un fichier unique sur un belaran@964: ordinateur individuel. Cependant, même si ces outils présentaient une grande belaran@964: avancée par rapport à la gestion manuelle des versions, leur modèle de belaran@964: verrouillage et leur utilisation limitée à un seul ordinateur rendaient leur belaran@964: utilisation possible uniquement dans une très petite équipe. belaran@964: belaran@964: belaran@964: La seconde génération a assoupli ces contraintes en adoptant une architecture belaran@964: réseau et centralisée, permettant de gérer plusieurs projets entiers en même belaran@964: temps. Alors que les projets grandirent en taille, ils rencontrèrent de nouveaux belaran@964: problèmes. Avec les clients discutant régulièrement avec le serveurs, la montée belaran@964: en charge devint un réel problème sur les gros projets. Une connexion réseau belaran@964: peu fiable pouvait complètement empêcher les utilisateurs distants de dialoguer belaran@964: avec le serveur. Alors que les projets \textit{Open Source} commencèrent à belaran@964: mettre en place des accès en lecture seule disponible anonymement, les belaran@964: utilisateurs sans les privilèges de commit réalisèrent qu'ils ne pouvaient belaran@964: pas utiliser les outils pour collaborer naturellement avec le projet, comme ils belaran@964: ne pouvaient pas non plus enregistrer leurs modifications. belaran@964: belaran@964: belaran@964: La génération actuelle des outils de gestion de source est peer-to-peer par belaran@964: nature. Tout ces systèmes ont abandonné la dépendance à un serveur central, et belaran@964: ont permis à leur utilisateur de distribuer les données de leur gestion de belaran@964: source à qui en a besoin. La collaboration à travers Internet a transformé la belaran@964: contrainte technologique en une simple question de choix et de consencus. Les belaran@964: outils modernes peuvent maintenant fonctionner en mode déconnecté sans limite et belaran@964: de manière autonome, la connexion au réseau n'étant nécessaire que pour belaran@964: synchroniser les modifications avec les autres dépôts. belaran@964: belaran@964: belaran@964: belaran@964: belaran@964: Quelques avantages des gestionnaires de source distribués belaran@964: belaran@964: Même si les gestionnaire de source distribués sont depuis plusieurs années belaran@964: assez robustes et aussi utilisables que leurs prédécesseurs, les utilisateurs belaran@964: d'autres outils n'y ont pas encore été sensibilisés. Les gestionnaires belaran@964: de source distribués se distinguent particulièrement de leurs équivalents belaran@964: centralisés de nombreuses manières. belaran@964: belaran@964: belaran@964: Pour un développeur individuel, ils restent beaucoup plus rapides que les belaran@964: outils centralisés. Cela pour une raison simple : un outil centralisé doit belaran@964: toujours dialoguer à travers le réseau pour la plupart des opérations, car belaran@964: presque toutes les métadonnées sont stockées sur la seule copie du serveur belaran@964: central. Un outil distribué stocke toute ses métadonnées localement. À tâche belaran@964: égale, effectuer un échange avec le réseau ajoute un délai aux outils belaran@964: centralisés. Ne sous-estimez pas la valeur d'un outil rapide : vous allez belaran@964: passer beaucoup de temps à interagir avec un logiciel de gestion de source. belaran@964: belaran@964: belaran@964: Les outils distribués sont complètement indépendants des aléas de votre serveur, belaran@964: d'autant plus qu'ils répliquent les métadonnées à beaucoup d'endroits. Si belaran@964: votre serveur central prend feu, vous avez intérêt à ce que les médias de belaran@964: sauvegardes soient fiables, et que votre dernier backup soit récent et belaran@964: fonctionne sans problème. Avec un outil distribué, vous avez autant de belaran@964: backup que de contributeurs. belaran@964: belaran@964: belaran@964: En outre, la fiabilité de votre réseau affectera beaucoup moins les belaran@964: outils distribués. Vous ne pouvez même pas utiliser un outil centralisé belaran@964: sans connexion réseau, à l'exception de quelques commandes, très limitées. belaran@964: Avec un outil distribué, si votre connexion réseau tombe pendant que vous belaran@964: travaillez, vous pouvez ne même pas vous en rendre compte. La seule chose belaran@964: que vous ne serez pas capable de faire sera de communiquer avec des dépôts belaran@964: distants, opération somme toute assez rare en comparaison aux opérations belaran@964: locales. Si vous avez une équipe de collaborateurs très dispersée ceci peut belaran@964: être significatif. belaran@964: belaran@964: belaran@964: belaran@964: Avantages pour les projets \textit{Open Source} belaran@964: belaran@964: Si vous prenez goût à un projet \textit{Open Source} et que vous belaran@964: décidez de commencer à toucher à son code, et que le projet utilise belaran@964: un gestionnaire de source distribué, vous êtes immédiatement un "pair" belaran@964: avec les personnes formant le cœur du projet. Si ils publient belaran@964: leurs dépôts, vous pouvez immédiatement copier leurs historiques de belaran@964: projet, faire des modifications, enregistrer votre travail en utilisant belaran@964: les même outils qu'eux. Par comparaison, avec un outil centralisé, vous belaran@964: devez utiliser un logiciel en mode lecture seule à moins que belaran@964: quelqu'un ne vous donne les privilèges de commit sur le serveur belaran@964: central. Avant ça, vous ne serez pas capable d'enregistrer vos belaran@964: modifications, et vos propres modifications risqueront de se belaran@964: corrompre chaque fois que vous essayerez de mettre à jour à votre belaran@964: espace de travail avec le serveur central. belaran@964: belaran@964: belaran@964: belaran@964: Le non-problème du \textit{fork} belaran@964: belaran@964: Il a été souvent suggéré que les gestionnaires de source distribués belaran@964: posent un risque pour les projets \textit{Open Source} car ils belaran@964: facilitent grandement la création de fork\footnote{NdT:Création belaran@964: d'une belaran@964: version alternative du logiciel{http://fr.wikipedia.org/wiki/Fork#Embranchement_d.27un_projet_informatique}.} belaran@964: Un fork apparait quand il y des divergences d'opinion ou d'attitude belaran@964: au sein d'un groupe de développeurs qui aboutissent à la décision de ne belaran@964: plus travailler ensemble. Chaque parti s'empare d'une copie plus ou moins belaran@964: complète du code source du projet et continue dans sa propre direction. belaran@964: belaran@964: belaran@964: Parfois ces différents partis décident de se réconcilier. Avec un belaran@964: serveur central, l'aspect technique de cette réconciliation belaran@964: est un processus douloureux, et essentiellement manuel. Vous devez belaran@964: décider quelle modification est la gagnante, et replacer, par un belaran@964: moyen ou un autre, les modifications de l'autre équipe dans l'arborescence belaran@964: du projet. Ceci implique généralement la perte d'une partie de l'historique belaran@964: d'un des partis, ou même des deux. belaran@964: belaran@964: belaran@964: Ce que les outils distribués permettent à ce sujet est probablement belaran@964: la meilleure façon de développer un projet. Chaque modification belaran@964: que vous effectuez est potentiellement un fork. La grande force de belaran@964: cette approche est que les gestionnaires de source distribués doivent être belaran@964: vraiment très efficaces pour fusionner\footnote{NdT:j'ai choisi de belaran@964: traduire ici \textit{merging} par fusionner pour des raisons de clarté} belaran@964: des forks, car les forks, dans ce contexte, arrivent tout le belaran@964: temps. belaran@964: belaran@964: belaran@964: Si chaque altération que n'importe qui effectue, à tout moment, est vue belaran@964: comme un fork à fusionner, alors ce que le monde de l'\textit{Open belaran@964: Source} voit comme un fork devient uniquement une problématique belaran@964: sociale. En fait, les outils de gestions de source distribués réduisent belaran@964: les chances de fork: belaran@964: belaran@964: belaran@964: Ils éliminent la distinction sociale qu'imposent les outils centralisés belaran@964: entre les membres du projets (ceux qui ont accès au commit) et ceux de belaran@964: l'extérieur (ce qui ne l'ont pas). \item Ils rendent plus facile la belaran@964: réconciliation après un fork social, car belaran@964: tout ce qu'elle implique est une simple fusion. belaran@964: belaran@964: belaran@964: belaran@964: Certaines personnes font de la résistance envers les gestionnaires de source belaran@964: distribués parce qu'ils veulent garder un contrôle ferme sur leur projet, et belaran@964: ils pensent que les outils centralisés leur fournissent ce contrôle. Néanmoins, belaran@964: si c'est votre cas, sachez que si vous publiez votre dépôt CVS ou Subversion belaran@964: de manière publique, il existe une quantité d'outils disponibles pour récupérer belaran@964: entièrement votre projet et son historique (quoique lentement) et le récréer belaran@964: ailleurs, sans votre contrôle. En fait, votre contrôle sur votre projet est belaran@964: illusoire, vous ne faites qu'interdire à vos collaborateurs de travailler belaran@964: de manière fluide, en disposant d'un miroir ou d'un fork de votre belaran@964: historique. belaran@964: %%%TODO: Fussy, those last sentences are not really well translated: belaran@964: %%%no problem for me (wilk) belaran@964: %However, if you're of this belief, and you publish your CVS or Subversion belaran@964: %repositories publically, there are plenty of tools available that can pull belaran@964: %out your entire project's history (albeit slowly) and recreate it somewhere belaran@964: %that you don't control. So while your control in this case is illusory, you are belaran@964: %forgoing the ability to fluidly collaborate with whatever people feel belaran@964: %compelled to mirror and fork your history. belaran@964: belaran@964: belaran@964: belaran@964: belaran@964: belaran@964: Avantages pour les projets commerciaux belaran@964: belaran@964: Beaucoup de projets commerciaux sont réalisés par des équipes éparpillées belaran@964: à travers le globe. Les contributeurs qui sont loin du serveur central belaran@964: devront subir des commandes lentes et même parfois peu fiables. Les belaran@964: solutions propriétaires de gestion de source tentent de palier ce problème belaran@964: avec des réplications de sites distants qui sont à la fois coûteuses à mettre belaran@964: en place et lourdes à administrer. Un système distribué ne souffre pas belaran@964: de ce genre de problèmes. En outre, il est très aisé de mettre en place belaran@964: plusieurs serveurs de références, disons un par site, de manière à ce qu'il belaran@964: n'y ait pas de communication redondante entre les dépôts, sur une connexion belaran@964: longue distance souvent onéreuse. belaran@964: belaran@964: belaran@964: Les systèmes de gestion de source supportent généralement assez mal la belaran@964: montée en charge. Ce n'est pas rare pour un gestionnaire de source centralisé belaran@964: pourtant onéreux de s'effondrer sous la charge combinée d'une douzaine belaran@964: d'utilisateurs concurrents seulement. Une fois encore, la réponse à cette problématique belaran@964: est généralement encore la mise en place d'un ensemble complexe de serveurs belaran@964: synchronisés par un mécanisme de réplication. Dans le cas d'un gestionnaire belaran@964: de source distribué, la charge du serveur central &emdash; si vous avez un&emdash; est belaran@964: plusieurs fois inférieure (car toutes les données sont déjà répliquées ailleurs), belaran@964: un simple serveur, pas très cher, peut gérer les besoins d'une plus grande belaran@964: équipe, et la réplication pour balancer la charge devient le belaran@964: travail d'un simple script. belaran@964: belaran@964: belaran@964: Si vous avez des employés sur le terrain, en train de chercher à résoudre un souci sur belaran@964: le site d'un client, ils bénéficieront aussi d'un gestionnaire de source belaran@964: distribué. Cet outil leur permettra de générer des versions personnalisées, belaran@964: d'essayer différentes solutions, en les isolant aisément les unes des autres, belaran@964: et de rechercher efficacement à travers l'historique des sources, la cause belaran@964: des bugs ou des régressions, tout ceci sans avoir besoin de la moindre belaran@964: connexion au réseau de votre compagnie. belaran@964: belaran@964: belaran@964: belaran@964: belaran@964: belaran@964: Pourquoi choisir Mercurial? belaran@964: belaran@964: Mercurial a plusieurs caractéristiques qui en font un choix particulièrement belaran@964: pertinent pour la gestion de source: belaran@964: belaran@964: belaran@964: \item Il est facile à apprendre et à utiliser ; belaran@964: \item Il est léger et performant ; belaran@964: \item Il monte facilement en charge ; belaran@964: \item Il est facile à personnaliser ; belaran@964: belaran@964: belaran@964: belaran@964: Si vous êtes déjà familier d'un outil de gestion de source, vous serez belaran@964: capable de l'utiliser en moins de 5 minutes. Sinon, ça ne sera pas beaucoup belaran@964: plus long\footnote{NdT: Pour appuyer le propos de l'auteur, je signale que belaran@964: j'utilise Mercurial comme outil d'initiation à la gestion de contrôle dans belaran@964: des travaux pratiques à l'ESME Sudria (http://www.esme.fr) et que les belaran@964: élèves le prennent en main sans difficulté majeure malgré l'approche distribuée.}. belaran@964: Les commandes utilisées par Mercurial, comme ses fonctionnalités, sont belaran@964: généralement uniformes et cohérentes, et vous pouvez donc ainsi garder en tête belaran@964: simplement quelques règles générales, plutôt qu'un lot complexe d'exceptions. belaran@964: belaran@964: belaran@964: Sur un petit projet, vous pouvez commencer à travailler avec Mercurial en belaran@964: quelques instants. Ajouter des modifications ou des branches, transférer belaran@964: ces modifications (localement ou via le réseau), et les opérations belaran@964: d'historique ou de statut sont aussi très rapides. Mercurial reste hors de belaran@964: votre chemin grâce à sa simplicité d'utilisation et sa rapidité d'exécution. belaran@964: belaran@964: belaran@964: L'utilité de Mercurial ne se limite pas à de petits projets: il est belaran@964: aussi utilisé par des projets ayant des centaines ou même des milliers belaran@964: de contributeurs, avec plusieurs dizaines de milliers de fichiers, et des belaran@964: centaines de méga de code source. belaran@964: belaran@964: belaran@964: Voici une liste non exhaustive des projets complexes ou critiques utilisant belaran@964: Mercurial : belaran@964: %TODO belaran@964: % For both spanish and english version, add the following examples: belaran@964: belaran@964: belaran@964: \item Firefox{https://developer.mozilla.org/en/Mozilla_Source_Code_(Mercurial)} ; belaran@964: \item OpenSolaris{http://opensolaris.org/os/community/tools/scm/hg_help/} ; belaran@964: \item OpenJDK{http://hg.openjdk.java.net/} (utilisant en outre l'extension belaran@964: forest pour gérer ses sous modules); belaran@964: belaran@964: belaran@964: belaran@964: Si les fonctionnalités cœur de Mercurial ne sont pas suffisantes pour vous, belaran@964: il est très aisé d'en construire d'autres. Mercurial est adapté à l'utilisation belaran@964: de scripts, et son implémentation interne en Python, propre et claire, belaran@964: rend encore plus facile l'ajout de fonctionnalités sous forme d'extensions. Il belaran@964: en existe déjà un certain nombre de très populaires et très utiles, belaran@964: dont le périmètre va de la recherche de bugs à l'amélioration des performances. belaran@964: belaran@964: belaran@964: belaran@964: belaran@964: Mercurial comparé aux autres outils belaran@964: belaran@964: Avant que vous n'alliez plus loin, comprenez bien que cette section belaran@964: reflète mes propres expériences, et elle est donc (j'ose le dire) belaran@964: peu objective. Néanmoins, j'ai utilisé les outils de gestion de source belaran@964: listés ci dessous, dans la plupart des cas, pendant plusieurs années. belaran@964: %% TODO: Fussy translation. belaran@964: belaran@964: belaran@964: belaran@964: Subversion belaran@964: belaran@964: Subversion est un des outils de gestion de source les plus populaire, il fût belaran@964: développé pour remplacer CVS. Il a une architecture client/server centralisée. belaran@964: belaran@964: belaran@964: Subversion et Mercurial ont des noms de commandes très similaires pour belaran@964: les mêmes opérations, ainsi si vous êtes familier avec l'un, c'est facile belaran@964: d'apprendre l'autre. Ces deux outils sont portables sur les systèmes belaran@964: d'exploitation les plus populaires\footnote{NdT:Mercurial fonctionne sans problème belaran@964: sur OpenVMS à l'ESME Sudria http://www.esme.fr, compte tenu que Subversion a été belaran@964: développé en C, je ne suis pas sûr que son portage aurait été aussi aisé.}. belaran@964: %TODO: Backport this statement in english and spanish belaran@964: belaran@964: belaran@964: Avant la version 1.5, Subversion n'offrait aucune forme de support pour les fusions. Lors belaran@964: de l'écriture de ce livre, ses capacités de fusion étaient nouvelles, et réputées pour être belaran@964: \href{http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword}{complexes belaran@964: et bugguées}. belaran@964: belaran@964: belaran@964: Mercurial dispose d'un avantage substantiel en terme de performance par rapport à belaran@964: Subversion sur la plupart des opérations que j'ai pu tester. J'ai mesuré belaran@964: une différence de performance allant de deux à six fois plus rapide avec belaran@964: le système de stockage de fichier local de Subversion 1.4.3 belaran@964: (ra_local), qui est la méthode d'accès la plus rapide disponible. Dans belaran@964: un déploiement plus réaliste, impliquant un stockage réseau, Subversion belaran@964: serait encore plus désavantagé. Parce que la plupart des commandes Subversion belaran@964: doivent communiquer avec le serveur et que Subversion n'a pas de mécanisme belaran@964: de réplication, la capacité du serveur et la bande passante sont devenues des belaran@964: goulots d'étranglement pour les projets de taille moyenne ou grande. belaran@964: belaran@964: belaran@964: En outre, Subversion implique une surcharge substantielle dans le stockage local belaran@964: de certaines données, pour éviter des transactions avec le serveur, pour belaran@964: certaines opérations communes, telles que la recherche des fichiers modifiés belaran@964: (status) et l'affichage des modifications par rapport à la révision belaran@964: courante (diff). En conséquence, un répertoire de travail Subversion belaran@964: a souvent la même taille, ou est plus grand, qu'un dépôt Mercurial et son belaran@964: espace de travail, et ceci bien que le dépôt Mercurial contienne l'intégralité belaran@964: de l'historique. belaran@964: belaran@964: belaran@964: Subversion est largement supporté par les outils tierces. Mercurial est belaran@964: actuellement encore en retrait de ce point de vue. L'écart se réduit, néanmoins, belaran@964: et en effet certains des outils graphiques sont maintenant supérieurs à leurs belaran@964: équivalents Subversion. Comme Mercurial, Subversion dispose d'un excellent belaran@964: manuel utilisateur. belaran@964: belaran@964: belaran@964: Parce que Subversion ne stocke pas l'historique chez ses clients, il est belaran@964: parfaitement adapté à la gestion de projets qui doivent suivre un ensemble belaran@964: de larges fichiers binaires et opaques. Si vous suivez une cinquantaine de belaran@964: versions d'un fichier incompressible de 10MB, l'occupation disque coté client belaran@964: d'un projet sous Subversion restera à peu près constante. A l'inverse, belaran@964: l'occupation disque du même projet sous n'importe lequel des gestionnaires belaran@964: de source distribués grandira rapidement, proportionnellement aux nombres belaran@964: de versions, car les différences entre chaque révisions seront très grandes. belaran@964: belaran@964: belaran@964: En outre, c'est souvent difficile ou, généralement, impossible de fusionner belaran@964: des différences dans un fichier binaire. La capacité de Subversion de belaran@964: verrouiller des fichiers, pour permettre à l'utilisateur d'être le seul belaran@964: à le mettre à jour (commit) temporairement, est un avantage significatif belaran@964: dans un projet doté de beaucoup de fichiers binaires. belaran@964: belaran@964: belaran@964: Mercurial peut importer l'historique depuis un dépôt Subversion. Il peut belaran@964: aussi exporter l'ensemble des révisions d'un projet vers un dépôt Subversion. belaran@964: Ceci rend très facile de prendre la température et d'utiliser Mercurial et Subversion belaran@964: en parallèle, avant de décider de migrer vers Mercurial. La conversion de belaran@964: l'historique est incrémentale, donc vous pouvez effectuer une conversion belaran@964: initiale, puis de petites additions par la suite pour ajouter les nouvelles belaran@964: modifications. belaran@964: belaran@964: belaran@964: belaran@964: belaran@964: Git belaran@964: belaran@964: Git est un outil de gestion de source distribué qui fût développé pour gérer belaran@964: le code source de noyau de Linux. Comme Mercurial, sa conception initiale a belaran@964: été inspirée par Monotone. belaran@964: belaran@964: belaran@964: Git dispose d'un ensemble conséquent de commandes, avec plus de 139 commandes belaran@964: individuelles pour la version 1.5.0. Il a aussi la réputation d'être difficile belaran@964: à apprendre. Comparé à Git, le point fort de Mercurial est clairement sa belaran@964: simplicité. belaran@964: belaran@964: belaran@964: En terme de performance, Git est extrêmement rapide. Dans la plupart des belaran@964: cas, il est plus rapide que Mercurial, tout du moins sur Linux, alors que belaran@964: Mercurial peut être plus performant sur d'autres opérations. Néanmoins, sur belaran@964: Windows, les performances et le niveau de support général fourni par Git, belaran@964: au moment de l'écriture de cet ouvrage, est bien derrière celui de Mercurial. belaran@964: belaran@964: belaran@964: Alors que le dépôt Mercurial ne demande aucune maintenance, un dépôt Git belaran@964: exige d'exécuter manuellement et régulièrement la commande repacks sur belaran@964: ces métadonnées. Sans ceci, les performances de git se dégradent et la belaran@964: consommation de l'espace disque augmente rapidement. Un serveur qui contient belaran@964: plusieurs dépôts Git qui ne sont pas régulièrement et fréquemment repacked belaran@964: deviendra un vrai problème lors des backups du disque, et il y eu des belaran@964: cas, où un backup journalier pouvait durer plus de 24 heures. Un dépôt belaran@964: fraichement repacked sera légèrement plus petit qu'un dépôt Mercurial, belaran@964: mais un dépôt non repacked est beaucoup plus grand. belaran@964: belaran@964: belaran@964: Le cœur de Git est écrit en C. La plupart des commandes Git sont implémentées belaran@964: sous forme de scripts Shell ou Perl, et la qualité de ces scripts varie belaran@964: grandement. J'ai plusieurs fois constaté que certains de ces scripts étaient belaran@964: chargés en mémoire aveuglément et que la présence d'erreurs pouvait s'avérer belaran@964: fatal. belaran@964: belaran@964: belaran@964: Mercurial peut importer l'historique d'un dépôt Git. belaran@964: belaran@964: belaran@964: belaran@964: belaran@964: CVS belaran@964: belaran@964: CVS est probablement l'outil de gestion de source le plus utilisé aujourd'hui belaran@964: dans le monde. À cause de son manque de clarté interne, il n'est plus belaran@964: maintenu depuis plusieurs années. belaran@964: belaran@964: belaran@964: Il a une architecture client/serveur centralisée. Il ne regroupe pas les belaran@964: modifications de fichiers dans une opération de commit atomique, ce belaran@964: qui permet à ses utilisateurs de casser le \textit{build} assez belaran@964: facilement : une personne peut effectuer une opération de commit belaran@964: sans problème puis être bloquée par besoin de fusion, avec comme conséquence belaran@964: néfaste, que les autres utilisateurs ne récupèreront qu'une partie de ses belaran@964: modifications. Ce problème affecte aussi la manière de travailler avec belaran@964: l'historique du projet. Si vous voulez voir toutes les modifications d'une belaran@964: personne du projet, vous devrez injecter manuellement les descriptions et les belaran@964: \textit{timestamps} des modifications de chacun des fichiers impliqués (si belaran@964: vous savez au moins quels sont ces fichiers). belaran@964: belaran@964: belaran@964: CVS a une notion étrange des \textit{tags} et des branches que je n'essayerai belaran@964: même pas de décrire ici. Il ne supporte pas bien les opérations de renommage d'un belaran@964: fichier ou d'un répertoire, ce qui facilite la corruption de son dépôt. Il n'a belaran@964: presque pas pour ainsi dire de contrôle de cohérence interne, il est donc belaran@964: pratiquement impossible de dire si un dépôt est corrompu ni à quel point. Je belaran@964: ne recommanderai pas CVS pour un projet existant ou nouveau. belaran@964: belaran@964: belaran@964: Mercurial peut importer l'historique d'un projet CVS. Néanmoins, il y a belaran@964: quelques principes à respecter; ce qui est vrai aussi pour les autres belaran@964: outils d'import de projet CVS. À cause de l'absence de commit atomique belaran@964: et gestion de version de l'arborescence, il n'est pas possible de reconstruire belaran@964: de manière précise l'ensemble de l'historique. Un travail de devinette belaran@964: est donc nécessaire, et les fichiers renommés ne sont pas détectés. Parce belaran@964: qu'une bonne part de l'administration d'un dépôt CVS est effectuée manuellement, belaran@964: et est donc, sujette à erreur, il est courant que les imports CVS rencontrent belaran@964: de nombreux problèmes avec les dépôt corrompus (des \textit{timestamps} belaran@964: de révision complètement buggés et des fichiers verrouillés depuis des années belaran@964: sont deux des problèmes les moins intéressants dont je me souvienne). belaran@964: belaran@964: belaran@964: Mercurial peut importer l'historique depuis un dépôt CVS. belaran@964: belaran@964: belaran@964: belaran@964: belaran@964: Outils propriétaires belaran@964: belaran@964: Perforce a une architecture client/serveur centralisée, sans aucun belaran@964: mécanisme de mise en cache de données coté client. Contrairement à la plupart belaran@964: des outils modernes de gestion de source, Perforce exige de ses belaran@964: utilisateurs d'exécuter une commande pour informer le serveur belaran@964: central de tout fichier qu'ils souhaitent modifier. belaran@964: belaran@964: belaran@964: Les performances de Perforce sont plutôt bonnes pour des petites belaran@964: équipes, mais elles s'effondrent rapidement lorsque le nombre belaran@964: d'utilisateurs augmente au delà de la douzaine. Des installations belaran@964: de Perforce assez larges nécessitent le déploiement de proxies pour belaran@964: supporter la montée en charge associée. belaran@964: belaran@964: belaran@964: belaran@964: belaran@964: Choisir un outil de gestion de source belaran@964: belaran@964: A l'exception de CVS, tous les outils listés ci-dessus ont des belaran@964: forces qui leur sont propres et qui correspondent à certaines belaran@964: formes de projet. Il n'y a pas un seul meilleur outil de gestion belaran@964: de source qui correspondrait le mieux à toutes les situations. belaran@964: belaran@964: belaran@964: Par exemple, Subversion est un très bon choix lorsqu'on travaille belaran@964: avec beaucoup de fichiers binaires, qui évoluent régulièrement, grâce belaran@964: à sa nature centralisée et sa capacité à verrouiller des fichiers. belaran@964: belaran@964: belaran@964: Personnellement, je préfère Mercurial pour sa simplicité, ses belaran@964: performances et sa bonne capacité de fusion, et il m'a très bien rendu service belaran@964: de plusieurs années maintenant. belaran@964: belaran@964: belaran@964: belaran@964: belaran@964: belaran@964: Migrer depuis un outil à Mercurial belaran@964: belaran@964: Mercurial est livré avec une extension nommée convert, qui belaran@964: peut de manière incrémentale importer des révisions depuis différents belaran@964: autres outils de gestion de source. Par incrémental, j'entends que belaran@964: vous pouvez convertir l'historique entier du projet en une seule fois, belaran@964: puis relancer l'outil d'import plus tard pour obtenir les modifications belaran@964: effectuées depuis votre import initial. belaran@964: belaran@964: belaran@964: Les outils de gestion de source supportés par convert sont : belaran@964: belaran@964: belaran@964: \item Subversion belaran@964: \item CVS belaran@964: \item Git belaran@964: \item Darcs belaran@964: belaran@964: belaran@964: belaran@964: En outre, convert peut exporter les modifications depuis Mercurial belaran@964: vers Subversion. Ceci rend possible d'essayer Subversion en parallèle belaran@964: avant de choisir une solution définitive, sans aucun risque de perte de belaran@964: données. belaran@964: belaran@964: belaran@964: La commande convert est très simple à utiliser. Simplement, belaran@964: indiquez le chemin ou l'URL du dépôt de source, en lui indiquant éventuellement belaran@964: le nom du chemin de destination, et la conversion se met en route. Après cet belaran@964: import initial, il suffit de relancer la commande encore une fois pour belaran@964: importer les modifications effectuées depuis. belaran@964: belaran@964: belaran@964: belaran@964: belaran@964: belaran@964: