Mercurial: The Definitive Guide

Il y a de nombreuses raisons pour que vous ou votre équipe souhaitiez utiliser un outil automatisant la gestion de révisions pour votre projet.

La plupart de ces raisons ont autant d'importances —du moins en théorie— que vous travailliez seul sur un projet, ou avec une centaine d'autres personnes.

Une question fondamentale à propos des outils de gestion de révisions, qu'il s'agisse du projet d'une personne ou d'une grande équipe, est quels sont ses gains par rapport à ses coûts. Un outil qui est difficile à utiliser ou à comprendre exigera un lourd effort d'adaptation.

Un projet de cinq mille personnes s'effondrera très certainement de lui même sans aucun processus et outil de gestion de révisions. Dans ce cas, le coût d'utilisation d'un logiciel de gestion de révisions est dérisoire puisque sans celui-ci, l'échec est presque garanti.

D'un autre coté, un “rapide hack” d'une personne peut sembler un contexte bien pauvre pour utiliser un outil de gestion de révisions, car, bien évidement le coût d'utilisation dépasse le coût total du projet. N'est-ce pas ?

Mercurial supporte ces deux échelles de travail. Vous pouvez apprendre les bases en quelques minutes seulement, et, grâce à sa performance, vous pouvez l'utiliser avec facilité sur le plus petit des projets. Cette simplicité signifie que vous n'avez pas de concept obscur ou de séquence de commandes défiant l'imagination, sans aucune corrélation avec ce que vous êtes réellement en train de faire. En même temps, ses mêmes performances et sa nature “peer-to-peer” vous permettent d'adapter, sans difficulté, son utilisation à de très grands projets.

Aucun outil de gestion de révisions ne peut sauver un projet mal mené, mais un bon outil peut rendre beaucoup plus fluide votre travail.

La gestion de source est un domaine tellement large qu'il n'existe pas qu'un seul nom ou acronyme pour le désigner. Voici quelques noms ou acronymes que vous rencontrerez le plus souvent.

:

Certaines personnes prétendent que ces termes ont en fait des sens différents mais en pratique ils se recouvrent tellement qu'il n'y a pas réellement de manière pertinente de les distinguer.

Si vous prenez goût à un projet Open Source et que vous décidez de commencer à toucher à son code, et que le projet utilise un gestionnaire de révisions distribué, vous êtes immédiatement un "pair" avec les personnes formant le “cœur” du projet. S'ils publient leurs dépôts, vous pouvez immédiatement copier leurs historiques de projet, faire des modifications, enregistrer votre travail en utilisant les mêmes outils qu'eux. Par comparaison avec un outil centralisé, vous devez utiliser un logiciel en mode “lecture seule” à moins que quelqu'un ne vous donne les privilèges de “commit” sur le serveur central. Avant ça, vous ne serez pas capable d'enregistrer vos modifications, et vos propres modifications risqueront de se corrompre chaque fois que vous essayerez de mettre à jour à votre espace de travail avec le serveur central.

Beaucoup de projets commerciaux sont réalisés par des équipes éparpillées à travers le globe. Les contributeurs qui sont loin du serveur central devront subir des commandes lentes et même parfois peu fiables. Les solutions propriétaires de gestion de révisions tentent de palier ce problème avec des réplications de sites distants qui sont à la fois coûteuses à mettre en place et lourdes à administrer. Un système distribué ne souffre pas de ce genre de problèmes. En outre, il est très aisé de mettre en place plusieurs serveurs de références, disons un par site, de manière à ce qu'il n'y ait pas de communication redondante entre les dépôts, sur une connexion longue distance souvent onéreuse.

Les systèmes de gestion de révisions supportent généralement assez mal la montée en charge. Il n'est pas rare pour un gestionnaire de révisions centralisé pourtant onéreux de s'effondrer sous la charge combinée de quelques dizaines d'utilisateurs concurrents seulement. Une fois encore, la réponse à cette problématique est généralement encore la mise en place d'un ensemble complexe de serveurs synchronisés par un mécanisme de réplication. Dans le cas d'un gestionnaire de révisions distribué, la charge du serveur central — si vous en avez un— est largement inférieure (car toutes les données sont déjà répliquées ailleurs), un simple serveur, peu onéreux, peut gérer les besoins d'une plus grande équipe, et la réplication pour répartir la charge devient le travail d'un simple script.

Si vous avez des employés sur le terrain, en train de chercher à résoudre un souci sur le site d'un client, ils bénéficieront aussi d'un gestionnaire de révisions distribué. Cet outil leur permettra de générer des versions personnalisées, d'essayer différentes solutions, en les isolant aisément les unes des autres, et de rechercher efficacement à travers l'historique des sources, la cause des bugs ou des régressions, tout ceci sans avoir besoin de la moindre connexion au réseau de votre société.

Subversion est un des outils de gestion de révisions les plus populaire, développé pour remplacer CVS. Il a une architecture client/serveur centralisée.

Subversion et Mercurial ont des noms de commandes très similaires pour les mêmes opérations, ainsi si vous êtes familier avec l'un, c'est facile d'apprendre l'autre. Ces deux outils sont portables sur tous les systèmes d'exploitation populaires.

Avant la version 1.5, Subversion n'offrait aucune forme de support pour les fusions. Lors de l'écriture de ce livre, ses capacités de fusion étaient nouvelles, et réputées pour être complexes et buguées.

Mercurial dispose d'un avantage substantiel en terme de performance par rapport à Subversion sur la plupart des opérations que j'ai pu tester. J'ai mesuré une différence de performance allant de deux à six fois plus rapide avec le système de stockage de fichier local de Subversion 1.4.3 (ra_local), qui est la méthode d'accès la plus rapide disponible. Dans un déploiement plus réaliste, impliquant un stockage réseau, Subversion serait encore plus désavantagé. Parce que la plupart des commandes Subversion doivent communiquer avec le serveur et que Subversion n'a pas de mécanisme de réplication, la capacité du serveur et la bande passante sont devenues des goulots d'étranglement pour les projets de taille moyenne ou grande.

En outre, Subversion implique une surcharge substantielle dans le stockage local de certaines données, pour éviter des transactions avec le serveur, pour certaines opérations communes, telles que la recherche des fichiers modifiés (status) et l'affichage des modifications par rapport à la révision courante (diff). En conséquence, un répertoire de travail Subversion a souvent la même taille, ou est plus grand, qu'un dépôt Mercurial et son espace de travail, et ceci bien que le dépôt Mercurial contienne l'intégralité de l'historique.

Subversion est largement supporté par les outils tiers. Mercurial est actuellement encore en retrait de ce point de vue. L'écart se réduit néanmoins, en effet, certains des outils graphiques sont maintenant supérieurs à leurs équivalents Subversion. Comme Mercurial, Subversion dispose d'un excellent manuel utilisateur.

Parce que Subversion ne stocke pas l'historique chez ses clients, il est parfaitement adapté à la gestion de projets qui doivent suivre un ensemble de larges fichiers binaires et opaques. Si vous suivez une cinquantaine de versions d'un fichier incompressible de 10MB, l'occupation disque coté client d'un projet sous Subversion restera à peu près constante. À l'inverse, l'occupation disque du même projet sous n'importe lequel des gestionnaires de révisions distribués grandira rapidement, proportionnellement aux nombres de versions, car les différences entre chaque révision seront très grandes.

En outre, c'est souvent difficile ou, généralement, impossible de fusionner des différences dans un fichier binaire. La capacité de Subversion de verrouiller des fichiers, pour permettre à l'utilisateur d'être le seul à le mettre à jour (“commit”) temporairement, est un avantage significatif dans un projet doté de beaucoup de fichiers binaires.

Mercurial peut importer l'historique depuis un dépôt Subversion. Il peut aussi exporter l'ensemble des révisions d'un projet vers un dépôt Subversion. Ceci rend très facile de “prendre la température” et d'utiliser Mercurial et Subversion en parallèle, avant de décider de migrer vers Mercurial. La conversion de l'historique est incrémentale, donc vous pouvez effectuer une conversion initiale, puis de petites additions par la suite pour ajouter les nouvelle modifications.

Git est un outil de gestion de révisions distribué qui a été développé pour gérer le code source de noyau de Linux. Comme Mercurial, sa conception initiale a été inspirée par Monotone.

Git dispose d'un ensemble conséquent de commandes, avec plus de 139 commandes individuelles pour la version 1.5.0. Il a aussi la réputation d'être difficile à apprendre. Comparé à Git, le point fort de Mercurial est clairement sa simplicité.

En terme de performance, Git est extrêmement rapide. Dans la plupart des cas, il est plus rapide que Mercurial, tout du moins sur Linux, alors que Mercurial peut être plus performant sur d'autres opérations. Néanmoins, sur Windows, les performances et le niveau de support général fourni par Git, au moment de l'écriture de cet ouvrage, est bien derrière celui de Mercurial.

Alors que le dépôt Mercurial ne demande aucune maintenance, un dépôt Git exige d'exécuter manuellement et régulièrement la commande “repacks” sur ses métadonnées. Sans ceci, les performances de git se dégradent et la consommation de l'espace disque augmente rapidement. Un serveur qui contient plusieurs dépôts Git qui ne sont pas régulièrement et fréquemment “repacked” deviendra un vrai problème lors des “backups” du disque, et il y eu des cas, où un “backup” journalier pouvait durer plus de 24 heures. Un dépôt fraichement “repacked” sera légèrement plus petit qu'un dépôt Mercurial, mais un dépôt non “repacked” est beaucoup plus grand.

Le cœur de Git est écrit en C. La plupart des commandes Git sont implémentées sous forme de scripts Shell ou Perl, et la qualité de ces scripts varie grandement. J'ai plusieurs fois constaté que certains de ces scripts étaient chargés en mémoire aveuglément et que la présence d'erreurs pouvait s'avérer fatale.

Mercurial peut importer l'historique d'un dépôt Git.

CVS est probablement l'outil de gestion de révisions le plus utilisé aujourd'hui dans le monde. À cause de son manque de clarté interne, il n'est plus maintenu depuis plusieurs années.

Il a une architecture client/serveur centralisée. Il ne regroupe pas les modifications de fichiers dans une opération de “commit” atomique, ce qui permet à ses utilisateurs de “casser le build” assez facilement : une personne peut effectuer une opération de “commit” sans problème puis être bloquée par besoin de fusion, avec comme conséquence néfaste, que les autres utilisateurs ne récupèreront qu'une partie de ses modifications. Ce problème affecte aussi la manière de travailler avec l'historique du projet. Si vous voulez voir toutes les modifications d'une personne du projet, vous devrez injecter manuellement les descriptions et les timestamps des modifications de chacun des fichiers impliqués (si vous savez au moins quels sont ces fichiers).

CVS a une notion étrange des tags et des branches que je n'essayerai même pas de décrire ici. Il ne supporte pas bien les opérations de renommage d'un fichier ou d'un répertoire, ce qui facilite la corruption de son dépôt. Il n'a presque pas pour ainsi dire de contrôle de cohérence interne, il est donc pratiquement impossible de dire si un dépôt est corrompu ni à quel point. Je ne recommanderai pas CVS pour un projet existant ou nouveau.

Mercurial peut importer l'historique d'un projet CVS. Néanmoins, il y a quelques principes à respecter ; ce qui est vrai aussi pour les autres outils d'import de projet CVS. À cause de l'absence de “commit” atomique et gestion de versions de l'arborescence, il n'est pas possible de reconstruire de manière précise l'ensemble de l'historique. Un travail de “devinette” est donc nécessaire, et les fichiers renommés ne sont pas détectés. Parce qu'une bonne part de l'administration d'un dépôt CVS est effectuée manuellement, et est donc, sujette à erreur, il est courant que les imports CVS rencontrent de nombreux problèmes avec les dépôt corrompus (des timestamps de révision complètement buggés et des fichiers verrouillés depuis des années sont deux des problèmes les moins intéressants dont je me souvienne).

Mercurial peut importer l'historique depuis un dépôt CVS.

Perforce a une architecture client/serveur centralisée, sans aucun mécanisme de mise en cache de données côté client. Contrairement à la plupart des outils modernes de gestion de révisions, Perforce exige de ses utilisateurs d'exécuter une commande pour informer le serveur central de tout fichier qu'ils souhaitent modifier.

Les performances de Perforce sont plutôt bonnes pour des petites équipes, mais elles s'effondrent rapidement lorsque le nombre d'utilisateurs augmente au delà de quelques dizaines. Des installations de Perforce assez larges nécessitent le déploiement de proxies pour supporter la montée en charge associée.

À l'exception de CVS, tous les outils listés ci-dessus ont des forces qui leurs sont propres et qui correspondent à certaines formes de projet. Il n'y a pas un seul meilleur outil de gestion de révisions qui correspondrait le mieux à toutes les situations.

En guise exemple, Subversion est un très bon choix lorsqu'on travaille avec beaucoup de fichiers binaires, qui évoluent régulièrement, grâce à sa nature centralisée et sa capacité à verrouiller des fichiers.

Personnellement, je préfère Mercurial pour sa simplicité, ses performances et sa bonne capacité de fusion, et il m'a très bien rendu service de plusieurs années maintenant.

La meilleure version de Mercurial pour Windows est TortoiseHg, qui peut être téléchargée ici : http://bitbucket.org/tortoisehg/stable/wiki/Home. Ce logiciel n'a aucune dépendance exterieure ; il fonctionne “et c'est tout”. Il fournit aussi bien les outils en ligne de commmande qu'une interface graphique.

Lee Cantey publie un installeur de Mercurial pour Mac OS X sur http://mercurial.berkwood.com.

Parce que chaque distribution de Linux a ses propres outils de gestion de paquets, politiques et rythmes de développements, il est difficile de donner un ensemble d'instructions unique pour installer les binaires de Mercurial. La version de Mercurial avec laquelle vous vous retrouverez dépendra grandement de l'activité de la personne en charge du paquetage pour la distribution.

Pour rester simple, je me concentrerai sur l'installation de Mercurial en ligne de commande, sous les distributions les plus courantes. La plupart des distributions fournissent des gestionnaires graphiques de paquetage qui vous permettront d'installer Mercurial en quelques clicks. Le paquetage devrait se nommer mercurial.

SunFreeWare, à http://www.sunfreeware.com, fournit des paquets précompilés pour Mercurial.

Mercurial fournit un système d'aide intégré, ce qui est inestimable quand vous vous retrouvez coincé à essayer de vous rappeler comment lancer une commande. Si vous êtes bloqué, exécutez simplement hg help ; elle affichera une brève liste des commandes, avec une description pour chacune. Si vous demandez de l'aide sur une commande spécifique (voir ci-dessous), elle affichera des informations plus détaillées.

$ hg help init
hg init [-e CMD] [--remotecmd CMD] [DEST]

create a new repository in the given directory

    Initialize a new repository in the given directory. If the given directory
    does not exist, it will be created.

    If no directory is given, the current directory is used.

    It is possible to specify an "ssh://" URL as the destination. See "hg help
    urls" for more information.

    Returns 0 on success.

options:

 -e --ssh CMD        specify ssh command to use
    --remotecmd CMD  specify hg command to run on the remote side

use "hg -v help init" to show global options

Pour un niveau d'informations encore plus détaillé (ce dont vous aurez rarement besoin), exécutez hg help -v. L'option -v est l'abréviation de --verbose, et indique à Mercurial d'afficher plus d'informations que d'habitude.

Copier un dépôt est juste un peu spécial. Bien que vous puissiez utiliser une commande habituelle de copie pour copier votre dépôt, il vaut mieux utiliser une commande fournie par Mercurial. Cette commande est appelée hg clone, car elle crée une copie identique à un dépôt existant.

$ hg clone http://hg.serpentine.com/tutorial/hello
destination directory: hello
requesting all changes
adding changesets
adding manifests
adding file changes
added 5 changesets with 5 changes to 2 files
updating to branch default
2 files updated, 0 files merged, 0 files removed, 0 files unresolved

Un avantage de la commande hg clone est que, comme nous l'avons vu ci dessus, elle nous permet de cloner les dépôts à travers le réseau. Un autre est qu'elle se rappelle d'où a été cloné un dépôt, ce qui est utile quand on veut mettre à jour le clone.

Si votre opération de clonage réussit, vous devriez maintenant avoir un répertoire local appelé hello. Ce répertoire contiendra quelques fichiers.

$ ls -l
total 0
drwxr-xr-x 3 oracle dba 120 Mar 17 05:09 hello
$ ls hello
Makefile  hello.c

Ces fichiers ont le même contenu et historique dans votre dépôt qu'ils ont dans le dépôt que vous avez cloné.

Chaque dépôt Mercurial est complet, autonome et indépendant. Il contient sa propre copie privée des fichiers du projet et de leur historique. Le clone d'un dépôt se souvient de la localisation du dépôt à partir duquel il a été cloné, mais il ne communique pas avec ce dernier, ou un autre, à moins que vous ne lui demandiez.

Tout ceci signifie pour le moment que nous sommes libres d'expérimenter avec ce dépôt, confiants dans le fait qu'il s'agit d'un “bac à sable” qui n'affectera personne d'autre.

Prêtons plus attention un instant au contenu d'un dépôt. Nous voyons qu'il contient un répertoire nommé .hg . C'est ici que Mercurial conserve toutes ses métadonnées.

$ cd hello
$ ls -a
.  ..  .hg  Makefile  hello.c

Le contenu du répertoire .hg et ses sous-répertoires sont les seuls propres à Mercurial. Tous les autres fichiers et répertoires dans le dépôt sont à vous, et vous pouvez en faire ce que vous voulez.

Pour introduire un peu de terminologie, le répertoire .hg est un “vrai” dépôt, et tous les fichiers et les répertoires qui coexistent avec lui, sont désignés sous le nom espace de travail. Une manière facile de se rappeler cette distinction est de retenir que le dépôt contient l'historique de votre projet, alors que l'espace de travail contient un "snapshot" de votre projet à un certain point de son historique.

Comme l'anglais est réputé pour être un langage maladroit, et que l'informatique est la source de bien des erreurs de terminologie (pourquoi utiliser un seul terme quand quatre feront l'affaire ?), la gestion de révisions a une variété de mots et de phrases qui veulent dire la même chose. Si vous discutez d'historique de Mercurial avec d'autres personnes, vous constaterez que souvent, le mot “changeset” est contracté simplement en “change” ou (à l'écrit) “cset”, et même parfois “révision”, abrégé en “rev”.

Bien que le mot que vous utilisez pour désigner le concept de changeset importe peu, l'identifiant que vous utilisez pour désigner un changeset spécifique a une grande importance. Rappelez vous que le champ “changeset” affiché par la commande hg log identifie un “changeset” à la fois avec un numéro de révision et une séquence hexadécimale.

La distinction est importante. Si vous envoyez un email à quelqu'un en parlant de la “révision 33”, il est très probable que sa “révision 33” ne sera pas la même que la votre. La raison de ceci est que le numéro de révision dépend de l'ordre dans lequel les modifications sont arrivées dans le dépôt, et il n'y a aucune garantie que les mêmes changements soient arrivés dans le même ordre dans différents dépôts. Trois modifications a, b, c peuvent aisément apparaitre dans un dépôt comme 0, 1, 2, et dans un autre comme 0, 2, 1 .

Mercurial utilise les numéros de révision uniquement comme des raccourcis pratiques. Si vous devez discuter d'un “changeset” avec quelqu'un, ou identifer un “changeset” pour une quelconque raison (par exemple, un rapport de “bug”), utilisez la séquence hexadécimale.

Pour réduire la sortie de hg log à une seule révision, utilisez l'option -r (ou --rev). Vous pouvez utiliser le numéro de révision ou la séquence hexadécimale comme identifiant, et demander autant de révisions que vous le souhaitez.

$ hg log -r 3
changeset:   3:0272e0d5a517
user:        Bryan O'Sullivan <bos@serpentine.com>
date:        Sat Aug 16 22:08:02 2008 +0200
summary:     Get make to generate the final binary from a .o file.

$ hg log -r 0272e0d5a517
changeset:   3:0272e0d5a517
user:        Bryan O'Sullivan <bos@serpentine.com>
date:        Sat Aug 16 22:08:02 2008 +0200
summary:     Get make to generate the final binary from a .o file.

$ hg log -r 1 -r 4
changeset:   1:82e55d328c8c
user:        mpm@selenic.com
date:        Fri Aug 26 01:21:28 2005 -0700
summary:     Create a makefile

changeset:   4:2278160e78d4
tag:         tip
user:        Bryan O'Sullivan <bos@serpentine.com>
date:        Sat Aug 16 22:16:53 2008 +0200
summary:     Trim comments.

Si vous voulez voir l'historique de plusieurs révisions sans avoir à les énumérer, vous pouvez utiliser un intervalle de numérotation qui vous permet d'exprimer l'idée “je veux toutes les révisions entre abc et def inclus”.

$ hg log -r 2:4
changeset:   2:fef857204a0c
user:        Bryan O'Sullivan <bos@serpentine.com>
date:        Sat Aug 16 22:05:04 2008 +0200
summary:     Introduce a typo into hello.c.

changeset:   3:0272e0d5a517
user:        Bryan O'Sullivan <bos@serpentine.com>
date:        Sat Aug 16 22:08:02 2008 +0200
summary:     Get make to generate the final binary from a .o file.

changeset:   4:2278160e78d4
tag:         tip
user:        Bryan O'Sullivan <bos@serpentine.com>
date:        Sat Aug 16 22:16:53 2008 +0200
summary:     Trim comments.

Mercurial respecte aussi l'ordre dans lequel vous spécifiez les révisions, ainsi hg log -r 2:4 affichera 2, 3, 4 alors que hg log -r 4:2 affichera 4, 3, 2.

Le résumé affiché par hg log est suffisant si vous savez déjà ce que vous cherchez. En revanche, vous aurez probablement besoin de voir une description complète du changement, ou une liste des fichiers modifiés si vous cherchez à déterminer qu'un “changeset” est bien celui que vous recherchez. L'option -v de la commande hg log (ou --verbose) vous donne ces informations supplémentaires.

$ hg log -v -r 3
changeset:   3:0272e0d5a517
user:        Bryan O'Sullivan <bos@serpentine.com>
date:        Sat Aug 16 22:08:02 2008 +0200
files:       Makefile
description:
Get make to generate the final binary from a .o file.

Si vous voulez voir à la fois la description et le contenu d'une modification, ajoutez l'option -p (ou --patch). Ceci affiche le contenu d'une modification comme un diff unifié (si vous n'avez jamais vu de diff unifié avant, consultez la section Section 12.4, “Understanding patches” pour un rapide survol).

$ hg log -v -p -r 2
changeset:   2:fef857204a0c
user:        Bryan O'Sullivan <bos@serpentine.com>
date:        Sat Aug 16 22:05:04 2008 +0200
files:       hello.c
description:
Introduce a typo into hello.c.


diff -r 82e55d328c8c -r fef857204a0c hello.c
--- a/hello.c	Fri Aug 26 01:21:28 2005 -0700
+++ b/hello.c	Sat Aug 16 22:05:04 2008 +0200
@@ -11,6 +11,6 @@
 
 int main(int argc, char **argv)
 {
-	printf("hello, world!\n");
+	printf("hello, world!\");
 	return 0;
 }

L'option -p est incroyablement utile, il est donc important dans s'en rappeler.

Quand vous exécutez la commande hg commit pour la première fois, il n'est pas garanti qu'elle réussisse du premier coup. En effet, Mercurial enregistre votre nom et votre adresse avec chaque modification que vous effectuez, de manière à ce que vous soyez capable (ou d'autres le soient) de savoir qui a fait telle modification. Mercurial essaye automatiquement de découvrir un nom d'utilisateur qui ait un minimum de sens pour effectuer l'opération de “commit” avec. Il va essayer chacune des méthodes suivantes, dans l'ordre :

Si tous ces mécanismes échouent, Mercurial n'exécutera pas la commande, affichant un message d'erreur. Dans ce cas, il ne vous laissera pas effectuer de “commit” tant que vous n'aurez pas défini un nom d'utilisateur.

Vous devriez penser à utiliser la variable d'environement HGUSER et l'option -u comme moyen pour changer le nom d'utilisateur par défaut. Pour une utilisation normale, la manière la plus simple et robuste d'opérer est de créer un fichier .hgrc, voir ci-dessous pour les détails à ce sujet.

2.7.1.1. Créer un fichier de configuration pour Mercurial

Pour définir un nom d'utilisateur, utilisez votre éditeur de texte favori pour créer un fichier .hgrc dans votre répertoire home. Mercurial va utiliser ce fichier pour retrouver votre configuration personnelle. Le contenu initial devrait ressembler à ceci :

	“Home directory” sous Windows
	Quand on parle de répertoire “home”, sur une version anglaise d'une installation de Windows, il s'agira habituellement d'un répertoire nommée comme votre nom dans C:\Documents and Settings. Vous pouvez trouver de quel répertoire il s'agit en lançant une fenêtre d'interpréteur de commande et en exécutant la commande suivante : C:\ echo %UserProfile

# This is a Mercurial configuration file.
[ui]
username = Firstname Lastname <email.address@domain.net>

La ligne avec [ui] commence une section du fichier de configuration, ainsi la ligne “username = ...” signifie “ définir la valeur de l'élément username dans la section ui”. Une section continue jusqu'à ce qu'une nouvelle commence, ou que la fin du fichier soit atteinte. Mercurial ignore les lignes vides et traite tout texte situé à la suite d'un “#” jusqu'à la fin de la ligne comme un commentaire.

2.7.1.2. Choisir un nom d'utilisateur

Vous pouvez utiliser n'importe quelle valeur pour votre username, car cette information est destinée à d'autres personnes et non à être interprétée par Mercurial. La convention que la plupart des personnes suivent est d'utiliser leur nom suivie de leur adresse email, comme montré ci-dessus :

	Note
	Le mécanisme interne du serveur web intégré à Mercurial, masque les adresses emails, pour rendre plus difficile leurs récupérations par les outils utilisés par les spammmers. Ceci réduit la probabilité que de recevoir encore plus de spam si vous vous publiez un dépôt sur internet.

Lorsqu'on effectue une opération de “commit”, Mercurial lance automatiquement un éditeur de texte pour permettre de saisir un message qui décrira les modifications effectuées dans cette révision. Ce message est nommé le message de commit. Ce sera un enregistrement pour tout lecteur expliquant le pourquoi et le comment de vos modifications, et il sera affiché par la commande hg log.

$ hg commit

L'éditeur que la commande hg commit déclenche ne contiendra qu'une ligne vide suivi d'un certain nombre de lignes commençant par “HG: ”.

    This is where I type my commit comment.
    
    HG: Enter commit message.  Lines beginning with 'HG:' are removed.
    HG: --
    HG: user: Bryan O'Sullivan <bos@serpentine.com>
    HG: branch 'default'
    HG: changed hello.c

Mercurial ignore les lignes qui commencent avec “HG:”, il ne les utilise que pour nous indiquer quels fichiers modifiés il se prépare à “commiter”. Modifier ou effacer ces lignes n'a aucune conséquence sur l'opération de “commit”.

Comme hg log n'affiche que la première ligne du message de “commit” par défaut, il est souvent considéré comme une bonne pratique de rédiger des messages de “commit” qui tiennent sur une seule ligne. Voilà un exemple concret de message de “commit” qui ne suit pas cette directive, et qui a donc un résumé peu lisible.

changeset:   73:584af0e231be
user:        Censored Person <censored.person@example.org>
date:        Tue Sep 26 21:37:07 2006 -0700
summary:     include buildmeister/commondefs.   Add an exports and install
      

À ce sujet, il faut noter qu'il n'existe pas de règle absolue dans ce domaine. Mercurial lui-même n'interprète pas les contenus des messages de “commit”, ainsi votre projet est libre de concevoir différentes politiques de mise en page des messages.

Ma préférence personnelle va au message court, mais informatif, qui offre des précisions supplémentaires par rapport à ce que pourrait m'apprendre une commande hg log --patch.

Si vous exécutez la commande hg commit sans aucun argument, elle enregistre tous les changements qui ont été fait, et qui sont indiqué par les commandes hg status et hg diff.

	Une surprise pour les utilisateurs habitués à Subversion
	Comme n'importe quel autre commande de Mercurial, si vous ne soumettez pas de manière explicite les noms des fichiers à “commiter” à la commande hg commit, elle va travailler sur l'ensemble du répertoire de travail. Soyez conscient de ceci si vous venez du monde Subversion ou CVS, car vous pourriez vous attendre à ce qu'elle opère uniquement sur le répertoire courant et ses sous-répertoires.

Si, en rédigeant le message, vous décidez que finalement vous ne voulez pas effectuer ce “commit”, il suffit de quitter simplement l'éditeur sans sauvegarder. Ceci n'aura aucune conséquence sur le dépôt ou les fichiers du répertoire de travail.

Une fois que votre “commit” est terminé, vous pouvez utiliser la commande hg tip pour afficher le “changeset” que vous venez de créer. Cette commande produit une sortie à l'écran qui est identique à celle du hg log, mais qui n'affiche que la dernière révision du dépôt.

$ hg tip -vp
changeset:   5:ec142fc290c8
tag:         tip
user:        Bryan O'Sullivan <bos@serpentine.com>
date:        Thu Mar 17 05:09:25 2011 +0000
files:       hello.c
description:
Added an extra line of output


diff -r 2278160e78d4 -r ec142fc290c8 hello.c
--- a/hello.c	Sat Aug 16 22:16:53 2008 +0200
+++ b/hello.c	Thu Mar 17 05:09:25 2011 +0000
@@ -8,5 +8,6 @@
 int main(int argc, char **argv)
 {
 	printf("hello, world!\");
+	printf("hello again!\n");
 	return 0;
 }

On fait couramment référence à la dernière révision du dépôt comme étant la révision tip, ou plus simplement le tip.

Au passage, la commande hg tip accepte la plupart des options qu'accepte hg log. Ainsi -v ci-dessus implique “soit verbeux”, -p veut dire “affiche le patch”. L'utilisation de l'option -p pour afficher un patch est un autre exemple de la cohérence des commandes évoquée plus tôt.

Pour commencer, construisons un clone de notre dépôt hello qui ne contiendra pas le changement que nous venons d'effectuer. Nous l'appellerons notre dépôt temporaire hello-pull.

$ cd ..
$ hg clone hello hello-pull
updating to branch default
2 files updated, 0 files merged, 0 files removed, 0 files unresolved

Nous allons utiliser la commande hg pull pour envoyer les modifications depuis my-hello dans hello-pull. Néanmoins, récupérer aveuglement des modifications depuis un dépôt a quelque chose d'un peu effrayant. Mercurial propose donc une commande hg incoming qui permet de savoir quelles modifications la commande hg pull pourrait entraîner dans notre dépôt, et ceci sans effectuer réellement de modification dessus.

$ cd hello-pull
$ hg incoming ../my-hello
comparing with ../my-hello
searching for changes
changeset:   5:ec142fc290c8
tag:         tip
user:        Bryan O'Sullivan <bos@serpentine.com>
date:        Thu Mar 17 05:09:25 2011 +0000
summary:     Added an extra line of output

Apporter les modifications rapatriées dans un dépôt se résume donc à exécuter la commande hg pull, et préciser depuis quel dépôt effectuer le hg pull.

$ hg tip
changeset:   4:2278160e78d4
tag:         tip
user:        Bryan O'Sullivan <bos@serpentine.com>
date:        Sat Aug 16 22:16:53 2008 +0200
summary:     Trim comments.

$ hg pull ../my-hello
pulling from ../my-hello
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
(run 'hg update' to get a working copy)
$ hg tip
changeset:   5:ec142fc290c8
tag:         tip
user:        Bryan O'Sullivan <bos@serpentine.com>
date:        Thu Mar 17 05:09:25 2011 +0000
summary:     Added an extra line of output

Comme vous le voyez avec une sortie avant et après de la commande hg tip, nous avons réussi à récupérer aisément les modifications dans notre dépôt. Il reste néanmoins quelque chose à faire avant de retrouver ces modifications dans l'espace de travail.

Récupérer des changements précis

Il est possible à cause du délai entre l'exécution de la commande hg incoming et l'exécution de la commande hg pull, que vous ne puissiez pas voir toutes les modifications que vous rapporterez d'un autre dépôt. Supposons que vous récupériez les modifications d'un dépôt situé quelque part sur le réseau. Alors que vous regardez le résultat de la commande hg incoming, et avant que vous ne décidiez de récupérer ces modifications, quelqu'un peut ajouter de nouvelles révisions dans le dépôt distant. Ce qui signifie que vous récupérez plus de révisions que ce que vous aviez regardées en utilisant la commande hg incoming. Si vous voulez seulement récupérer ce que vous aviez vérifié à l'aide de la commande hg incoming, ou que pour d'autres raisons vous ne souhaitiez récupérer qu'un sous ensemble des révisions supplémentaires disponibles, indiquez simplement les modifications que vous souhaitez récupérer par leurs ID de révision, soit hg pull -r7e95bb.

Nous avons jusqu'à maintenant grossièrement défini la relation entre un dépôt et un espace de travail. La commande hg pull que nous avons exécutée dans la section Section 2.8.1, “Récupérer les modifications d'autres dépôts” a apporté des modifications, que nous avons vérifiées, dans notre dépôt, mais il n'y a aucune trace de ces modifications dans notre espace de travail. En effet, hg pull ne touche pas (par défaut) à l'espace de travail. C'est la commande hg update qui s'en charge.

$ grep printf hello.c
	printf("hello, world!\");
$ hg update tip
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ grep printf hello.c
	printf("hello, world!\");
	printf("hello again!\n");

Il peut sembler un peu étrange que la commande hg pull ne mette pas à jour l'espace de travail automatiquement. Il y a en fait une très bonne raison à cela : vous pouvez utiliser la commande hg update pour mettre à jour votre espace de travail à l'état dans lequel il était à n'importe quelle révision de l'historique du dépôt. Si vous aviez un espace de travail contenant une ancienne révision—pour chercher l'origine d'un bug, par exemple—et que vous effectuiez un hg pull qui mettrait à jour automatiquement votre espace de travail, vous ne seriez probablement pas très satisfait.

Néanmoins, comme les opérations de pull sont très souvent suivies d'un update, Mercurial vous permet de combiner les deux aisément en passant l'option -u à la commande hg pull.

Si vous étudiez de nouveau la sortie de la commande hg pull dans la section Section 2.8.1, “Récupérer les modifications d'autres dépôts” quand nous l'avons exécutée sans l'option -u, vous pouvez constater qu'elle a affiché un rappel assez utile : vous devez encore effectuer une opération pour mettre à jour votre espace de travail.

Pour découvrir sur quelle révision de l'espace de travail on se trouve, utilisez la commande hg parents.

$ hg parents
changeset:   5:ec142fc290c8
tag:         tip
user:        Bryan O'Sullivan <bos@serpentine.com>
date:        Thu Mar 17 05:09:25 2011 +0000
summary:     Added an extra line of output

Si vous regardez de nouveau le dessin Figure 2.1, “Historique graphique du dépôt hello”, vous verrez les flèches reliant entre elles les révisions. Le nœud d'où la flèche part est dans chaque cas un parent, et le nœud où la flèche arrive est un enfant.

Pour mettre à jour l'espace de travail d'une révision particulière, indiquez un numéro de révision ou un “changeset ID” à la commande hg update.

$ hg update 2
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg parents
changeset:   2:fef857204a0c
user:        Bryan O'Sullivan <bos@serpentine.com>
date:        Sat Aug 16 22:05:04 2008 +0200
summary:     Introduce a typo into hello.c.

$ hg update
2 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg parents
changeset:   5:ec142fc290c8
tag:         tip
user:        Bryan O'Sullivan <bos@serpentine.com>
date:        Thu Mar 17 05:09:25 2011 +0000
summary:     Added an extra line of output

Si vous ne précisez pas de manière explicite de numéro de révision la commande hg update mettra à jour votre espace de travail avec le contenu de la révison “tip”, comme montré dans l'exemple ci-dessus lors du second appel à hg update.

Mercurial vous laisse transférer les modifications vers un autre dépôt, depuis votre dépôt actuel. Comme dans l'exemple du hg pull ci-dessus, nous allons créer un dépôt temporaire vers lequel transférer nos modifications.

$ cd ..
$ hg clone hello hello-push
updating to branch default
2 files updated, 0 files merged, 0 files removed, 0 files unresolved

La commande hg outgoing nous indique quels changements nous allons transférer vers l'autre serveur.

$ cd my-hello
$ hg outgoing ../hello-push
comparing with ../hello-push
searching for changes
changeset:   5:ec142fc290c8
tag:         tip
user:        Bryan O'Sullivan <bos@serpentine.com>
date:        Thu Mar 17 05:09:25 2011 +0000
summary:     Added an extra line of output

Et la commande hg push effectue réellement le transfert.

$ hg push ../hello-push
pushing to ../hello-push
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files

Comme avec hg pull, la commande hg push ne met pas à jour le répertoire de travail du dépôt dans lequel il transfère les modifications. À l'inverse de hg pull, hg push ne fournit pas d'option -u pour forcer la mise à jour de l'espace de travail cible. Cette asymétrie est délibéré : le dépot vers lequel nous transférons peut très bien être un serveur distant et partagé par plusieurs personnes. Si nous devions mettre à jour son répertoire de travail alors que quelqu'un d'autre travaille dessus, nous risquerions de perturber son travail.

Que se passe-t-il lorsque vous essayez de récupérer ou de transférer vos modifications et que le dépôt cible a déjà reçu ces modifications ? Rien de bien excitant.

$ hg push ../hello-push
pushing to ../hello-push
searching for changes
no changes found

Quand nous faisons un clone d'un dépôt, Mercurial enregistre l'emplacement du dépôt d'origine dans le fichier .hg/hgrc de notre nouveau dépôt. Si nous ne fournissons pas d'emplacement à la commande hg pull ou à la commande hg push, ces commandes utiliseront alors cet emplacement comme valeur par défaut. Les commandes hg incoming et hg outgoing feront de même.

Si vous regardez le fichier .hg/hgrc, vous constaterez que son contenu ressemble à ce qui suit.

[paths]
default = http://www.selenic.com/repo/hg

Il est possible—et souvent pratique—d'avoir un emplacement par défaut pour les commandes hg push et hg outgoing différent de celui des commandes hg pull et hg incoming. C'est faisable en ajoutant une entrée default-push à la section [paths] du .hg/hgrc, comme suit.

[paths]
default = http://www.selenic.com/repo/hg
default-push = http://hg.example.com/hg

Les commandes que nous avons étudiées dans les sections précédentes ne sont pas limitées aux dépôts locaux. Chacune fonctionne de la même manière à travers une connexion réseau, il suffit de lui passer une URL à la place d'un chemin de fichier local.

$ hg outgoing http://hg.serpentine.com/tutorial/hello
comparing with http://hg.serpentine.com/tutorial/hello
searching for changes
changeset:   5:ec142fc290c8
tag:         tip
user:        Bryan O'Sullivan <bos@serpentine.com>
date:        Thu Mar 17 05:09:25 2011 +0000
summary:     Added an extra line of output

Dans cet exemple, nous allons voir quels changements nous pourrions transférer vers le dépôt distant, mais le dépôt n'est, de manière tout à fait compréhensible, pas configuré pour accepter des modifications d'utilisateurs anonymes.

$ hg push http://hg.serpentine.com/tutorial/hello
pushing to http://hg.serpentine.com/tutorial/hello
searching for changes
remote: ssl required

Rappelez vous que Mercurial enregistre quelle révision est le parent de chaque révision. Si une révision a un parent, nous l'appelons un enfant “child” ou un descendant de ce parent. Une “head” est une révision qui n'a donc pas d'enfant. La révision “tip” est donc une “head”, car c'est la révision la plus récente du dépôt qui n'a pas d'enfant. Il y a des moments où un dépôt peut contenir plusieurs “heads”.

Figure 3.2. Contenu du dépôt après une récupération (pull) depuis le dépôt my-hello vers le dépôt my-new-hello

Dans la figure Figure 3.2, “Contenu du dépôt après une récupération (pull) depuis le dépôt my-hello vers le dépôt my-new-hello”, vous pouvez constater l'effet d'un “pull” depuis le dépôt my-hello dans le dépôt my-new-hello. L'historique qui était déjà présent dans le dépôt my-new-hello reste intact, mais une nouvelle révision a été ajoutée. En vous reportant à la figure Figure 3.1, “Historique divergeant des dépôts my-hello et my-new-hello.”, vous pouvez voir que l' ID de révision “changeset ID” reste le même dans le nouveau dépôt, mais que le numéro de révision reste le même. (Ceci est un parfait exemple de pourquoi il n'est fiable d'utiliser les numéros de révision lorsque l'on discute d'un “changeset”.) Vous pouvez voir les “heads” présentes dans le dépôt en utilisant la commande hg heads.

$ hg heads
changeset:   6:ec142fc290c8
tag:         tip
parent:      4:2278160e78d4
user:        Bryan O'Sullivan <bos@serpentine.com>
date:        Thu Mar 17 05:09:25 2011 +0000
summary:     Added an extra line of output

changeset:   5:2491baec1ec8
user:        Bryan O'Sullivan <bos@serpentine.com>
date:        Thu Mar 17 05:09:35 2011 +0000
summary:     A new hello for a new day.

Que se passe-t-il quand vous essayez d'utiliser la commande hg update pour mettre à jour votre espace de travail au nouveau “tip” ?

$ hg update
abort: crosses branches (use 'hg merge' or use 'hg update -c')

Mercurial nous prévient que la commande hg update n'effectuera pas la fusion, il ne veut pas mettre à jour l'espace de travail quand il estime que nous pourrions avoir besoin d'une fusion, à moins de lui forcer la main. À la place, il faut utiliser la commande hg merge pour fusionner les deux “heads”.

Pour commencer une fusion (merge) entre deux “heads”, nous utilisons la commande hg merge.

$ hg merge
merging hello.c
0 files updated, 1 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)

Nous résolvons les conflits dans le fichier hello.c. Ceci met à jour le répertoire de travail de sorte qu'il ne contienne les modifications en provenance des deux “heads”, ce qui est indiqué par la la sortie de la commande hg parents et le contenu du fichier hello.c.

$ hg parents
changeset:   5:2491baec1ec8
user:        Bryan O'Sullivan <bos@serpentine.com>
date:        Thu Mar 17 05:09:35 2011 +0000
summary:     A new hello for a new day.

changeset:   6:ec142fc290c8
tag:         tip
parent:      4:2278160e78d4
user:        Bryan O'Sullivan <bos@serpentine.com>
date:        Thu Mar 17 05:09:25 2011 +0000
summary:     Added an extra line of output

$ cat hello.c
/*
 * Placed in the public domain by Bryan O'Sullivan.  This program is
 * not covered by patents in the United States or other countries.
 */

#include <stdio.h>

int main(int argc, char **argv)
{
	printf("once more, hello.\n");
	printf("hello, world!\");
	printf("hello again!\n");
	return 0;
}

Dès l'instant où vous avez effectué une fusion (merge), hg parents vous affichera deux parents, avant que vous n'exécutiez la commande hg commit sur le résultat de la fusion.

$ hg commit -m 'Merged changes'

Nous avons maintenant un nouveau tip, remarquez qu'il contient à la fois nos anciennes “heads” et leurs parents. Ce sont les mêmes révisions que nous avions affichées avec la commande hg parents.

$ hg tip
changeset:   7:3c1554942e80
tag:         tip
parent:      5:2491baec1ec8
parent:      6:ec142fc290c8
user:        Bryan O'Sullivan <bos@serpentine.com>
date:        Thu Mar 17 05:09:36 2011 +0000
summary:     Merged changes

Dans la figure Figure 3.3, “Répertoire de travail et dépôt pendant une fusion, et le “commit” qui suit”, vous pouvez voir une représentation de ce qui se passe dans l'espace de travail pendant la fusion, et comment ceci affecte le dépôt lors du “commit”. Pendant la fusion, l'espace de travail, qui a deux révisions (changesets) comme parents, voit ces derniers devenir le parent d'une nouvelle révision (changeset).

Figure 3.3. Répertoire de travail et dépôt pendant une fusion, et le “commit” qui suit

Mon outil de fusion préféré est kdiff3, que j'utilise ici pour illustrer les fonctionnalités classiques des outils graphiques de fusion. Vous pouvez voir une capture d'écran de l'utilisation de kdiff3 dans la figure Figure 3.5, “Utiliser kdiff3 pour fusionner les différentes version d'un fichier.”. Cet outil effectue une fusion “three-way”, car il y a trois différentes versions du fichier qui nous intéressent. Le fichier découpe la partie supérieure de la fenêtre en trois panneaux :

Dans le panneau en dessous, on trouve le résultat actuel de notre fusion. Notre tâche consiste donc à remplacer tous les textes en rouge, qui indiquent des conflits non résolus, avec une fusion manuelle et pertinente de “notre” version et de la “leur”.

Les quatre panneaux sont accrochés ensemble, si nous déroulons les ascenseurs verticalement ou horizontalement dans chacun d'entre eux, les autres sont mis à jour avec la section correspondante dans leurs fichiers respectifs.

Figure 3.5. Utiliser kdiff3 pour fusionner les différentes version d'un fichier.

Pour chaque portion de fichier posant problème, nous pouvons choisir de résoudre le conflit en utilisant une combinaison de touches depuis la version de base, la nôtre, ou la leur. Nous pouvons aussi éditer manuellement les fichiers à tout moment, si c'est nécessaire.

Il y a beaucoup d'outils de fusion disponibles, bien trop pour parler de tous ici. Leurs disponibilités varient selon les plateformes ainsi que leurs avantages et inconvénients. La plupart sont optimisés pour la fusion de fichier contenant un texte plat, certains sont spécialisés dans un format de fichier précis (généralement XML).

Dans cet exemple, nous allons reproduire la modification de l'historique du fichier de la figure Figure 3.4, “Modifications en conflit dans un document” ci-dessus. Commençons par créer un dépôt avec une version de base de notre document.

$ cat > letter.txt <<EOF
> Greetings!
> I am Mariam Abacha, the wife of former
> Nigerian dictator Sani Abacha.
> EOF
$ hg add letter.txt
$ hg commit -m '419 scam, first draft'

Créons un clone de ce dépôt et effectuons une modification dans le fichier.

$ cd ..
$ hg clone scam scam-cousin
updating to branch default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd scam-cousin
$ cat > letter.txt <<EOF
> Greetings!
> I am Shehu Musa Abacha, cousin to the former
> Nigerian dictator Sani Abacha.
> EOF
$ hg commit -m '419 scam, with cousin'

Et un autre clone, pour simuler que quelqu'un d'autre effectue une modification sur le fichier. (Ceci pour suggérer qu'il n'est pas rare de devoir effectuer des fusions (merges) avec vos propres travaux quand vous isolez les tâches dans des dépôts distincts. En effet, vous aurez alors à trouver et résoudre certains conflits).

$ cd ..
$ hg clone scam scam-son
updating to branch default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd scam-son
$ cat > letter.txt <<EOF
> Greetings!
> I am Alhaji Abba Abacha, son of the former
> Nigerian dictator Sani Abacha.
> EOF
$ hg commit -m '419 scam, with son'

Maintenant que ces deux versions différentes du même fichier sont créées, nous allons configurer l'environnement de manière appropriée pour exécuter notre fusion (merge).

$ cd ..
$ hg clone scam-cousin scam-merge
updating to branch default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd scam-merge
$ hg pull -u ../scam-son
pulling from ../scam-son
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files (+1 heads)
not updating, since new heads added
(run 'hg heads' to see heads, 'hg merge' to merge)

Dans cette exemple, je n'utiliserais pas la commande Mercurial habituelle hgmerge pour effectuer la fusion (merge), car il me faudrait abandonner ce joli petit exemple automatisé pour utiliser un outil graphique. À la place, je vais définir la variable d'environnement HGMERGE pour indiquer à Mercurial d'utiliser la commande non-interactive merge. Cette dernière est comprise dans de nombreux systèmes “à la Unix”. Si vous exécutez cet exemple depuis votre ordinateur, ne vous occupez pas de définir HGMERGE.

$ export HGMERGE=merge
$ hg merge
merging letter.txt
merge: warning: conflicts during merge
merging letter.txt failed!
0 files updated, 0 files merged, 0 files removed, 1 files unresolved
use 'hg resolve' to retry unresolved file merges or 'hg update -C' to abandon
$ cat letter.txt
Greetings!
<<<<<<< /tmp/tour-merge-conflictJzT4po/scam-merge/letter.txt
I am Shehu Musa Abacha, cousin to the former
=======
I am Alhaji Abba Abacha, son of the former
>>>>>>> /tmp/letter.txt~other.LnSKVz
Nigerian dictator Sani Abacha.

Parce que merge ne peut pas résoudre les modifications conflictuelles, il laisse des marqueurs de différences à l'intérieur du fichier qui a des conflits, indiquant clairement quelles lignes sont en conflit, et si elles viennent de notre fichier ou du fichier externe.

Mercurial peut distinguer, à la manière dont la commande merge se termine, qu'elle n'a pas été capable d'effectuer la fusion (merge), alors il nous indique que nous devons effectuer de nouveau cette opération. Ceci peut être très utile si, par exemple, nous exécutons un outil graphique de fusion et que nous le quittons sans nous rendre compte qu'il reste des conflits ou simplement par erreur.

Si la fusion (merge) automatique ou manuelle échoue, il n'y a rien pour nous empêcher de “corriger le tir” en modifiant nous-même les fichiers, et enfin effectuer le “commit” du fichier:

$ cat > letter.txt <<EOF
> Greetings!
> I am Bryan O'Sullivan, no relation of the former
> Nigerian dictator Sani Abacha.
> EOF
$ hg resolve -m letter.txt
$ hg commit -m 'Send me your money'
$ hg tip
changeset:   3:2eb6858f32d9
tag:         tip
parent:      1:3136513772a5
parent:      2:7d96870fc99d
user:        Bryan O'Sullivan <bos@serpentine.com>
date:        Thu Mar 17 05:09:37 2011 +0000
summary:     Send me your money

Où est la commande hg resolve ?

La commande hg resolve a été introduite dans la version 1.1 de Mercurial, qui a été publiée en décembre 2008. Si vous utilisez une version plus anciennne de Mercurial (exécutez la command hg version pour en avoir le cœur net), cette commande ne sera pas disponible. Si votre version de Mercurial est plus ancienne que la 1.1, vous devriez très fortement considérer une mise à jour vers une version plus récente avant d'essayer de régler des fusions complexes.

Lorsque Mercurial effectue un suivi des modifications faites à un fichier, il conserve l'historique pour ce fichier dans un filelog sous forme de métadonnées. Chaque entrée dans le “filelog” contient assez d'informations pour reconstituer une révision du fichier correspondant. Les “filelogs” sont des fichiers stockés dans le répertoire .hg/store/data. Un “filelog” contient des informations de deux types : les données de révision, et un index pour permettre à Mercurial une recherche efficace d'une révision donnée.

Lorsqu'un fichier devient trop gros ou a un long historique, son “filelog” se voit stocké dans un fichier de données (avec un suffixe “.d”) et un fichier index (avec un suffixe“.i”) distincts. La relation entre un fichier dans le répertoire de travail et le “filelog” couvrant le suivi de son historique dans le dépôt est illustré à la figure Figure 4.1, “Relations entre les fichiers dans le répertoire de travail et leurs “filelogs” dans le dépôt”.

Figure 4.1. Relations entre les fichiers dans le répertoire de travail et leurs “filelogs” dans le dépôt

Mercurial a recours à une structure nommée manifest pour rassembler les informations sur les fichiers dont il gère le suivi. Chaque entrée dans ce “manifest” contient des informations sur les fichiers présents dans une révision donnée. Une entrée enregistre la liste des fichiers faisant partie de la révision, la version de chaque fichier, et quelques autres métadonnées sur ces fichiers.

Le changelog contient les informations sur chaque “changeset”. Chaque révision enregistre qui a “committé” un changement, le commentaire du “changeset”, d'autres morceaux d'information relatives au “changeset” et la révision du “manifest” à utiliser.

À l'intérieur d'un “changelog”, d'un “manifest”, ou d'un “filelog”, chaque révision enregistre un pointeur vers son parent immédiat (ou à ses deux parents s'il s'agit d'une révision correspondant à une fusion (merge)). Comme mentionné plus haut, il y a aussi des relations entre les révisions à travers ces structures, qui sont de nature hiérarchique.

Pour chaque “changeset” dans un dépôt, il y a exactement une révision stockée dans le “changelog”. Chaque révision du “changelog” contient un pointeur vers une unique révision du “manifest”. Une révision du “manifest” garde un pointeur vers une unique révision pour chaque “filelog” suivi lorsque le “changeset” est créé. Ces relations sont illustrées dans Figure 4.2, “Metadata relationships”.

Figure 4.2. Metadata relationships

Comme l'illustration le montre, il n'y a pas de relation “un à un” entre les révisions dans un “changelog”, “manifest” ou “filelog”. Si un fichier que Mercurial suit n'a pas changé entre deux “changesets”, l'entrée pour ce fichier dans les deux révisions du “manifest” pointera vers la même révision de son “filelog” ^[3].

Le “revlog” fournit un stockage efficace des révisions en utilisant un mécanisme delta. Au lieu de stocker une copie complète d'un fichier à chaque révision, il stocke les changements requis pour transformer une révision plus ancienne en une nouvelle révision. Pour plusieurs types de données, ces deltas sont typiquement une fraction de pourcentage de la taille de la copie complète d'un fichier.

Certains systèmes de gestion de révisions obsolètes peuvent seulement travailler avec les deltas de fichiers texte. Il doivent d'ailleurs stocker les fichiers binaires comme des images complètes ou encodées avec une représentation texte, chacune de ces approches étant gaspilleuse. Mercurial peut traiter les deltas de fichiers avec du contenu binaire arbitraire ; il n'a pas besoin de traiter spécialement du texte.

Mercurial empile toujours les données à la fin d'un fichier “revlog”. Il ne modifie jamais la section d'un fichier après qu'il l'ait écrite. C'est à la fois plus robuste et efficace que les schémas qui ont besoin de modifier ou réécrire les données.

De plus, Mercurial traite chaque écriture comme la partie d'une transaction qui peut comprendre plusieurs fichiers. Une transaction est atomique : soit la transaction entière réussit et ses effets sont tous visibles aux lecteurs en une étape, soit la totalité est annulée. Cette garantie de l'atomicité signifie que si vous exécutez deux copies de Mercurial, où une lit les données et l'autre les écrit, le lecteur ne verra jamais un résultat partiellement écrit qui pourrait le perturber.

Le fait que Mercurial ne fasse qu'ajouter aux fichiers fait qu'il est facile de fournir cette garantie de transaction. Plus les choses sont faites simplement comme ça, plus vous pouvez être rassurés qu'elles sont bien faites.

Mercurial évite habillement un piège commun à tous les vieux systèmes de gestion de révisions : le problème de la récupération inefficace. La plupart des systèmes de gestion de révisions stockent le contenu d'une révision comme une série incrémentale de modifications faites à un “snapshot”. (Certains basent le “snapshot” sur la plus vieille révision, d'autres sur la plus récente.) Pour reconstruire une révision spécifique, vous devez d'abord lire le “snapshot”, et ensuite toutes les révisions entre le “snapshot” et votre révision cible. Plus vous avez d'historique accumulé dans un fichier, plus de révisions vous avez à lire, d'où la longueur que cela prend à reconstruire une révision particulière.

Figure 4.3. “Snapshot” d'un “revlog”, avec des deltas incrémentaux

L'innovation que Mercurial apporte à ce problème est simple mais efficace. Une fois que la quantité cumulée de deltas d'informations stockées depuis le dernier snapshot excède un seuil fixé, il stocke un nouveau “snapshot” (compressé bien sûr), plutôt qu'un nouveau delta. Ceci rend possible la reconstruction de toute révision d'un fichier rapidement. Cette approche fonctionne si bien que depuis, elle a été copiée par plusieurs autres systèmes de gestion de révisions.

Figure 4.3, ““Snapshot” d'un “revlog”, avec des deltas incrémentaux” illustre l'idée. Dans une entrée d'un fichier d'index de “revlog”, Mercurial stocke l'intervalle des entrées depuis le fichier de données qu'il doit lire pour reconstruire une révision particulière.

Avec les deltas ou l'information du snapshot, une entrée d'un revlog contient un hash cryptographique des données qu'il représente. Ceci fait qu'il est difficile de construire les données d'une révision, mais facile de détecter une corruption accidentelle.

Les hash fournissent plus qu'un bon moyen de vérification contre la corruption ; il sont aussi utilisés comme identifiants pour les révisions. Les “hashs” d'identifications d'un “changeset” que vous voyez comme utilisateur final proviennent des révisions du “changelog”. Bien que les “filelogs” et le “manifest” utilisent aussi des “hashs”, Mercurial ne les utilise qu'en arrière-plan.

Mercurial vérifie que les “hashs” sont corrects lorsqu'il récupère les révisions de fichiers et lorsqu'il récupère (pull) les changements d'un autre dépôt. S'il rencontre un problème d'intégrité, il se plaindra et arrêtera tout ce qu'il est en train de faire.

En plus de l'effet qu'il a sur l'efficacité des récupérations, l'utilisation par Mercurial de “snapshots” périodiques fait qu'il est plus robuste contre la corruption partielle de données. Si un “revlog” devient partiellement corrompu à cause d'une erreur matérielle ou d'un bug système, il est souvent possible de reconstruire certaines ou la plupart des révisions à partir des sections non corrompues du “revlog”, avant et après la section corrompue. Ceci ne serait pas possible à partir d'un modèle de stockage de deltas seul.

Le “dirstate” stocke les informations sur les parents pour plus qu'une simple comptabilité. Mercurial utilise les parents du “dirstate” comme les parents d'un nouveau “changeset” lorsque vous “committez”.

Figure 4.5. Le répertoire de travail peut avoir deux parents

Figure 4.5, “Le répertoire de travail peut avoir deux parents” montre l'état normal d'un répertoire de travail, où il n'y a qu'un seul “changeset” comme parent. Ce “changeset” est le tip, le “changeset” le plus récent dans le dépôt n'a pas d'enfant.

Figure 4.6. Le répertoire de travail gagne de nouveaux parents après un “commit”

On peut se représenter le répertoire de travail comme “le changeset que je vais committer”. Chaque fichier que vous demandez à Mercurial d'ajouter, de supprimer, de renommer ou de copier va être intégré dans ce changeset, tout comme les modifications de n'importe quel fichier que Mercurial est déjà en train de suivre ; le nouveau “changeset” aura les mêmes parents que le répertoire de travail.

Après un commit, Mercurial va mettre à jour les parents du répertoire de travail, ainsi, le premier parent est l'ID du nouveau “changeset”, et le second, le “null ID”. Ceci est illustré dans Figure 4.6, “Le répertoire de travail gagne de nouveaux parents après un “commit””. Mercurial ne touche à aucun des fichiers du répertoire de travail lorsque vous “committez” ; il modifie simplement le dirstate pour noter ses nouveaux parents.

Il est parfaitement normal de faire un “update” du répertoire de travail à un “changeset” autre que le “tip” courant. Par exemple, vous pourriez vouloir savoir à quoi votre projet ressemblait mardi dernier, ou regarder le “changeset” qui a introduit un bug. Dans des cas comme ça, la chose naturelle à faire est de faire un “update” du répertoire de travail au “changeset” qui vous intéresse, et ensuite d'en examiner les fichiers pour regarder leurs contenus comme ils l'étaient lorsque vous avez “committé” ce “changeset”. L'effet de ceci est montré dans Figure 4.7, “Le répertoire de travail, “updaté” pour un “changeset” plus ancien”.

Figure 4.7. Le répertoire de travail, “updaté” pour un “changeset” plus ancien

En ayant fait un “update” du répertoire de travail vers un “changeset” plus ancien, que se passe-t-il si vous faites des changements et ensuite “committez” ? Mercurial se comporte comme je l'ai fait remarqué plus haut. Les parents du répertoire de travail deviennent les parents du nouveau “changeset”. Ce nouveau “changeset” n'a pas d'enfant, donc il devient le nouveau “tip”. Le dépôt contient maintenant deux “changesets” qui n'ont pas d'enfant ; on appelle ceci des heads. Vous pouvez voir la structure que cela crée dans Figure 4.8, “Après un “commit” fait pendant la synchronisation avec un ancien “changeset””.

Figure 4.8. Après un “commit” fait pendant la synchronisation avec un ancien “changeset”

Note

Si vous êtes un nouvel utilisateur de Mercurial, vous devez garder à l'esprit une “erreur” commune, qui est d'utiliser la commande hg pull sans aucune option. Par défaut, la commande hg pull ne fait pas d'“update” sur le répertoire de travail, ainsi, vous allez récupérer les nouveaux changesets dans votre dépôt, mais le répertoire de travail va rester synchronisé au même “changeset” qu'il l'était avant le “pull”. Si vous faites des changements et “committez” ensuite, vous allez créer une nouvelle “head” puisque votre répertoire de travail n'est pas synchronisé au “tip” actuel. Pour combiner les opérations d'un “pull” suivi d'un “update”, exécutez hg pull -u. Je place le mot “erreur” entre guillemets parce que tout ce dont vous avez besoin de faire pour rectifier la situation où vous avez créé une nouvelle “head” par accident est un hg merge suivi d'un hg commit. En d'autres mots, ceci n'a presque jamais de conséquences négatives ; il s'agit juste d'une surprise pour les nouveaux arrivants. Je discuterai d'autres moyens d'éviter ce comportement, et pourquoi Mercurial agit de cette façon surprenante plus tard.

Lorsque vous exécutez la commande hg merge, Mercurial laisse le premier parent du répertoire de travail inchangé et fixe le second au “changeset” avec lequel vous fusionnez (merge), comme montré dans Figure 4.9, “Fusionner (merge) deux “heads””.

Figure 4.9. Fusionner (merge) deux “heads”

Mercurial doit aussi modifier le répertoire de travail pour fusionner les fichiers gérés dans les deux “changesets”. Un peu simplifié, le processus de fusion fonctionne comme ça : pour chaque fichier dans le “manifest” de chaque “changeset”.

Il y a plus de détails—fusionner a beaucoup de cas épineux—mais ceux-ci sont des choix plus communs qui sont liés à une fusion (merge). Comme vous pouvez le voir, la plupart des cas sont entièrement automatiques, et effectivement, la plupart des fusions (merge) se terminent automatiquement, sans nécessiter votre intervention pour résoudre un conflit.

Lorsque vous pensez à ce qu'il se passe lorsque vous “committez” après un “merge”, une fois encore, le répertoire de travail est “le changeset que je suis sur le point de committer”. Après que la commande hg merge soit terminée, le répertoire de travail a deux parents ; ceux ci vont devenir les parents du nouveau “changeset”.

Mercurial vous permet d'exécuter de multiples fusions, mais vous devez “committer” le résultat de chaque fusion individuellement au fur et à mesure. Ceci est nécessaire puisque Mercurial ne stocke que deux parents pour chaque révision et le répertoire de travail. Alors qu'il serait techniquement faisable de fusionner de multiples “changesets” en même temps, Mercurial interdit cela pour être plus simple. Avec des fusions multiples, les risques de confusion pour l'utilisateur, de mauvaie résolution de conflits, et de pagaille dans les fusions augmenteraient de façon intolérable.

Un nombre surprenant de systèmes de gestion de révisions fait peu ou pas attention à un nom de fichier au cours du temps. Par exemple, il était habituel que si un fichier était renommé d'un coté de la fusion, les changements à partir de l'autre coté étaient supprimés silencieusement.

Mercurial enregistre les metadata lorsque vous lui dites d'exécuter un renommage ou une copie. Il utilise ces metadatas durant une fusion pour faire les bonnes choses dans le cas d'un “merge”. Par exemple, si je renomme un fichier et que vous l'éditez sans le renommer, lorsque l'on fusionne, le fichier sera renommé et aura les changements appliqués.

Lorsque cela est approprié, Mercurial stocke les “snapshots” et deltas sous une forme compressée. Il le fait en essayant toujours de compresser un “snapshot” ou un delta, mais en ne stockant la version compressée que si celle-ci est plus petite que la version non compressée.

Ceci signifie que Mercurial fait “la bonne chose” lorsqu'il stocke un fichier dont la forme native est compressée, comme une archive zip ou une image JPEG. Lorsque ces types de fichiers sont compressés une seconde fois, le fichier obtenu est habituellement plus gros que la forme compressée une seule fois et Mercurial stockera alors le zip ou JPEG.

Les deltas entre les révisions d'un fichier compressé sont habituellement plus gros que les snapshots du fichier, et Mercurial fait à nouveau “la bonne chose” dans ces cas. Il trouve qu'un delta dépasse le seuil auquel il devrait stocker un “snapshot” complet du fichier, alors il stocke le “snapshot”, en gagnant encore de la place en comparaison d'une approche naïve avec un delta seulement.

[ui]
ssh = ssh -C

L'histoire ne se résume pas à ajouter à la fin des fichiers lorsque l'on cherche à garantir que le lecteur ne verra pas qu'une écriture partielle. Si vous relisez Figure 4.2, “Metadata relationships”, les révisions dans le “changelog” pointent vers les révisions dans le “manifest”, et les révisions du “manifest” pointent vers les révisions du “filelog”. Cette hiérarchie est délibérée.

L'écriture commence par une transaction en écrivant dans le “filelog” et dans les données du “manifest”, et n'écrit aucune donnée du “changelog” tant que ce n'est pas terminé. La lecture commence en lisant les données du “changelog”, puis les données du “manifest”, et enfin les données du “filelog”.

Puisque que l'écriture ne finit pas d'écrire les données du “filelog” et du “manifest” avant d'écrire dans le “changelog”, la lecture ne verra jamais un pointeur vers une révision du “manifest” partiellement écrite à partir du “changelog”, et ne lira jamais un pointeur vers une révision du “filelog” partiellement écrite dans le “manifest”.

La garantie de l'ordre de lecture/écriture et de l'atomicité signifie que Mercurial n'a jamais besoin de poser de lock sur un dépôt lorsqu'il lit des données, même si le dépôt est en train d'être écrit au même moment que la lecture a lieu. Ceci a un grand impact sur la fiabilité ; vous pouvez avoir un nombre arbitraire de processus Mercurial qui lisent sans risque les données d'un dépôt en même temps, peu importe s'il est en train d'être lu ou non.

La nature sans “lock” de la lecture signifie que si vous partagez un dépôt sur un système multi-utilisateurs, vous n'avez pas besoin de donner aux autres utilisateurs locaux la permission d'écrire sur votre dépôt pour qu'ils soient capable de faire un clone ou un “pull” des changements à partir de celui-ci ; ils ont seulement besoin de la permission en lecture. (Il ne s'agit pas d'une fonctionnalité commune à travers les systèmes de gestion de révisions, donc ne prenez pas ça pour argent comptant ! La plupart ont besoin que les lecteurs soient capables de mettre un lock sur le dépôt pour y accéder en toute sécurité, et ceci demande des permissions en écriture, sur au moins un répertoire, ce qui provoque bien sûr toutes sortes de problèmes pénibles et agaçants relatifs à la sécurité et à l'administration.)

Mercurial utilise des “locks” pour assurer qu'un seul processus peut écrire dans le dépôt à un moment donné (le mécanisme de “lock” est sûr, même sur des systèmes de fichiers qui sont connus pour être hostiles aux “locks”, comme NFS). Si un dépôt dispose d'un “lock”, un processus qui cherche à écrire va attendre un peu avant de retenter pour voir si le dépôt perd son “lock”, mais si le dépôt garde trop longtemps son “lock”, le processus qui tente d'écrire va expirer (time out) après un moment. Cela veut dire par exemple que vos scripts lancés quotidiennement n'attendront pas toujours et boucleront si un système plantait sans avertissement, par exemple. (Oui, le timeout est configurable, de zéro à l'infini.)

L'absence de recherche sur les têtes de disques est critique pour la performance de Mercurial, puisque toute recherche est beaucoup plus coûteuse comparativement à une grosse opération de lecture.

C'est pour ça, par exemple, que le “dirstate” est stocké dans un fichier unique. S'il y avait eu un “dirstate” par répertoire que Mercurial suivrait, le disque aurait recherché une fois par répertoire. Au lieu de ça, Mercurial lit entièrement un fichier unique, en une étape.

Mercurial utilise aussi un schéma “copie à l'écriture” lorsqu'il clone un dépôt sur un stockage local. Au lieu de copier chaque “fichier” revlog depuis l'ancien dépôt vers le nouveau dépôt, il crée un “lien physique”, qui est le plus court chemin pour dire “Ces deux noms pointent vers le même fichier”. Lorsque Mercurial est sur le point d'écrire sur l'un des revlogs de ces fichiers, il vérifie si le nombre de noms pointant sur ce fichier est plus grand que un. Si c'est le cas, plus d'un dépôt utilise le fichier, donc Mercurial crée une nouvelle copie du fichier qui est privée à ce dépôt.

Quelques développeurs de systèmes de gestion de révisions ont montré que cette idée de faire une copie privée complète d'un fichier n'est pas vraiment efficace au niveau du stockage. Bien que ce soit vrai, le stockage est peu onéreux, et cette méthode donne la plus grande performance lorsque l'on reporte la plupart des journalisations au système d'exploitation. Un schéma alternatif réduirait certainement la performance tout en augmentant la complexité du logiciel, mais la vitesse et la simplicité sont les clefs du “confort” de l'utilisation quotidienne.

Puisque Mercurial ne vous force pas à signaler que vous modifiez un fichier, il utilise le “dirstate” pour stocker certaines informations supplémentaires pour déterminer efficacement si vous avez ou non modifié un fichier. Pour chaque fichier du répertoire de travail, il stocke l'heure à laquelle il a été modifié, ainsi que la taille du fichier à cette heure.

Lorsque vous faites explicitement un hg add, hg remove, hg rename ou hg copy sur des fichiers, Mercurial met à jour le “dirstate” afin de savoir que faire lorsque vous effectuez un “commit”.

Le “dirstate” aide Mercurial à vérifier efficacement le statut des fichiers dans un dépôt.

Enregistrer la date de modification et la taille réduit grandement le nombre d'opérations de lecture que Mercurial doit effectuer lorsque l'on utilise une commande comme hg status. Le résultat est un grand gain de performance.

Un comportement utile que Mercurial possède est que si vous passez le nom d'un répertoire à une commande, toute commande Mercurial la traitera comme : “Je veux opérer sur chaque fichier dans ce répertoire et ses sous-répertoires”.

$ mkdir b
$ echo b > b/somefile.txt
$ echo c > b/source.cpp
$ mkdir b/d
$ echo d > b/d/test.h
$ hg add b
adding b/d/test.h
adding b/somefile.txt
adding b/source.cpp
$ hg commit -m 'Added all files in subdirectory'

Remarquez que dans cet exemple, Mercurial affiche le nom des fichiers qu'il a ajouté, alors qu'il ne l'a pas fait lorsque nous avons ajouté le fichier nommé myfile.txt dans l'exemple précédent.

Ce qu'il se passe est que dans le premier cas, nous avons nommé explicitement le fichier à ajouter sur la ligne de commande. Ce que Mercurial suppose dans ce cas est que nous savons ce que nous faisons, il n'affiche donc rien en sortie.

Cependant, lorsque nous avons implicitement donné les fichiers à l'aide du nom d'un répertoire, Mercurial prend l'initiative d'afficher le nom de chaque fichier avec lequel il fait quelque chose. Ceci clarifie ce qu'il se passe et réduit la probabilité d'une mauvaise surprise restée silencieuse. Ce comportement est commun à la plupart des commandes Mercurial.

Mercurial ne suit pas les informations sur les répertoires. En contrepartie, il suit le chemin vers un fichier. Avant de créer un fichier, il crée au préalable les répertoires manquants dans le chemin. Après avoir supprimé un fichier, il supprime chaque répertoire vide qui apparaît dans le chemin du fichier. Ceci apparaît comme une distinction triviale, cependant, cela a une conséquence pratique mineure : il n'est pas possible de représenter un répertoire totalement vide dans Mercurial.

Les répertoires vides sont rarement utiles. Il existe cependant des solutions alternatives et non intrusives que vous pouvez utiliser pour obtenir l'effet approprié. Les développeurs de Mercurial ont ainsi pensé que la complexité requise pour gérer les répertoires n'était pas aussi importante que le bénéfice que cette fonctionnalité apporterait.

Si vous avez besoin d'un répertoire vide dans votre dépôt, il existe quelques façons d'y arriver. L'une d'elles est de créer un répertoire et ensuite, de faire un hg add sur un fichier “caché” dans ce répertoire. Sur les systèmes de type Unix, tout fichier dont le nom commence avec un point (“.”) est considéré comme caché par la plupart des commandes et outils graphiques. Cette approche est illustrée ci-après.

$ hg init hidden-example
$ cd hidden-example
$ mkdir empty
$ touch empty/.hidden
$ hg add empty/.hidden
$ hg commit -m 'Manage an empty-looking directory'
$ ls empty
$ cd ..
$ hg clone hidden-example tmp
updating to branch default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ ls tmp
empty
$ ls tmp/empty

Une autre façon de s'attaquer au besoin d'un répertoire vide est de simplement d'en créer un dans vos scripts de construction avant qu'ils n'en aient le besoin.

Il est important de comprendre que supprimer un fichier n'a que deux effets.

Supprimer un fichier n'affecte en aucun cas l'historique du fichier.

Si vous mettez à jour le répertoire de travail à un changeset qui a été committé alors que le fichier que vous venez de supprimer était encore suivi, ce fichier réapparaîtra dans le répertoire de travail, avec le contenu qu'il avait lorsque vous aviez committé ce changeset. Si vous mettez à jour (update) le répertoire de travail à un changeset ultérieur dans lequel le fichier a été supprimé, Mercurial supprimera une nouvelle fois le fichier du répertoire de travail.

Mercurial considère qu'un fichier que vous avez supprimé sans utiliserhg remove comme étant manquant. Un fichier manquant est représenté avec un “!” en sortie de hg status. Les commandes Mercurial ne feront rien avec les fichiers manquants.

$ hg init missing-example
$ cd missing-example
$ echo a > a
$ hg add a
$ hg commit -m 'File about to be missing'
$ rm a
$ hg status
! a

Si votre dépôt contient un fichier que hg status reporte comme manquant, et que vous voulez que ce fichier reste supprimé, vous pouvez exécuter hg remove --after à tout moment pour dire à Mercurial que vous aviez bien voulu supprimer ce fichier.

$ hg remove --after a
$ hg status
R a

D'un autre côté, si vous avez supprimé le fichier manquant par accident, donnez à la commande hg revert le nom du fichier à retrouver. Il réapparaitra dans sa forme non modifiée.

$ hg revert a
$ cat a
a
$ hg status

Vous pourriez vous demander pourquoi il est nécessaire de dire explicitement à Mercurial que vous souhaitez supprimer un fichier. Au début du développement de Mercurial, celui ci vous laissait pourtant supprimer un fichier sans souci ; Mercurial vous aurait automatiquement informé de l'absence du fichier lorsque vous auriez lancé un hg commit et arrêté de le suivre. En pratique, ceci a montré qu'il était trop facile de supprimer accidentellement un fichier sans le remarquer.

Mercurial offre une commande combinée, hg addremove, qui ajoute les fichiers non suivis et marque les fichiers manquants comme supprimés.

$ hg init addremove-example
$ cd addremove-example
$ echo a > a
$ echo b > b
$ hg addremove
adding a
adding b

La commande hg commit fournit aussi une option -A qui exécute le même ajouter-et-supprimer, immédiatement suivi d'un commit.

$ echo c > c
$ hg commit -A -m 'Commit with addremove'
adding c

Ce qu'il se passe durant une fusion (merge) est que les changements “suivent” une copie. Pour illustrer ce que cela veut dire de la meilleure façon, créons un exemple. Nous allons commencer avec le mini dépôt usuel qui contient un simple fichier.

$ hg init my-copy
$ cd my-copy
$ echo line > file
$ hg add file
$ hg commit -m 'Added a file'

Nous devons faire du travail en parallèle, ainsi, nous aurons quelque chose à fusionner (merge). Donc clonons notre dépôt.

$ cd ..
$ hg clone my-copy your-copy
updating to branch default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

De retour dans notre dépôt initial, utilisons la commande hg copy pour faire une copie du premier fichier que nous avons créé.

$ cd my-copy
$ hg copy file new-file

Si nous regardons ensuite à la sortie de la commande hg status, les fichiers copiés ont l'air de fichiers normalement ajoutés.

$ hg status
A new-file

Mais si nous passons l'option -C à hg status, il affiche une autre ligne de sortie : il s'agit du fichier source pour notre copie.

$ hg status -C
A new-file
  file
$ hg commit -m 'Copied file'

Maintenant, de retour dans le dépôt que nous avons cloné, créons un changement en parallèle. Nous allons ajouter une ligne de contenu au fichier original qui a été créé.

$ cd ../your-copy
$ echo 'new contents' >> file
$ hg commit -m 'Changed file'

Nous avons alors un fichier file modifié dans ce dépôt. Lorsque nous récupérons (pull) les changements depuis le premier répertoire et fusionnons (merge) les deux "heads", Mercurial propagera les changements que nous avons faits localement au fichier file dans sa copie new-file.

$ hg pull ../my-copy
pulling from ../my-copy
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)
$ hg merge
merging file and new-file to new-file
0 files updated, 1 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ cat new-file
line
new contents

Ce comportement—des changements d'un fichier qui se propagent aux copies de ce fichier—peut sembler ésotérique, mais, dans la plupart des cas, c'est fortement souhaitable.

Pour commencer, souvenez-vous que cette propagation a lieu seulement lors des fusions (merge). Donc, si vous faites un hg copy sur un fichier, et par la suite modifiez le fichier original durant le cours normal de votre travail, rien n'aura lieu.

La deuxième chose à savoir est que les modifications ne se propageront à travers une copie que si le changeset à partir duquel vous faites une fusion (merge) n'a pas encore vu la copie.

La raison pour laquelle Mercurial fait ainsi est une règle. Imaginons que je corrige un important bug dans un fichier source et que je commit mes changements. Pendant ce temps, vous avez décidé de faire un hg copy du fichier dans votre dépôt, sans rien savoir au sujet du bug ou à propos de la correction. Vous avez alors commencé à "hacker" sur votre copie du fichier.

Si vous aviez récupéré (pull) et fusionné (merge) mes changements, et que Mercurial n'avait pas propagé les changements à travers les copies, votre nouveau fichier source contiendrait maintenant le bug, et à moins que vous ne sachiez qu'il faille propager la correction du bug à la main, le bug aurait subsisté dans votre copie du fichier.

En propageant automatiquement les changements qui fixent les bugs à partir du fichier original vers les copies, Mercurial prévient ce type de problèmes. À ma connaissance, Mercurial est le seul système de gestion de révisions qui propage les changements à travers les copies comme ceci.

Une fois que votre historique des changements a un enregistrement concernant une copie et qu'une fusion postérieure a eu lieu, il n'y a d'habitude pas d'autre besoin de propager les changements du fichier originel vers le fichier copié. C'est pourquoi Mercurial ne propage les changements à travers les copies qu'à la première fusion, et pas après.

Si pour une raison ou une autre, vous décidez que cette fonctionnalité de propager automatiquement les changements à travers les copies n'est pas pour vous, utilisez simplement la commande normale de copie de votre système (sur les systèmes de type Unix, il s'agit de cp) pour faire une copie d'un fichier. Utilisez ensuite hg add pour ajouter les nouveaux fichiers à la main. Cependant, avant d'en faire ainsi, relisez Section 5.3.2, “Pourquoi les changements devraient-ils suivre les copies ?”, et faites un choix en connaissance de cause comme quoi cette fonctionnalité n'est pas appropriée à votre cas spécifique.

Lorsque vous utilisez la commande hg copy, Mercurial crée une copie de chaque fichier source tel qu'il est actuellement dans le répertoire de travail. Cela signifie que si vous effectuez des modifications sur un fichier, puis faites un hg copy sur celui-ci sans avoir au préalable committé ces changements, la nouvelle copie contiendra aussi les modifications que vous avez fait jusqu'à ce point. (Je trouve ce comportement quelque peu contre intuitif, c'est pourquoi j'en fais mention ici.)

La commande hg copy agit comme la commande Unix cp (vous pouvez utilisez l'alias hg cp si vous préférez). Nous devons lui donner deux ou plus arguments où le dernier est considéré comme la destination, et les autres comme les sources.

Si vous passez à hg copy un seul fichier source, et que la destination n'existe pas, ceci créera un nouveau fichier avec ce nom.

$ mkdir k
$ hg copy a k
$ ls k
a

Si la destination est un répertoire, Mercurial copie les sources dans ce répertoire.

$ mkdir d
$ hg copy a b d
$ ls d
a  b

La copie de répertoire est récursive et préserve la structure du répertoire source.

$ hg copy z e
copying z/a/c to e/a/c

Si la source et la destination sont tous deux des répertoires, l'arborescence de la source est recréée dans le répertoire destination.

$ hg copy z d
copying z/a/c to d/z/a/c

Comme avec la commande hg remove, si vous copiez un fichier manuellement et voulez que Mercurial sache qu'il s'agit d'une copie, utilisez simplement l'option --after avec hg copy.

$ cp a n
$ hg copy --after a n

Puisque le “rename” de Mercurial est implanté comme un “copy-and-remove”, la même propagation des changements a lieu après un “rename” qu'après un “copy” lorsque vous fusionnez (merge).

Si je modifie un fichier et que vous le renommez, si ensuite nous fusionnons nos changements respectifs, mes modifications sur le fichier sous son nom originel seront propagés vers le même fichier sous son nouveau nom. (C'est quelque chose que vous pourriez espérer voir “fonctionner simplement”, mais tous les systèmes de gestion de version ne le font pas.)

Tandis qu'avoir des changements qui suivent une copie est une fonctionnalité où vous hocheriez sûrement la tête en disant “oui, cela pourrait être utile”, il est clair que les voir suivre un renommage est sans aucun doute important. Sans cette facilité, il serait vraiment trop facile d'avoir des changements qui deviennent orphelins lorsque des fichiers sont renommés.

Le cas de noms divergeants a lieu lorsque deux développeurs commencent avec un fichier—appelons le foo—dans leurs dépôts respectifs.

$ hg clone orig anne
updating to branch default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg clone orig bob
updating to branch default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

Anne renomme le fichier en bar.

$ cd anne
$ hg rename foo bar
$ hg ci -m 'Rename foo to bar'

Pendant ce temps, Bob le renomme en quux. (Souvenez-vous que hg mv est un alias pour hg rename.)

$ cd ../bob
$ hg mv foo quux
$ hg ci -m 'Rename foo to quux'

J'aime à penser qu'il s'agit d'un conflit puisque chaque développeur a exprimé différentes intentions au sujet de ce que le nom de ce fichier aurait du être.

Que pensez-vous qu'il devrait se produire lorsqu'ils fusionnent (merge) leurs travaux ? Le comportement actuel de Mercurial est qu'il préserve toujours les deux noms lorsqu'il fusionne (merge) des changesets qui contiennent des renommages divergeants.

# See http://www.selenic.com/mercurial/bts/issue455
$ cd ../orig
$ hg pull -u ../anne
pulling from ../anne
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
1 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ hg pull ../bob
pulling from ../bob
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)
$ hg merge
warning: detected divergent renames of foo to:
 bar
 quux
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ ls
bar  quux

Remarquez que bien que Mercurial vous avertisse au sujet de la divergeance des renommages, il vous laisse faire quelque chose au sujet de la divergence après la fusion (merge).

Un autre type de conflit de renommage intervient lorsque deux personnes choisissent de renommer différents fichiers source vers la même destination. Dans ce cas, Mercurial exécute la machinerie normale de fusion (merge) et vous guide vers une solution convenable.

Mercurial possède un bug de longue date dans lequel il échoue à traiter une fusion (merge) où un côté a un fichier avec un nom donné, alors que l'autre côté possède un répertoire avec le même nom. Ceci est documenté dans l'issue 29.

$ hg init issue29
$ cd issue29
$ echo a > a
$ hg ci -Ama
adding a
$ echo b > b
$ hg ci -Amb
adding b
$ hg up 0
0 files updated, 0 files merged, 1 files removed, 0 files unresolved
$ mkdir b
$ echo b > b/b
$ hg ci -Amc
adding b/b
created new head
$ hg merge
abort: Is a directory: /tmp/issue29wS6WTk/issue29/b

Lorsqu'une fusion intervient, la plupart des fichiers vont, la plupart du temps, rester sans modification. Pour chaque fichier sur lequel Mercurial doit faire quelque chose, il suit l'état de celui-ci.

Si Mercurial voit un fichier quelconque dans un état “unresolved” après une fusion (merge), il considère que la fusion (merge) a échoué. Heureusement, nous n'avons pas à recommencer la procédure à partir du début.

L'option --list ou -l passée à hg resolve liste l'état de chaque fichier fusionné (merge).

$ hg resolve -l
U myfile.txt

En sortie de hg resolve, un fichier “resolved” est marqué avec un R, alors qu'un fichier “unresolved” est marqué d'un U. S'il existe un fichier listé avec un U, nous savons qu'essayer de committer le résultat de la fusion (merge) échouera.

Nous avons plusieurs options pour changer l'état d'un fichier de “unresolved” à “resolved”. Le plus habituel est de relancer hg resolve. Si nous passons les noms des fichiers individuels ou des répertoires, ceci retentera la fusion de tous les fichiers présents à cet endroit. Nous pouvons aussi passer l'option --all ou -a qui tentera de fusionner tous les fichiers “unresolved”.

Mercurial nous laisse aussi modifier la résolution d'un fichier directement. Nous pouvons marquer un fichier “resolved” en utilisant l'option --mark, ou “unresolved” en utilisant l'option --unmark. Ceci nous autorise à nettoyer une fusion particulièrement compliquée à la main, et de garder un suivi de nos progrès avec chaque fichier pendant que nous avançons.

L'aspect le plus important de tout modèle que vous devez garder en tête est la façon dont il subvient aux besoins et capacités des personnes qui l'utiliseront. Ceci pourrait sembler évident en soi ; pourtant, vous ne pouvez pas vous permettre de l'oublier à un seul moment.

Une fois, j'ai mis en place un modèle de workflow qui m'apparaissait comme parfait, mais il a causé la consternation et des conflits au sein de mon équipe de développement. En dépit de mes tentatives pour expliquer pourquoi nous avions besoin d'un ensemble complexe de branches, et comment les changements devaient couler entre eux, certains membres de l'équipe se révoltèrent. Alors qu'ils étaient pourtant des personnes sympathiques, ils ne voulaient pas prêter attention aux contraintes sur lesquelles nous étions en train d'opérer, ou, face aux conséquences de ces contraintes dans les détails du modèle que je préconisais.

Ne balayez pas les problèmes sociaux ou techniques de la main. Quelque soit le schéma que vous établirez, vous devriez planifier un protocole pour prévenir, ou rapidement vous relever de troubles que vous pouvez anticiper. Par exemple, si vous vous attendez à avoir une branche pour les changements pas-pour-release, vous devriez penser très tôt à la possibilité qu'une personne fusionne (merge) accidentellement ces changements avec une branche de release. Vous pouvez empécher ce problème particulier en écrivant un hook qui prévient les changements d'être fusionnés à partir d'une branche inopportune.

Je ne voudrais pas suggérer qu'une approche “tout peut arriver” comme quelque chose de durable, mais il s'agit d'un modèle qui est simple à saisir et qui fonctionne parfaitement dans quelques situations inhabituelles.

Par exemple, beaucoup de projets ont un groupe distant de collaborateurs qui ne se rencontre physiquement que très rarement. Certains groupes aiment vaincre l'isolation du travail à distance en organisant occasionnellement des “sprints”. Dans un sprint, des personnes viennent ensemble dans un même endroit (la salle de conférence d'une société, la salle de réunion d'un hôtel, ce genre d'endroit) et y passent plusieurs jours, plus ou moins enfermés, et hackant intensément sur une poignée de projets.

Un "sprint" ou une session de "hacking" dans un café sont les endroits parfaits pour utiliser la commande hg serve puisque hg serve n'a pas besoin d'une infrastructure extraordinaire de serveurs. Vous pouvez commencer avec la commande hg serve en quelques instants, en lisant Section 6.4, “Partage informel avec hg serve” plus bas Ensuite, dites simplement à la personne à côté de vous que vous exécutez un serveur, envoyez-lui l'URL par un message instantané, et vous avez immédiatement un moyen simple et rapide de travailler ensemble. Ils peuvent taper votre URL dans leur navigateur web et rapidement revoir vos changements ; ou ils peuvent récupérer chez vous un bugfix et le vérifier ; ou ils peuvent cloner une branche contenant une nouvelle fonctionnalité et la tester.

Le charme et le problème en faisant les choses ainsi, dans un mode ad-hoc est que seules les personnes qui sont au courant de vos changements, et de leur emplacement, peuvent les voir. Une telle approche informelle ne passe simplement pas à l'échelle au delà d'une poignée de personnes, puisque chacun a besoin de connaître n différents dépôts à partir des quels récupérer les changements (pull).

Pour de plus petits projets qui migrent depuis un outil de gestion de révision centralisé, la façon la plus simple de commencer est certainement d'avoir un flux de changement à partir d'un unique dépôt central. Il s'agit aussi du “composant” pour des schémas de workflow plus ambitieux.

Les contributeurs commencent par cloner une copie de ce dépôt. Ils peuvent récupérer les changements à n'importe quel moment où ils en ressentent le besoin, et certains (sûrement tous) développeurs ont les persmissions qui leur permettent d'envoyer leurs modifications (push) en retour lorsqu'elles sont prêtes pour que les autres personnes puissent les voir.

Dans ce modèle, il peut encore être sensé pour les gens de récupérer les changements directement entre eux, sans passer par le dépôt central. Considérez le cas où j'ai un bug fix provisoire, mais je m'inquiète de savoir si, dans le cas où je le publiais, cela ne casserait pas l'arbre des autres contributeurs s'ils la récupèreraient. Pour réduire les dommages potentiels, je peux vous demander de cloner mon dépôt dans un dépôt temporaire qui vous appartient et de le tester. Ceci nous permet de ne pas publier les modification potentiellement dangereuses tant qu'elles n'ont pas encore été un peu testées.

Si une équipe héberge son propre dépôt dans ce type de scénario, les personnes qui utilisent habituellement le protocole ssh pour envoyer (push) en toute sécurité leurs changements au dépôt central, comme docummenté dans Section 6.5, “Utiliser le protocole Secure Shell (ssh)”. Il est aussi usuel de publier une copie en lecture seule du dépôt sur HTTP comme dans Section 6.6, “Service sur HTTP grâce à CGI”. Publier sur HTTP satisfait le besoin des personnes qui n'ont pas d'accès en écriture, et ceux qui veulent utiliser leur navigateur web pour explorer l'historique du dépôt.

Une chose magnifique au sujet des services d'hébergement comme Bitbucket est qu'ils ne gèrent pas uniquement les détails minutieux de la configuration du serveur, tels que les comptes utilisateurs, l'authentification, les protocoles sécurisés, ils fournissent aussi une infrastructure additionnelle pour que ce modèle fonctionne bien.

Par exemple, un service d'hébergement bien conçu laissera les personnes cloner leurs copies d'un dépôt à l'aide d'un simple clic. Ceci laisse les personnes travailler dans des espaces séparés et partager leurs changements lorsqu'ils sont prêts.

De plus, un bon service d'hébergement laissera les personnes communiquer ensemble, par exemple pour dire “Il y a des changements prêts pour toi pour relecture dans cet arbre”.

Les projets d'une taille significative ont tendance à avancer sur plusieurs fronts en même temps. Dans le cas de logiciel, il est commun qu'un projet sorte périodiquement des releases officielles. Une release devrait ensuite aller dans le “mode de maintenance” pour un moment après sa première publication ; les releases de maintenance tendent à contenir seulement des corrections de bugs, et non de nouvelles fonctionnalités. En parallèle de ces releases de maintenance, une ou plusieurs futures releases doivent être en cours de développement. Les gens utilisent en général le mot “branche” pour référer à l'une de ces nombreuses directions légèrement différentes dans lesquelles le développement évolue.

Mercurial est particulièrement bien adapté pour gérer plusieurs branches simultanées mais non identiques. Chaque “direction de développement” peut vivre dans son propre dépôt central, et vous pouvez récupérez les changements de l'un ou l'autre lorsque le besoin s'en fait sentir. Parce que les dépôts sont indépendant les uns des autres, les modifications instables dans une branche de développement n'affecteront jamais une branche stable, sauf si quelqu'un fusionne (merge) explicitement ces changements dans la branche stable.

Voici un exemple sur comment cela peut se passer en pratique. Disons que vous avez une “branche principale” sur un serveur central.

$ hg init main
$ cd main
$ echo 'This is a boring feature.' > myfile
$ hg commit -A -m 'We have reached an important milestone!'
adding myfile

Les contributeurs le clonent, y apportent localement des modifications, les testent et envoient (push) en retour leurs changements.

Une fois que la branche principale atteint une étape assez importante pour une release, vous pouvez utiliser la commande hg tag pour donner un nom permanent à cette étape de révision.

$ hg tag v1.0
$ hg tip
changeset:   1:33e75fb73c66
tag:         tip
user:        Bryan O'Sullivan <bos@serpentine.com>
date:        Thu Mar 17 05:08:41 2011 +0000
summary:     Added tag v1.0 for changeset 73e86f09043d

$ hg tags
tip                                1:33e75fb73c66
v1.0                               0:73e86f09043d

Disons que du developpement continue sur la branche principale.

$ cd ../main
$ echo 'This is exciting and new!' >> myfile
$ hg commit -m 'Add a new feature'
$ cat myfile
This is a boring feature.
This is exciting and new!

En utilisant le tag enregistré à l'étape importante, les gens qui clonent ce dépôt peuvent à tout moment dans le futur utiliser la commande hg update pour avoir une copie du répertoire de travail exactement comme il était lorsque cette révision "tag" a été committée.

$ cd ..
$ hg clone -U main main-old
$ cd main-old
$ hg update v1.0
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cat myfile
This is a boring feature.

De plus, immédiatement après que la branche principale soit taggée, nous pouvons maintenant cloner la branche principale sur le serveur vers une nouvelle branche “stable” sur le même serveur.

$ cd ..
$ hg clone -rv1.0 main stable
requesting all changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files
updating to branch default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved

Si nous avons besoin d'effectuer des modifications à la branche stable, nous pouvons alors cloner ce dépôt, effectuer nos modifications, committer, et envoyer nos changements en retour là bas.

$ hg clone stable stable-fix
updating to branch default
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ cd stable-fix
$ echo 'This is a fix to a boring feature.' > myfile
$ hg commit -m 'Fix a bug'
$ hg push
pushing to /tmp/branchingeS3nOt/stable
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files

Puisque les dépôts Mercurial sont indépendants, et que Mercurial ne déplace pas les changements automatiquement, les branches stable et principale sont isolées l'une de l'autre. Les changements qui sont faits à la branche principale ne “fuient” pas vers la branche stable, et vice versa.

Nous allons souvent avoir envie que toutes nos correction de bugs sur la branche stable soient reportées sur la branche principale. Plutôt que de réécrire une correction de bug pour la branche principale, nous pouvons simplement récupérer (pull) et fusionner (merge) les changements de la branche stable vers la branche principal, et Mercurial se débrouillera pour rapporter ces corrections de bugs pour nous.

$ cd ../main
$ hg pull ../stable
pulling from ../stable
searching for changes
adding changesets
adding manifests
adding file changes
added 1 changesets with 1 changes to 1 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)
$ hg merge
merging myfile
0 files updated, 1 files merged, 0 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ hg commit -m 'Bring in bugfix from stable branch'
$ cat myfile
This is a fix to a boring feature.
This is exciting and new!

La branche principale contiendra toujours des changements qui ne sont pas dans la branche stable, mais elle contiendra aussi les corrections de bugs de la branche stable. La branche stable restera non affectée par ces changements, tant qu'ils coulent de la branche stable vers la branche principale, et non dans l'autre sens.

Pour de plus gros projets, une façon efficace de gérer les changements est de diviser l'équipe en plus petits groupes. Chaque groupe a une branche partagée qui lui est attitrée, clonée à partir d'une unique branche “principale” utilisée pour le projet entier. Les personnes travaillant sur une branche individuelle sont typiquement isolées des développements sur les autres branches.

Figure 6.1. Feature branches

Lorsqu'une fonctionnalité particulière est réputée pour être dans une forme adaptée, quelqu'un de l'équipe qui s'en occupe récupère les changements (pull) à partir de la branche principale vers la branche de cette fonctionnalité, fusionne (merge) et renvoie (push) le tout vers la branche principale.

Certains projets sont organisés comme un “train” élémentaire : une release est planifiée tous les quelques mois, et, toutes les fonctionnalités disponibles lorsque le “train” est prêt à s'arrêter sont autorisées ici.

Ce modèle ressemble à travailler avec des branches de fonctionnalités. La différence est que lorsqu'une branche de fonctionnalité rate le train, quelqu'un de l'équipe qui travaille sur cette fonctionnalité récupère (pull) et fusionne (merge) ce qui a été ajouté à la release du train dans la branche de la fonctionnalité, puis, l'équipe continue son travail au-dessus de cette release afin que leur fonctionnalité puisse être ajoutée à la prochaine release.

Le développement du noyau Linux est doté d'une structure hiérarchique superficielle, entourée par un nuage de chaos apparent. Parce que la plupart des développeurs Linux utilisent git, un outil distribué de gestion de révisions avec des capacités similaires à celles de Mercurial, il est utile de décrire comment le travail se déroule dans cet environnement ; si vous aimez ces idées, l'approche se traduit correctement à travers les outils.

Au centre de la communauté siège Linus Torvalds, le créateur de Linux. Il publie un dépôt unique de sources qui est considéré comme faisant “autorité” sur l'arborescence par la communauté entière de développeurs. Tout le monde peut cloner l'arbre de Linus, mais il ne récupère (pull) pas les changements de n'importe quelle arborescence.

Linus a plusieurs “lieutenants de confiance”. Comme règle générale, il récupère (pull) tous les changements qu'ils publient, dans la plupart des cas sans même relire ces modifications. Certains de ces lieutenants sont généralement autorisés à être “mainteneurs”, responsables pour un sous-système spécifique du noyau. Si un hacker du noyau veut apporter des modification au sous-système qu'il veut voir intégré à l'arbre de Linus, il doit trouver le mainteneur du sous-système, et lui demander de récupérer ses changements. Si le mainteneur relit ses changements et les accepte, ils seront transmis à Linus le moment venu.

Les lieutenants individuels ont leur propre approche pour relire, accepter et publier les changements ; et pour décider quand les apporter à Linus. De plus, il y a plusieurs branches connues que les personnes utilisent pour différentes choses. Par exemple, quelques personnes maintiennent des dépôts “stables” de leurs versions du noyau, pour lesquels ils apportent des corrections critiques lorsque nécessaire. Certains mainteneurs publient plusieurs arbres : l'un pour les changements expérimentaux, l'un pour les changements qu'ils vont faire remonter, etc. D'autres ne publient qu'un unique arbre.

Ce modèle a deux caractéristiques remarquables. La première est qu'il s'agit de “pull seulement”. Vous devez demander, convaincre, ou mendier auprès d'un autre développeur pour prendre vos modifications, puisqu'il n'y a vraisemblablement pas d'arbre où plus d'une personne peut envoyer des changements (push), et qu'il n'y a pas de possibilité d'envoyer des changements (push) vers un arbre que quelqu'un d'autre contrôle.

La seconde est que c'est basé sur la réputation et l'acclamation. Si vous êtes un inconnu, Linus va probablement ignorer vos changements sans même répondre. Cependant, un mainteneur de sous-système les relira probablement, et les acceptera sûrement s'ils passent ses critères d'acceptation. Plus vous enverrez du “bon” code à un mainteneur, et plus celui-ci aura confiance en votre jugement et acceptera vos changements. Si vous êtes bien connu et maintenez une branche ancienne pour quelque chose que Linus n'a pas encore accepté, les gens avec un intérêt similaire devraient récupérer vos changements régulièrement pour rester à jour vis-à-vis de votre travail.

La réputation et l'acclamation ne nécessite pas de système croisé ou de limites “entre les gens”. Si vous êtes respectés mais que vous êtes un hacker spécialisé dans la sauvegarde, et que vous tentez de corriger un bug réseau, ce changement recevra un examen approfondi de la part du mainteneur responsable du réseau comparable à celui d'un total étranger.

Pour les personnes qui viennent d'un projet dont le milieu est plus ordonné, le processus chaotique de développement du noyau Linux en comparaison apparaît souvent totalement dément. C'est sujet aux caprices d'individus ; des personnes font des changements considérables quand ils les jugent appropriés ; et l'allure du développement est ahurissante. Et pourtant, Linux est un bout de logiciel d'une grande réussite et bien considéré.

Une source perpétuelle de heurts dans la communauté opensource est de savoir si un modèle de développement où les personnes ne peuvent que récupérer (pull) les changements d'autres est “meilleur” que celui dans lequel de multiples personnes peuvent envoyer (push) leurs changements vers un dépôt partagé.

Typiquement, les partisans du modèle push partagé utilisent des outils qui renforcent activement cette approche. Si vous utilisez un outil centralisé de gestion de révision comme Subversion, il n'y a pas la possibilité de choisir quel modèle utiliser : l'outil vous fournit un push partagé, et si vous voulez faire quelque chose d'autre, vous avez à changer votre propre approche à la base (comme appliquer les patchs manuellement).

Un bon outil de gestion distribuée de révisions doit supporter les deux modèles. Vous et vos collaborateurs pouvez ensuite structurer la façon dont vous travaillez ensemble en vous basant sur vos besoins et vos préférences, et non sur les contorsions que vos outils vous forcent à effectuer.

Lorsque vous et votre équipe configurez des dépôts partagés et commencez à propager vos changement dans tous les sens entre les dépôts locaux et partagés, vous commencez à être face à un défi connexe, mais un peu différent : celui de gérer les multiples directions vers lesquelles votre équipe pourrait aller au même moment. Même si ce sujet est intimement lié à la façon dont votre équipe collabore, il est suffisement dense pour mériter un traitement à part dans Chapter 8, Managing releases and branchy development.

Puisque il fournit un accès en lecture sans authentification à tous les clients, vous devriez utiliser la commande hg serve dans un environnement où vous ne vous inquiétez pas ou vous avez tout contrôle sur qui peut avoir accès au réseau et récupérer les données de votre dépôt.

La commande hg serve ne sait rien sur un quelconque firewall que vous auriez installé sur votre système ou réseau. Elle ne peut pas détecter ou contrôler votre logiciel de pare-feu. Si d'autre personnes ont la possibilité de dialoguer avec une instance de hg serve la seconde chose que vous devriez faire (après être sûr qu'ils utilisent l'URL correcte) est de vérifier la configuration de votre firewall.

Par défaut, hg serve écoute pour les connexions entrantes sur le port 8000. Si un autre processus est déjà en train d'écouter sur le port que vous voulez écouter, vous pouvez spécifier un port différent sur lequel écouter à l'aide de l'option -p.

Normalement, lorsque hg serve se lance, il n'affiche aucune sortie, ce qui peut être un peu énervant. Si vous voulez une confirmation que tout s'est déroulé correctement, et connaître l'URL que vous devriez fournir à vos collaborateurs, démarrez avec l'option -v.

Une URL ssh a tendance à ressembler à ceci :

ssh://bos@hg.serpentine.com:22/hg/hgbook

Il y a beaucoup de risque de confusion sur le chemin du composant d'une URL ssh puisqu'il n'y a pas de façon standard pour les outils de l'interpréter. Certains programmes se comportent différemment des autres lorsqu'ils traitent ces chemins. Il ne s'agit pas d'une situation idéale, mais ce n'est pas prêt de changer. Lisez les prochains paragraphes avec attention.

Mercurial traite le chemin vers un dépôt sur le serveur comme relatif au répertoire personnel de l'utilisateur sur le serveur distant. Par exemple, si un utilisateur foo sur le serveur a un répertoire personnel /home/foo, alors l'URL ssh qui contient un composant chemin de bar réfère en réalité au répertoire /home/foo/bar.

Si vous voulez spécifier un chemin relatif au répertoire personnel d'un autre utilisateur, vous pouvez préciser un chemin qui commence à l'aide du caractère tilde suivi du nom de l'utilisateur (appelons le otheruser), ainsi.

ssh://server/~otheruser/hg/repo

Et si vous voulez vraiment spécifier un chemin absolu sur le serveur, débutez le composant chemin par deux slashs comme dans cet exemple.

ssh://server//absolute/path

La plupart des systèmes du type Unix arrivent avec OpenSSH préinstallé. Si vous utilisez un tel système, utilisez which ssh pour trouver où la commande ssh est installée (il s'agit généralement de /usr/bin). Dans le cas peu probable où il ne serait pas présent, regarder la documentation de votre système pour voir comment l'installer.

Sous Windows, le paquet TortoiseHg est livré avec une version de l'excellente commande plink de Simon Tatham, et ne devrait pas avoir besoin de plus de configuration.

Pour éviter d'avoir à chaque fois taper un mot de passe lorsque vous utilisez votre client ssh, je recommande de créer une paire de clefs.

	Les paires de clefs ne sont pas obligatoires
	Mercurial ne sait rien du tout de l'authentification de ssh ou de la paire de clefs. Vous pouvez, si vous le désirez, ignorer sans risque cette section et la suivante jusqu'à ce que vous soyez fatigué de constamment retaper des mots de passe ssh.

Lorsque vous créez une paire de clefs, il est habituellement hautement recommandé de la protéger avec un mot de passe. (Le seul moment où vous pourriez ne pas devoir le faire est lorsque vous utilisez le protocole ssh pour des tâches automatisées sur un réseau sécurisé.)

Le simple fait de créer une paire de clefs n'est cependant pas suffisant. Vous aurez besoin d'ajouter la clef publique à l'ensemble des clefs autorisées pour tout utilisateur que vous utilisez pour vous connecter à distance. Pour les serveurs utilisant OpenSSh (la grande majorité), ceci voudra dire d'ajouter la clef publique à la liste dans un fichier appelé authorized_keys dans leur répertoire .ssh.

Sur un système de type Unix, votre clef publique aura l'extension .pub. Si vous utilisez la commande puttygen sous Windows, vous pouvez sauvegarder la clef publique dans un fichier que vous choisissez ou la copier à partir de la fenêtre qui apparait directement dans le fichier authorized_keys.

Un agent d'authentification est un démon qui enregistre les mots de passe en mémoire (il oublira ainsi les mots de passe si vous vous déconnectez et reconnectez). Un client ssh sera averti si un tel agent est en fonctionnement, et lui demandera un mot de passe. S'il n'y a pas d'agent en fonctionnement, ou si l'agent ne connaît pas le mot de passe nécessaire, vous aurez à taper votre mot de passe chaque fois que Mercurial tente de communiquer avec un serveur en votre nom (ex. lorsque vous faite un pull ou un push de changements).

L'inconvénient de sauvegarder les mots de passe dans un agent est qu'il est possible pour un attaquant bien préparé de retrouver le mot de passe clair, dans certains cas, même si votre système a été redémarré. Vous devriez vous faire votre propre jugement pour savoir si ce risque est acceptable. Ceci vous exempte certainement d'un tas de répétitions.

Parce que ssh peut être délicat à installer si c'est nouveau pour vous, différentes choses peuvent mal se passer. Ajouter Mercurial en plus, et il y a beaucoup plus de possibilités pour s'arracher les cheveux. La plupart de ces problèmes potentiels apparaissent du côté serveur, non du côté client. La bonne nouvelle est qu'une fois que vous avez une configuration qui marche, elle continue habituellement de fonctionner indéfiniment.

Avant d'essayer de faire communiquer Mercurial avec un serveur ssh, il est mieux de s'assurer que vous pouvez d'abord utiliser le ssh normal ou la commande putty pour communiquer avec le serveur. Si vous vous heurtez a des problèmes en utilisant ces commandes directement, Mercurial ne fonctionnera sûrement pas. Pire, il cachera le problème sous-jacent. Chaque fois que vous voulez déboguer des problèmes de Mercurial liés à ssh, vous devriez d'abord vous assurer que les commandes du client ssh fonctionne d'abord, avant de vous inquiéter à propos de savoir si il y a un problème avec Mercurial.

La première chose à s'assurer du côté serveur est que vous puissiez réellement vous connecter depuis une autre machine. Si vous ne pouvez pas utiliser ssh ou putty pour vous connecter, le message d'erreur que vous aurez peut vous donner quelques indices sur ce qui ne fonctionne pas. Les problèmes les plus courants sont les suivants.

En résumé, si vous avez des difficultés pour communiquer avec le démon ssh du serveur, d'abord assurez-vous qu'il y en a un en fonctionnement. Sur beaucoup de systèmes, il est installé, mais désactivé, par défaut. Une fois que c'est fait, vous devriez alors vérifier que le pare-feu du serveur est configuré pour permettre les connexions entrantes sur le port que le démon ssh écoute (habituellement 22). Ne vous inquiétez pas à propos de possibilités plus exotiques de mauvaise configuration tant que vous n'avez pas vérifier ces deux premières.

Si vous utilisez un agent d'authentification du côté client pour stocker les passphrases de vos clés, vous devriez être capable de vous connecter au serveur sans avoir à entrer une passphrase ou un mot de passe. Si vous devez entrer une passphrase, il y a quelques coupables possibles.

Si vous devez entrer le mot de passe d'utilisateur distant, il y a quelques autres problèmes possibles à vérifier.

Dans le monde idéal, vous devriez être capable d'exécuter la commande suivante avec succès, et elle devrait imprimer exactement une ligne en sortie, la date et l'heure actuelle.

ssh myserver date

Si, sur votre serveur, vous avec des scripts de connexion qui impriment des bannières ou d'autre "junk" même en fonctionnement non-interactif comme ici, vous devriez corriger cela avant de continuer, comme cela elles imprimeront des sorties que si elles fonctionnent en mode interactif. Autrement, au minimum, ces bannières encombreront les sorties de Mercurial. Pire, elles pourront potentiellement causer des problèmes avec des commandes Mercurial exécutées à distance. Mercurial essaye de détecter et d'ignorer des bannières dans des sessions ssh non-interactives, mais il n'est pas infaillible. (Si vous éditez vos scripts de connexion sur votre serveur, la manière habituelle de voir si un script de connexion fonctionne dans un shell interactif est de vérifier le code de retour de la commande tty -s.)

Lorsque vous avez vérifié que le bon vieux ssh fonctionne avec votre serveur, l'étape suivante est de s'assurer que Mercurial fonctionne sur le serveur. La commande suivant devrait fonctionnement correctement :

ssh myserver hg version

Si vous voyez un message d'erreur au lieu de la sortie normale de hg version, c'est habituellement parce que vous n'avez pas installé Mercurial dans /usr/bin. Ne vous inquiétez pas si c'est le cas ; vous n'avez pas besoin de le faire. Mais vous devriez vérifiez quelques problèmes possibles.

Si vous pouvez exécuter hg version sur une connexion ssh, bravo ! Vous avez réglé les problèmes du serveur et du client. Vous devriez maintenant être capable d'utiliser Mercurial pour accéder à des dépôts hébergés par cet utilisateur sur ce serveur. Si vous avez des problèmes avec Mercurial et ssh à ce moment, essayer d'utiliser l'option --debug pour obtenir une image plus claire de ce qui se passe.

Mercurial ne comprime pas les données quand il utilise le protocole ssh, car le protocole ssh peut comprimer de manière transparente les données. De plus, le comportement par défaut des clients ssh est de ne pas demander de la compression.

Sur n'importe quel réseau autre qu'un réseau local rapide (même un réseau sans fil), utiliser la compression améliore significativement la vitesse des opérations réseau de Mercurial. Par exemple, sur un WAN, quelqu'un a mesuré que la compression a réduit la durée pour cloner un dépôt particulièrement grand de 51 minutes à 17 minutes.

Les deux commandes ssh et plink acceptent une option -C qui active la compression. Vous pouvez facilement éditer votre ~/.hgrc pour activer la compression pour tous les usages de Mercurial du protocole ssh. Voici comment faire pour la commande habituelle ssh sur des systèmes Unix-like, par exemple.

[ui]
ssh = ssh -C

Si vous utilisez ssh sur un système Unix-like, vous pouvez le configurer pour toujours utiliser la compression lors de la connexion avec votre serveur. Pour cela, éditer votre fichier .ssh/config (qui peut ne pas encore exister), comme suit.

Host hg
  Compression yes
  HostName hg.example.com

Ceci définit un alias pour le nom d'hôte, hg. Quand vous utilisez ce nom d'hôte sur la ligne de commande ssh ou dans une URL Mercurial en protocole ssh, ssh se connectera à hg.example.com et utilisera la compression. Ceci vous offre à la fois un nom plus court à taper et la compression, chacun est une bonne chose en lui-même.

Avant de continuer, prenez quelques instants pour contrôler quelques aspects de l'installation de votre système.

Si vous n'avez pas de serveur web installé, et n'avez pas d'expérience solide dans la configuration Apache, vous devriez envisager d'utiliser le serveur web lighttpd au lieu d'Apache. Apache a une réputation bien méritée de configuration baroque et déroutante. Bien que lighttpd ait moins de fonctions qu'Apache, la plupart de celles-ci ne sont pas utiles pour servir des dépôts Mercurial. Et lighttpd est incontestablement beaucoup plus facile pour débuter qu'Apache.

Sur les systèmes Unix-like, il est habituel pour les utilisateurs d'avoir un sous-répertoire nommé quelque chose comme public_html dans leur "home directory", à partir duquel ils peuvent servir des pages web. Un fichier appelé foo dans ce répertoire sera accessible à une URL de la forme http://www.example.com/username/foo.

Pour commencer, trouver le script hgweb.cgi qui devrait être présent dans votre installation de Mercurial. Si vous ne pouvez pas trouver rapidement une copie locale sur votre système, téléchargez-le simplement du dépôt maître de Mercurial à http://www.selenic.com/repo/hg/raw-file/tip/hgweb.cgi.

Vous devrez copier ce script dans votre répertoire public_html, et vous assurez qu'il est exécutable.

cp .../hgweb.cgi ~/public_html
chmod 755 ~/public_html/hgweb.cgi

L'argument 755 de chmod est un peu plus général que de rendre le script exécutable: il garantit que le script est exécutable par n'importe qui, et que les permissions d'écriture pour le “group” et les “other” ne sont pas définies. Si vous laissez ces permissions d'écriture activées, le sous-système suexec d'Apache refuserait probablement d'exécuter le script. En fait, suexec insiste aussi pour que le répertoire dans lequel le script réside ne soit pas inscriptible par d'autres.

chmod 755 ~/public_html

chmod 755 ~
find ~/public_html -type d -print0 | xargs -0r chmod 755
find ~/public_html -type f -print0 | xargs -0r chmod 644

<Directory /home/*/public_html>
  AllowOverride FileInfo AuthConfig Limit
  Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec
  <Limit GET POST OPTIONS>
    Order allow,deny
    Allow from all
  </Limit>
  <LimitExcept GET POST OPTIONS>
    Order deny,allow Deny from all
  </LimitExcept>
</Directory>

AddHandler cgi-script .cgi

userdir.path = "public_html"
cgi.assign = (".cgi" => "" )

Le script hgweb.cgi vous laisse seulement publier un seul dépôt, ce qui est une limitation ennuyeuse. Si vous voulez publier plus d'un dépôt sans "wracking yourself" avec de multiples copies du même script, chacune avec un nom différent, un meilleur choix est d'utiliser le script hgwebdir.cgi.

La procédure pour configurer hgwebdir.cgi est seulement un peu plus compliquée que pour hgweb.cgi. D'abord, vous devez obtenir une copie du script. Si vous n'en avez pas une sous la main, vous pouvez télécharger une copie depuis le dépôt maître de Mercurial à http://www.selenic.com/repo/hg/raw-file/tip/hgwebdir.cgi.

Vous aurez besoin de copier ce script dans votre répertoire public_html, et vous assurer qu'il est exécutable.

cp .../hgwebdir.cgi ~/public_html
chmod 755 ~/public_html ~/public_html/hgwebdir.cgi

Avec une configuration élémentaire "out of the way", essayez de visiter http://myhostname/~myuser/hgwebdir.cgi dans votre navigateur. Il devrait afficher une liste vide de dépôts. Si vous obtenez une fenêtre vide ou un message d'erreur, essayer de parcourir la liste de problèmes potentiels dans Section 6.6.2.1, “Que pourrait-il éventuellement mal se passer ?”.

Le script hgwebdir.cgi se base sur un fichier de configuration externe. Par défaut, il cherche un fichier nommé hgweb.config dans le même répertoire que lui. Vous devrez créer ce fichier, et le rendre lisible par tout le monde. Le format de ce fichier est semblable à un fichier Windows “ini”, comme compris par un module Python ConfigParser [web:configparser].

La façon la plus facile de configurer hgwebdir.cgi est avec une section appellée collections. Ceci publiera automatiquement chaque dépôt sous les répertoires que vous citez. La section devrait ressembler à ceci :

[collections]
/my/root = /my/root

Mercurial interprète ceci en regardant le nom du répertoire sur la partie droite du signe “=” ; en trouvant les répertoires dans cette hiérarchie de répertoires ; et en utilisant le texte sur la gauche pour retirer le texte correspondant des noms qu'il listera réellement dans l'interface web. Le restant du chemin après que ce "stripping" a été réalisé est appelé un “chemin virtuel (virtual path)”.

Étant donné l'exemple ci-dessus, si vous avez un dépôt dont le chemin local est /my/root/this/repo, le script CGI retirera le début /my/root du nom, et publiera le dépôt avec un chemin virtuel this/repo. Si l'URL de base de notre script CGI est http://myhostname/~myuser/hgwebdir.cgi, l'URL complète URL pour ce dépôt sera http://myhostname/~myuser/hgwebdir.cgi/this/repo.

Si nous remplaçons/my/root sur la gauche de cet exemple par /my, alors hgwebdir.cgi retirera seulement /my du nom du dépôt, et nous donnera comme chemin virtuel root/this/repo au lieu de this/repo.

Le script hgwebdir.cgi cherchera récursivement dans chaque répertoire listé dans la section collections de son fichier de configuration, mais, il ne cherchera pas recursivement dans les répertoires qu'il trouvera.

Le mécanisme de collections rend facile la publication de plusieurs dépôts de façon “fire and forget”. Vous devez seulement installer le script CGI et le fichier de configuration une seule fois. Après, vous pouvez publier ou "dépublier" un dépôt n'importe quand en le déplaçant simplement dans, ou hors de la hiérarchie de répertoire dans laquelle vous avez indiqué à hgwebdir.cgi de regarder.

6.6.3.1. Spécifier explicitement quels dépôts publier

En plus du mécanisme de collections, le script hgwebdir.cgi vous permet de publier une liste spécifique de dépôts. Pour cela, créez une section paths, avec un contenu de la forme suivante.

[paths]
repo1 = /my/path/to/some/repo
repo2 = /some/path/to/another

Dans ce cas, le chemin virtuel (le composant qui apparaîtra dans une URL) est sur la gauche de chaque définition, tandis que le chemin vers le dépôt est sur la droite. Notez qu'il n'y a pas besoin de relation entre le chemin virtuel que vous choisissez et l'emplacement d'un dépôt dans votre système de fichiers.

Si vous le souhaitez, vous pouvez utiliser les mécanismes de collections et de paths simultanément dans un seul fichier de configuration.

	Prendre garde aux chemins virtuels en double
	Si plusieurs dépôts ont le même chemin virtuel, hgwebdir.cgi ne signalera pas d'erreur. Au lieu de cela, il se comportera de façon imprévisible.

L'interface web de Mercurial laisse les utilisateurs télécharger une archive de n'importe quelle révision. Cette archive contiendra une image du répertoire de travail comme pour cette révision, mais il ne contiendra pas une copie des données du dépôt.

Par défaut, cette fonctionnalité n'est pas activée. Pour l'activer, vous devrez ajouter un élément allow_archive à la section web de votre ~/.hgrc; voyez plus loin pour des détails.

Les interfaces web de Mercurial (la commande hg serve, et les scripts hgweb.cgi et hgwebdir.cgi) ont un nombre d'options de configuration que vous pouvez mettre. Celles-ci appartiennent à une section appelée web.

Si vous utilisez hgwebdir.cgi, vous pouvez mettre quelques éléments de configuration dans une section web du fichier hgweb.config au lieu d'un fichier ~/.hgrc, par commodité. Ces éléments sont motd et style.

Une situation dans laquelle un hgrc global peut être utile est si des utilisateurs "pullent" des modifications faites par d'autres utilisateurs. Par défaut, Mercurial can be useful is if users are pulling changes owned by other users. By default, Mercurial ne se fiera pas à la plupart des entrées de configuration dans un fichier .hg/hgrc à l'intérieur d'un dépôt qui appartient à un utilisateur différent. Si nous clonons ou "pullons" des modifications d'un tel dépôt, Mercurial affichera un avertissement indiquant qu'il ne fait pas confiance aux .hg/hgrc.

Si quelqu'un dans un groupe Unix particulier est dans la même équipe et devrait avoir confiance dans chaque réglage de configuration des autres, ou si nous voulons avoir confiance dans des utilisateurs particuliers, nous pouvons passer outre les défauts sceptiques de Mercurial en créant un fichier hgrc "system-wide" tel que celui qui suit ::

# Save this as e.g. /etc/mercurial/hgrc.d/trust.rc
[trusted]
# Trust all entries in any hgrc file owned by the "editors" or
# "www-data" groups.
groups = editors, www-data

# Trust entries in hgrc files owned by the following users.
users = apache, bobo