Un rapide tour de Mercurial

# HG changeset patch # User Romain PELISSE # Date 1251817212 -7200 # Node ID 1df99de46e391e4af875ed2e70b6b8dddf0603c5 # Parent 769698b84773a77e0e538e7674dc2f600bc59c4e Finishing works to adapt already existing translations to new xdoc fmt - also add a couple new translations to follow recent modification from Bryan. diff -r 769698b84773 -r 1df99de46e39 fr/ch02-tour-basic.xml --- a/fr/ch02-tour-basic.xml Mon Aug 31 16:04:52 2009 +0200 +++ b/fr/ch02-tour-basic.xml Tue Sep 01 17:00:12 2009 +0200 @@ -1,889 +1,1009 @@ - -Un rapide tour de Mercurial -\label{chap:tour-basic} - - -Installer Mercurial sur votre système -\label{sec:tour:install} - -Des paquetages binaires de Mercurial sont disponibles pour la plupart + + + Une rapide présentation de Mercurial : les bases + + + Installer Mercurial sur votre système + + Des paquetages binaires de Mercurial sont disponibles pour la plupart des systèmes d'exploitation, ce qui rend facile l'utilisation immédiate de Mercurial sur votre ordinateur. - -Linux - -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 uniques 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 \textit{mercurial}. - - -Debian: - - apt-get install mercurial - - -Fedora Core: - - - yum install mercurial - - - - - -Gentoo: - - - emerge mercurial - - - - - -OpenSUSE: - - - yum install mercurial - - - - - -Ubuntu: Le paquetage de Mercurial d'Ubuntu est construit sur celui de Debian. - Pour l'installer, exécutez simplement les commandes suivantes: - - - apt-get install mercurial - - - Les paquetages Ubuntu pour Mercurial ont tendance à être un peu en retard - par rapport au paquetage Debian (au moment de l'écriture de ce livre, il - faut compter à peu près un retard de 7 mois), ce qui signifie que parfois - sur Ubuntu, vous risquez de rencontrer des problèmes qui ont été corrigés - depuis longtemps dans les paquetages Debian. - - - - - -Solaris - -SunFreeWare, à http://www.saufreeware.com, est une bonne source -pour trouver un vaste nombre de paquets précompilés pour 32 ou 64 bits -Intel et les architecture Sparc, dont les versions courantes de Mercurial. - - - - -Mac OS X - -Lee Cantey publie un installateur de Mercurial pour Mac OS X sur le site -http://mercurial.berkwood.com. Ce paquetage fonctionne sur les -architectures Intel- et PowerPC. Avant de vous en servir, vous devez -installer une version Universelle MacPython web:macpython. C'est -assez facile à faire : suivez simplement les instructions sur le site -de Lee. - - -Il est aussi possible d'installer Mercurial en utilisant Fink ou MacPorts, -deux outils de gestion de paquetage libres pour Mac OS X. Si vous avez -Fink, utilisez sudo fink install mercurial-py25. Si vous avez -MacPorts, sudo port install mercurial. - - - - -Windows - -Lee Cantey publie aussi un installateur de Mercurial pour Windows sur le site -http://mercurial.berkwood.com. Ce paquetage n'a aucune dépendance -externe, il fonctionne tout court. - - - - La version de Windows de Mercurial ne convertie pas automatiquement - les retours chariot Windows et Unix. Si vous désirez partager votre - travail avec des utilisateurs Unix, vous devez faire un peu de configuration - supplémentaire. XXX En dire plus. - - - - - - -Commencer à utiliser Mercurial - -Pour commencer, nous utiliserons la commande hg version pour vérifier -si Mercurial est installé proprement. Les informations affichées sur la -version ne sont pas réellement importantes en soit, c'est surtout de savoir -si elles s'affichent qui nous intéresse. - - - - -L'aide intégrée - -Mercurial fournit un système d'aide intégré, ce qui est inestimable quand -vous vous retrouvez coincé à essayer de vous rappeler comment lancer telle -ou telle commande. -Si c'est le cas, exécutez simplement hg help; il vous aidera à imprimer -une brève liste de commandes, avec une description de ce qu'elles font. Si vous -demandez de l'aide sur une commande spécifique (voir ci-dessous), il affichera -des informations plus détaillées. - -Pour un niveau d'informations encore plus détaillées (ce dont vous aurez rarement -besoin), exécuter hg help . L'option est -l'abréviation de , et indique à Mercurial d'afficher plus -d'informations que d'habitude. - - - - - -Travailler avec un dépôt - -Avec Mercurial, tout se déroule au sein du dépôt\footnote{NdT: Dépôt est -la traduction que j'ai retenue pour tout l'ouvrage du terme anglais \textit{repository}}. -Le dépôt d'un projet contient tous les fichiers qui appartiennent au projet. - - -Il n'y a rien de particulièrement magique au sujet de ce dépôt, c'est -simplement une arborescence sur votre système de fichiers que Mercurial -traite de manière spéciale. Vous pouvez renommer ou effacer ce répertoire -à n'importe quel moment, en utilisant la ligne de commande ou votre -explorateur de fichiers. - - - -Faire une copie locale de votre dépôt - -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. - -Si votre opération de clonage réussit, vous devriez maintenant -avoir un répertoire local appelé hello. Ce répertoire -contiendra quelques fichiers. - -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é clôné, mais il ne communique pas avec -ce dernier, ou un autre, à moins que vous ne lui demandiez. - - -Ce que tout ceci signifie pour le moment est 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. - - - - -Quel est le contenu d'un dépôt ? - -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. - - - -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\footnote{NdT: -\textit{working directory}}. 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 une \emph{copie -ponctuelle}\footnote{NdT: Ce terme est une traduction du terme anglais -\textit{snapshot}. Il est traduit ici pour faciliter la lecture, mais ne sera -plus traduit par la suite.} de votre projet à un certain point de son -historique. - - - - - -Une ballade dans l'historique - -Une des premières choses que vous aurez envie de faire avec un nouveau -dépôt, sera de comprendre son historique. La commande hg log vous -donne une vue de l'historique. - -Par défaut, cette commande affiche à l'écran un bref paragraphe pour chaque -révision enregistrée pour ce projet. Dans la terminologie de Mercurial, nous -appelons chacun de ces évènements enregistrés un changeset, parce -qu'il contient un ensemble de modifications sur plusieurs fichiers. - - -La commande hg log affiche ainsi ces informations: - - -changeset: Ce champ contient un nombre, séparé par deux points - (:), d'une chaine hexadécimale. Il s'agit en fait d'identifiants - d'un \textit{changeset}. Il y a deux identifiants car le numéro de - la révision est plus court et plus à facile à saisir qu'une séquence - hexadécimale. - - -user: L'identité de la personne qui a créée ce %%% laisser le terme anglais car il sera affiché - \textit{changeset}. C'est un champ libre de forme, mais la plupart du - temps il contient le nom et l'email de la personne. - - -date: La date et l'heure à laquelle le \textit{changeset} - a été créé, ainsi que le \textit{fuseau horaire} dans laquelle il a été créé. %%%TODO: Translate 'timezone' properly : FUSEAU - (La date et l'heure sont locales à ce \textit{fuseau}, elles indiquent - donc quelle date et heure il était pour la personne qui a créé ce %%%TODO: je suppose (quelle "heure") OUI - \textit{changeset}.) - - -résumé: La première du message que le créateur a associé à - son \textit{changeset} pour le décrire. - - - -Par défaut, la commande hg log n'affiche qu'un résumé, il manque -beaucoup de détails. - - -La figure fournit une représentation graphique -de l'historique du dépôt hello, pour rendre plus facile de voir -dans quelle direction l'historique se déroule\footnote{NdT: \textit{flowing in}.}. -Nous reviendrons régulièrement sur cette représentation dans ce chapitre et -ceux qui suivent. - - - - - XXX add text - Représentation graphique du dépôt hello - \label{fig:tour-basic:history} - - - - -Changesets, révisions, et discuter avec les autres -%%% je propose "colaboration" - - -Comme l'anglais est réputé pour être un langage maladroit, et que l'informatique -est la source de bien des erreurs de terminologies (pourquoi utiliser un -seul terme quand quatre feront l'affaire ?), la gestion de version 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, -%%%TODO: ça ne veut rien dire: il faut supprimer une des personnes : soit "quelqu'un", -% soit "à d'autres personnes" -vous constaterez que souvent le mot \textit{changeset} est contracté simplement -en change ou (à l'écrit) cset, et même parfois un -\textit{changeset} simplement révision, abrégé en rev. - - -Bien que le mot que vous utilisez pour désigner le concept de -\textit{changeset} importe peu, l'identifiant que vous utilisez -pour désigner un changeset \textit{spécifique} a une grande -importance. Rappelez vous que le champ \textit{changeset} affiché par la -commande hg log identifie un \textit{changeset} à la fois avec -un numéro de révision et une séquence hexadécimale. - - - -Le numéro de révision est seulement valable dans ce dépôt, - - -alors que la séquence hexadécimale est un \emph{identifiant - permanent, et invariant } qui pourra toujours être associé au - \textit{changeset} exact de chaque copie de votre dépôt. - - - -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 $1,0,2$. - - -Mercurial utilise les numéros de révision uniquement comme des raccourcis -pratiques. Si vous devez discuter d'un \textit{changeset} avec quelqu'un, -ou identifer un \textit{changeset} pour une quelquonque %%%TODO: our : "pour" ou "ou" -raison (par exemple, un rapport de \textit{bug}), utilisez la séquence -hexadécimale. - - - - -Afficher une révision spécifique - -Pour réduire la sortie de hg log à une seule révision, utilisez -l'option (ou ). 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. - - - -Si vous voulez voir l'historique de plusieurs révisions sans avoir à -les énumérer, vous pouvez utiliser la \textit{range notation} -\footnote{NdT: Il n'est pas aisé de traduire ce terme, donc je le %%%TODO : intervalle de numérotation ? -laisse en anglais} qui vous permet d'exprimer l'idée je veux toutes -les révisions entre $a$ et $b$, inclus. - -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$. - - - - -Informations détaillées - - -Le résumé affiché par hg log est suffisant si vous savez déjà ce %%%TODO: je pense que le premier "si" est de trop : exact -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 \textit{changeset} est bien celui que vous%%%TODO: les propositions sont mal construites : après un "si...." il faut une proposition sans "si... donc ici : "si ... recherchez", ben quoi ? -recherchez. L'option \hgopt{-v} de la commande hg log (ou -\hgopt{--verbose}) vous donne ces informations supplémentaires. - - - -Si vous voulez voir à la fois la description et le contenu d'une -modification, ajouter l'option (ou ). -Ceci affiche le contenu d'une modification comme un diff unifié -\footnote{NdT: \textit{unified diff}} (si vous n'avez jamais vu de diff -unifié avant, consultez la section pour un rapide -survol). - - - - - - - - -Tout sur les options de commandes - - -Avant d'aller plus loin sur le fonctionnement des commandes de Mercurial, -étudions un moment comment elles fonctionnent de manière générale. Vous -trouverez ça probablement utile pour la suite de notre parcours. - - -Mercurial utilise une approche directe et cohérente pour interpréter %%%TODO: une manière d'approche ? -les options que vous passez aux commandes. Il suit une convention commune -à la plupart des systèmes Unix et Linux modernes. - - - -Chaque option a un nom complet. Par exemple, comme nous l'avons déjà - vu, la commande hg log accepte l'option .%%%TODO: commande ou command e\hgcmd...? - - -La plupart des options disposent de noms abrégés. Aussi, au lieu d'utiliser - , vous pouvez utiliser . (Les options qui - n'ont pas de noms abrégés sont généralement rarement utilisées, pour cette raison). - - -Les noms complets commencent par deux tirets (i.e. ), - alors que les options courtes commencent avec un seul (i.e. ). - - -Les noms des options sont cohérents entre les commandes. Par exemple, - chaque commande qui accepte un \textit{changeset ID} ou un numéro de révision - accepte aussi et comme arguments. - %TODO: Small mistake here, shouldn't have log here... shouldn't it ? - - - -Dans les exemples de ce livre, j'utilise les noms abrégés plutôt que les noms -complets. Ceci est une préférence personnelle, pas une recommandation. - - -La plupart des commandes qui affichent une quelconque sortie à l'écran, -afficheront davantage avec l'option (ou ), et -moins avec l'option (ou ). - - - - -Faire et vérifier des modifications - -Maintenant que nous avons une bonne idée des commandes pour consulter -l'historique de Mercurial, regardons comment faire des modifications et -les examiner. - - - -La première chose que nous allons faire c'est isoler notre expérience dans -un dépôt à part. Nous allons utiliser la commande hg clone, mais nous -n'avons pas besoin de faire une copie de dépôt distant. Comme nous avons -déjà une copie locale, nous pouvons juste faire un clone de celle-ci à la -place. C'est beaucoup plus rapide que de faire une copie à travers le -réseau, et un dépôt cloné localement prend également moins d'espace disque. - - - - - -On notera au passage qu'il est souvent considéré comme une bonne pratique -de conserver une copie immaculée du dépôt distant, à partir de laquelle -vous pourrez faire des copies locales temporaires pour créer des bacs à -sable pour chaque tâche sur laquelle vous souhaitez travailler. Ceci vous -permet de travailler sur plusieurs choses en parallèle, chacune isolée les -unes des autres en attendant que ces tâches soient finies et que vous soyez -prêt à les réintégrer. Parce que les copies locales sont peu coûteuses, il -est très rapide de créer ou détruire des dépôts dès que vous en avez besoin. - - -%% Note: la dernière phrase n'est pas une traduction littérale, mais je -%% pense qu'elle exprime plus clairement en français ce que veut dire son -%% équivalent anglais. : OUI - - -Dans notre dépôt my-hello, nous avons un fichier hello.c -qui contient le classique programme hello, world. Nous allons utiliser -l'ancienne et vénérable commande sed pour l'éditer afin qu'il -affiche une seconde ligne à l'écran. (J'utilise sed seulement parce -qu'il est ainsi facile d'écrire des exemples sous forme de script. Comme -vous n'avez pas ces contraintes, vous n'utiliserez probablement pas sed -mais plutôt votre éditeur de texte favori). - - - - - -La commande hg status de Mercurial nous dira de quels fichiers Mercurial -s'occupe au sein de ce dépôt. - -La commande hg status n'affiche rien sur la sortie pour quelques fichiers -mais une ligne commence par M for hello.c. À moins que -vous ne lui indiquiez de le faire, hg status n'affichera aucune sortie -pour les fichiers qui n'ont pas été modifiés. - - -Le caractère M indique que Mercurial a remarqué que nous avions -modifié le fichier hello.c. Nous n'avons pas besoin d'informer -Mercurial que nous allons modifier un fichier avant de le faire, ou que nous -venons de le modifier, il est capable de s'en rendre compte tout seul. - - -C'est pratique de savoir que nous avons modifié hello.c, mais il -serait encore plus pratique de savoir ce que nous avons modifié exactement. Pour -cela, nous avons la commande hg diff. - - - - - - - -Enregister les modifications dans un nouveau \textit{changeset} - -Nous pouvons modifier des fichiers, compiler et tester nos modifications, -et utiliser les commandes hg status et hg diff pour voir les -modifications effectuées, jusqu'au moment où nous serons assez satisfaits -pour décider d'enregistrer notre travail dans un \textit{changeset}. - - -La commande hg commit vous laisse créer un nouveau \textit{changeset}, -nous désignerons généralement cette opération par faire un commit ou -commiter\footnote{NdT: De mon expérience, la plupart des francophones -utilisent régulièrement, à l'oral, cette expression, mais bien évidement -il ne s'agit pas d'un terme de terminologie correcte, ni même français.} - - - -Définir le nom d'utilisateur - -Quand vous exécutez la commande hg commit pour la première fois, elle -n'est pas garantie de réussir. 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 quelle -modification. Mercurial essaye automatiquement de découvrir un nom -d'utilisateur qui ait un minimum de sens pour effectuer l'opération -de \textit{commit} avec. Il va essayer chacune des méthodes suivantes, -dans l'ordre: - - -Si vous spécifiez l'option avec la commande - hg commit, suivi d'un nom d'utilisateur, ceci aura toujours la - priorité sur les autres méthodes ci dessous. - - -Si vous avez défini une variable d'environnement HGUSER, - c'est cette valeur qui est alors utilisée. - - -Si vous créez un fichier nommé .hgrc dans votre - répertoire \textit{home}, avec une entrée username, - c'est la valeur associée qui sera utilisée. Pour voir à quoi - ressemble le contenu de ce fichier regardez la - section ci-dessous. - - -Si vous avez défini une variable d'environnement EMAIL - celle ci sera utilisée ensuite. - - -Enfin, Mercurial interrogera votre système pour trouver votre - nom d'utilisateur local ainsi que le nom de la machine hôte, et il - fabriquera un nom d'utilisateur à partir de ces données. Comme il arrive - souvent que ce genre de noms soit totalement inutile, il vous - préviendra en affichant un message d'avertissement. - - - -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 \textit{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 comme moyen pour \emph{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. - - - -Créer un fichier de configuration pour Mercurial -\label{sec:tour-basic:username} - - -Pour définir un nom d'utilisateur, utilisez votre éditeur de texte favori -pour créer un fichier .hgrc dans votre répertoire \textit{home}. -Mercurial va utiliser ce fichier pour retrouver votre configuration personnelle. -Le contenu initial devrait ressembler à ceci: - - - # 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. - - - - -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 -<<<<<<< local -suivent est d'utiliser leurs noms suivies de leurs adresses emails, -comme montrée ci-dessus: - - - - Le mécanisme interne du serveur \textit{web} intégré à Mercurial, - masque les adresses emails, pour rendre plus difficile leurs - récupérations par les outils utilisés par les \textit{spammmers}. - Ceci réduit la probabilité que de recevoir encore plus de - \textit{spam} si vous vous publiez un dépôt sur internet. - - - - - - -Rédiger un message de \textit{commit} - -Lorsqu'on effectue une opération de \textit{commit}, Mercurial -lance automatiquement un éditeur de texte pour permettre de saisir -un message qui décrira les modifications effectuées dans ce -\textit{changeset}. Ce message est nommé le \emph{message de -\textit{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. - - - -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:. - - - empty line - 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 à \textit{commiter}. Modifier ou effacer ces lignes n'a -aucune conséquence sur l'opération de \textit{commit}. - - - - -Rédiger un message \textit{approprié} - -Comme hg log n'affiche que la première ligne du message de -\textit{commit} par défaut, il est souvent considéré comme une bonne -pratique de rédiger des messages de \textit{commit} qui tiennent -sur une seule ligne. Voilà un exemple concret de message de -\textit{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 - - - -A 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 \textit{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. - - - - -Annuler un \textit{commit} - -Si, en rédigeant le message, vous décidez que finalement vous ne -voulez pas effectuer ce \textit{commit}, il suffit de quitter simplement -l'éditeur sans sauver. Ceci n'aura aucune conséquence sur le dépôt ou -les fichiers de l'espace de travail. - - -Si vous exécuter la commande hg commit sans aucun argument, elle -enregistre toutes les modifications que vous avez faites, comme le montre -les commandes hg status et hg diff. - - - - -Admirer votre travail - -Une fois que votre \textit{commit} est terminé, vous pouvez utiliser -la commande hg tip pour afficher le \textit{changeset} que nous -venons 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. - -On fait couramment référence à la dernière révision du dépôt comme -étant la révision \textit{tip}, ou plus simplement le \textit{tip}. - - - - - -Partager ses modifications - -Nous avons mentionné plus haut que les dépôts de Mercurial -sont autosuffisants. Ce qui signifie que le \textit{changeset} -que vous venez de créer existe seulement dans votre répertoire -my-hello. Étudions comment propager cette modification -dans d'autres dépôts. - - - -Récupérer les modifications d'autres dépôts -\label{sec:tour:pull} - - -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. - - - - - -Nous allons utiliser la commande hg pull pour apporter 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. - -(Bien évidement, quelqu'un pourrait ajouter des modifications -supplémentaires sur le dépôt que nous étudions avec hg incoming, -avant que nous ayons effectué notre hg pull, avec comme -triste conséquence que nous aurons récupéré des modifications que -nous n'attendions pas.) - - -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. - - - -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 -placer ces modifications dans l'espace de travail. - - - - -Mise à jour de l'espace de travail - -Nous avons jusqu'à maintenant grossièrement définie 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 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. - - - -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 utilisez 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&emdash;pour chercher l'origine d'un \textit{bug}, par exemple&emdash;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 \textit{pull} sont très souvent -suivies d'un \textit{update}, Mercurial vous permet de combiner les -deux aisément en passant l'option à la commande -hg pull - - - hg pull -u - - - -Si vous étudiez de nouveau la sortie de la commande hg pull dans -la section quand nous l'avons exécutée sans l'option -, 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: - - - - (run 'hg update' to get a working copy) - - - -Pour découvrir sur quelle révision de l'espace de travail on est, utilisez -la commande hg parents. - -Si vous regardez de nouveau le dessin , vous -<<<<<<< local -verrez les flèches reliant entre eux les \textit{changeset}. 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. - - -L'espace de travail a un parent de la même manière, c'est ce \textit{changeset} -que l'espace de travail contient à ce moment. -%%%TODO : difficile à comprendre : l'espace de travail a un parent, de la même manière, c'est ce changeset que l'espace... - - -Pour mettre à jour l'espace de travail d'une révision particulière, -indiquez un numéro de révision ou un \textit{changeset ID} à la commande -hg update. - -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évsion \textit{tip}, comme montré dans l'exemple -ci dessus lors du second appel à hg update. - - - - -Transférer les modifications à un autre dépôt - -Mercurial vous laisse transférer les modifications à 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\footnote{NdT: Les francophones disent souvent -pousser tout simplement} nos modifications. - -La commande hg outgoing nous indique quels changements nous -allons transférer vers l'autre serveur ? - -Et la commande hg push effectue réellement le transfert. - -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). - - -Qu'est ce qui se passe 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. - - - - - -Partager ses modifications à travers le réseau - -Les commandes que nous avons étudiées dans les sections précédentes -ne sont pas limitées aux dépôt 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. - - - -Dans cet exemple, nous allons voir quels changements nous pourrions -transférer vers le dépôt distant, mais le dépôt est, de manière tout -à fait compréhensible, pas configuré pour accepter des modifications -d'utilisateurs anonymes. - - - - - + + Windows + + La meilleur 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'un interface graphique. + + + + + Mac OS X + + Lee Cantey publie un installeur de Mercurial pour Mac OS X + sur http://mercurial.berkwood.com. + + + + Linux + + 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 uniques 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. + + + Ubuntu et Debian: + apt-get install mercurial + Fedora: + yum install mercurial + Gentoo: + emerge mercurial + OpenSUSE: + zypper install mercurial + + + + + Solaris + + SunFreeWare, à http://www.sunfreeware.com, + fournit des paquet précompilés pour Mercurial. + + + + + Commencer à utiliser Mercurial + + Pour commencer, nous utiliserons la commande hg + version pour vérifier si Mercurial est installé proprement. Les + informations affichées sur la version ne sont pas réellement importantes en + soit, c'est surtout de savoir si elles s'affichent qui nous + intéresse. + + &interaction.tour.version; + + + L'aide intégrée + + 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. + + &interaction.tour.help; + + Pour un niveau d'informations encore plus détaillées + (ce dont vous aurez rarement besoin), exécuter hg + help . L'option + est l'abréviation de + , et indique à Mercurial + d'afficher plus d'informations que d'habitude. + + + + + Travailler avec un dépôt + + Avec Mercurial, tout se déroule au sein du + dépôt. Le dépôt d'un projet contient tous + les fichiers qui appartiennent au projet. + + Il n'y a rien de particulièrement magique au sujet de + ce dépôt, c'est simplement une arborescence sur votre système de fichiers + de Mercurial traite de manière spéciale. Vous pouvez renommer ou effacer + ce répertoire à n'impporte quel moment, en utilisant la ligne de commande + ou votre explorateur de fichiers. + + + Faire une copie locale de votre dépôt + + 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. + + &interaction.tour.clone; + + Un avantage de la commande hg clone est que, comme nous l'avons vu ci + dessus, elle nous permet de faire 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. + + &interaction.tour.ls; + + 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é clôné, mais il ne communique pas avec + ce dernier, ou un autre, à moins que vous ne lui demandiez. + + Ce que tout ceci signifie pour le moment est 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. + + + + Quel est le contenu d'un dépôt ? + + 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. + + &interaction.tour.ls-a; + + 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. + + + + + Une promenade dans l'historique + + Une des premières choses que vous aurez envie + de faire avec un nouveau dépôt, sera de comprendre son historique. + La commande hg log vous donne une + vue de l'historique. + + &interaction.tour.log; --> + + Par défaut, cette commande affiche à l'écran un bref paragraphe pour chaque + révision enregistrée pour ce projet. Dans la terminologie de Mercurial, nous + appelons chacun de ces évènements enregistrés un changeset, parce + qu'il contient un ensemble de modifications sur plusieurs fichiers. + + La commande hg log affiche + ainsi ces informations: + + + changeset: Ce champ contient + un nombre, séparé par deux points (:), d'une chaine hexadécimale. Il + s'agit en fait d'identifiants d'un changeset. Il y a + deux identifiants car le numéro de la révision est plus court et plus à + facile à saisir qu'une séquence hexadécimale. + + user: L'identité de la personne + qui a créée ce %%% laisser le terme anglais car il sera affiché + changeset. C'est un champ libre de forme, mais la plupart du + temps il contient le nom et l'email de la personne. + + date: La date et l'heure à + laquelle le \textit{changeset a été créé, ainsi que le fuseau horaire dans + laquelle il a été créé. . (La + date et l'heure sont locales à ce \textit{fuseau}, elles indiquent donc quelle + date et heure il était pour la personne qui a créé ce changeset. + + résumé: La première du + message que le créateur a associé à son changeset pour le décrire. + + + + + Par défaut, la commande hg log + n'affiche qu'un résumé, il manque + beaucoup de détails. + + La figure fournit une + représentation graphique de l'historique du dépôt hello + , pour rendre plus facile de voir dans quelle direction + l'historique se déroule. Nous reviendrons régulièrement + sur cette représentation dans ce chapitre et ceux qui suivent. + + +

+ Graphical history of the <filename + class="directory">hello</filename> repository + + + XXX add text + + + + + + Changesets, révisions, et collaboration + + Comme l'anglais est réputé pour être un langage maladroit, et que l'informatique + est la source de bien des erreurs de terminologies (pourquoi utiliser un + seul terme quand quatre feront l'affaire ?), la gestion de version 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 un + changeset simplement 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. + + + Le numéro de révision est seulement + valable dans ce dépôt, + La séquence hexadécimale est un + identifiant permanent, et invariant qui + pourra toujours être associé au changeset exact de chaque + copie de votre dépôt. + + 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 \textit{changeset} avec quelqu'un, + ou identifer un \textit{changeset} pour une quelquonque %%%TODO: our : "pour" ou "ou" + raison (par exemple, un rapport de \textit{bug}), utilisez la séquence + hexadécimale. + + + + Afficher une révision spécifique + + Pour réduire la sortie de hg log + à une seule révision, utilisez l'option (ou ). 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. + + &interaction.tour.log-r; + + Si vous voulez voir l'historique de plusieurs + révisions sans avoir à les énumérer, vous pouvez utiliser la + intervalle de numérotation qui vous permet + d'exprimer l'idée je veux toutes les révisions entre $a$ + et $b$, inclus. + + &interaction.tour.log.range; + + 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. + + + + Informations détaillées + + 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 \hgopt{-v} de la commande hg + log (ou ) vous + donne ces informations supplémentaires. + + &interaction.tour.log-v; --> + + Si vous voulez voir à la fois la description + et le contenu d'une modification, ajouter l'option (ou ). Ceci affiche le contenu d'une modification + comme un diff unifié + + (si vous n'avez jamais vu de diff unifié avant, consultez la + section pour un rapide + survol). + + &interaction.tour.log-vp; + + L'option option + est incroyablement utile, il est donc important dans s'en + rappeller. + + + + + Tout sur les options de commandes + + Avant d'aller plus loin sur le fonctionnement + des commandes de Mercurial, étudions un moment comment elles + fonctionnent de manière générale. Vous trouverez ça probablement + utile pour la suite de notre parcours. + + Mercurial utilise une approche directe et cohérente + pour interpréter les + options que vous passez aux commandes. Il suit une convention commune + à la plupart des systèmes Unix et Linux modernes. + + + Chaque option a un nom complet. Par exemple, + comme nous l'avons déjà vu, la commande hg + log accepte l'option . + + La plupart des options disposent de + noms abrégés. Aussi, au lieu d'utiliser , vous pouvez utiliser . + (Les options qui n'ont pas de noms abrégés sont généralement + rarement utilisées). + + Les noms complets commencent par deux + tirets (i.e. ), + alors que les options courtes commencent avec un seul (i.e. + ). + + Les noms des options sont cohérents + entre les commandes. Par exemple, chaque commande qui accepte + un changeset ID ou un numéro de révision accepte aussi et comme arguments. + + + + Dans les exemples de ce livre, j'utilise les noms abrégés + plutôt que les noms complets. Ceci est une préférence personnelle, pas + une recommandation. + + La plupart des commandes qui affichent une quelconque sortie + à l'écran, afficheront davantage avec l'option (ou ), et + moins avec l'option (ou + ). + + + Option naming consistency + + Presque toujours, les commandes de Mercurial utilise + des noms d'options cohérentes pour référer à des concepts identiques. + Par exemple, si une commande concerne les changesets, vous les + identifierais toujours avec l'option . Cette utilisation cohérente des noms + d'options permet de mémoriser plus facilement quelles options accepte + une commande. + + + + + + Faire et vérifier des modifications + + Maintenant que nous avons une bonne idée des + commandes pour consulter l'historique de Mercurial, regardons + comment faire des modifications et les examiner. + + La première chose que nous allons faire + c'est isoler notre expérience dans un dépôt à part. Nous + allons utiliser la commande hg + clone, mais nous n'avons pas besoin de faire une + copie de dépôt distant. Comme nous avons déjà une copie locale, + nous pouvons juste faire un clone de celle-ci à la place. C'est + beaucoup plus rapide que de faire une copie à travers le réseau, + et un dépôt cloné localement prend également moins d'espace + disque. + L'économie d'espace disque apparait clairement + quand les dépôts source et destination sont sur le même système + de fichier, où dans ce cas, Mercurial utilisera des liens physiques + pour effectuer des partages copie-lors-des-écritures de ses + métadonnées internes. Si cette explication ne signifie rien pour + vous, ne vous inquietez pas: tout ceci se passe de manière + transparente et automatiquement, et vous n'avez pas du tout + besoin de comprendre ceci. + . + + &interaction.tour.reclone; + + On notera au passage qu'il est souvent considéré + comme une bonne pratique de conserver une copie immaculée + du dépôt distant, à partir de laquelle vous pourrez faire des + copies locales temporaires pour créer des bacs à sable + pour chaque tâche sur laquelle vous souhaitez travailler. Ceci + vous permet de travailler sur plusieurs choses en parallèle, + chacune isolée les unes des autres en attendant que ces tâches + soient finies et que vous soyez prêt à les réintégrer. Parce + que les copies locales sont peu coûteuses, il est très rapide + de créer ou détruire des dépôts dès que vous en avez besoin. + + + Dans notre my-hello + dépôts, nous avons un fichier hello.c + qui contient le classique hello, world. + + + &interaction.tour.cat1; + + Editons ce fichier pour qu'il affiche une autre + ligne sur la sortie standard. + + &interaction.tour.cat2; + + La commande Mercurial hg status + nous dira ce que Mercurial sait des fichiers du dépôts. + + + &interaction.tour.status; + + La commande hg status + n'affichera pas le contenu des fichiers, mais une ligne commençant + par M pour hello.c + . A moins que vous lui demandiez, la commande hg status n'affichera aucune informations + sur les fichiers que vous n'avez pas modifié. + + Le M indique que + Mercurial a remarqué que nous avons modifié le fichier + hello.c. Nous n'avons pas besoin + d'informer Mercurial que nous allons modifier le + fichier avant de commencer à le faire, ou que nous avions modifier le + fichier avant de le faire, il est capable de découvrir ça tout seul. + + + C'est déjà pratique de savoir que nous avons modifié le + fichier hello.c, mais nous préférerions savoir + exactement ce que nous avons changé. Pour ceci, nous + utilisons la commande hg diff. + + &interaction.tour.diff; + + + Comprendre les patches + + Penser à jeter un oeil au site si vous n'arrivez pas à lire la sortie + ci-dessus. + + + + Enregister vos modifications dans une nouvelle révision + + Nous pouvons modifier des fichiers, compiler et + tester nos modifications, et utiliser les commandes + hg status et hg + diff pour voir les modifications effectuées, jusqu'au + moment où nous serons assez satisfaits + pour décider d'enregistrer notre travail dans un \textit{changeset}. + + + La commande hg commit + vous laisse créer une nouvelle révision, nous désignerons généralement + cette opération par faire un commit ou committer + . + + + Définir le nom d'utilisateur + + 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 quelle 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 vous spécifiez l'option avec la commande + hg commit, suivi d'un nom + d'utilisateur, ceci aura toujours la priorité sur les autres + méthodes ci dessous. + Si vous avez défini une variable d'environnement + HGUSER, c'est cette valeur qui est alors utilisée. + Si vous créez un fichier nommé + .hgrc dans votre + répertoire \textit{home}, avec une entrée username, c'est la valeur associée + qui sera utilisée. Pour voir à quoi ressemble le contenu de ce fichier + regardez la section + ci-dessous. + Si vous avez défini une variable + d'environnement EMAIL celle ci sera utilisée ensuite. + Enfin, Mercurial interrogera votre système pour + trouver votre nom d'utilisateur local ainsi que le nom de la machine hôte, + et il fabriquera un nom d'utilisateur à partir de ces données. Comme + il arrive souvent que ce genre de noms soit totalement inutile, il vous + préviendra en affichant un message d'avertissement. + + + 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 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. + + + 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: + + + <quote>Home directory</quote> on 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 quelle 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. + + + + 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 leurs noms suivies de leurs adresses emails, + comme montrée ci-dessus: + + 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. + + + + + Rédiger un message de \textit{commit} + + 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. + + &interaction.tour.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 à \textit{commiter}. Modifier ou effacer ces lignes n'a + aucune conséquence sur l'opération de commit. + + + + + Rédiger un message \textit{approprié} + + 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 + + + A 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 tout 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 soumettez pas de manière explicite les noms des fichiers à + committer à 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 + attendre qu'elle opère uniquement le répertoire courant et ses sous + répertoires. + + + + Annuler un \textit{commit} + + 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 sauver. Ceci n'aura aucune + conséquence sur le dépôt ou les fichiers du répertoire de + travail. + + + + + Admirer votre travail + + Une fois que votre \textit{commit} est terminé, vous pouvez utiliser + la commande hg tip pour afficher le \textit{changeset} que nous + venons 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. + + &interaction.tour.tip; + + 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 mêmes options que + hg log, ainsi ci dessus inplique soit + verbeux, + veux dire affiche le patch. L'utilisation de l'option + pour afficher un patch est un + autre exemple de la cohérence des commandes évoquée plus tôt. + + + + + Partager ses modifications + + Nous avons mentionné plus haut que les dépôts + de Mercurial sont autosuffisants. Ce qui signifie que la nouvelle + révision que vous venez de créer n'existe seulement dans votre + répertoire my-hello. Étudions + comment propager cette modification dans d'autres dépôts. + + + Récupérer les modifications d'autres dépôts + + 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. + + &interaction.tour.clone-pull; + + 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. + + &interaction.tour.incoming; + + 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. + + &interaction.tour.pull; + + 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 placer 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. Suppossons que vous récupériez les modifications d'un dépôt + situé quelque part sur le réeau. 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 signigie que vous + récupérer plus de révision que ce que vous aviez regarder en utilisant + la commande hg incoming. + Si vous voulez seulement récupérer ce que vous aviez + vérifier à l'aide de la commande hg + incoming, ou que pour d'autres raisons vous souhaitiez ne + récupérer qu'un sous ensemble des révisions supplémentaires + disponibles, indiquant simplement les modifications que vous souhaitez + récupérer par leurs ID de révision, soit hg pull + -r7e95bb. + + + + Mise à jour de l'espace de travail + + Nous a:vons jusqu'à maintenant grossièrement définie 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 + 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. + + &interaction.tour.update; + + 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 utilisez 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&emdash;pour chercher l'origine d'un bug, par exemple&emdash;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 + à la commande hg pull. + + Si vous étudiez de nouveau la sortie de la commande hg pull dans la section quand nous l'avons exécutée sans l'option + , 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. + + &interaction.tour.parents; + + Si vous regardez de nouveau le dessin , vous verrez les flèches reliant + entre eux 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 \textit{changeset ID} à la commande + hg update. + + &interaction.tour.older; + + 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évsion \textit{tip}, comme montré dans l'exemple ci + dessus lors du second appel à hg update. + + + + Transférer les modifications à un autre dépôt + + Mercurial vous laisse transférer les modifications + à 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. + + &interaction.tour.clone-push; + + La commande hg outgoing + nous indique quels changements nous allons transférer vers l'autre + serveur ? + + &interaction.tour.outgoing; + + Et la commande hg push + effectue réellement le transfert. + + &interaction.tour.push; + + 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 travail dessus, nous risquerions + de perturber son travail. + + Qu'est ce qui se passe 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. + + &interaction.tour.push.nothing; + + + + + Emplacements par défaut + + 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 ces emplacements 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&emdash;et souvent + pratique&emdash;d'avoir un emplacement par défaut pour la commande + hg push et la commande hg outgoing + différent de celui des commandes hg pull et des + 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 + + + + Partager ses modifications à travers le réseau + + Les commandes que nous avons étudiées dans les sections + précédentes ne sont pas limitées aux dépôt 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. + + &interaction.tour.outgoing.net; + + Dans cet exemple, nous allons voir quels changements + nous pourrions transférer vers le dépôt distant, mais le dépôt est, + de manière tout à fait compréhensible, pas configuré pour accepter + des modifications d'utilisateurs anonymes. + + &interaction.tour.push.net; + + + + + Commencer un nouveau projetw + + Il est tout aussi aisé de commencer un nouveau projet + que de travailler sur un qui existe déjà. La commande + hg init créer un nouveau dépôt Mercurial, + vide. + + &interaction.ch01-new.init; + + Ceci créer simplement un répertoire nommée + myproject dans le répertoire courant. + + &interaction.ch01-new.ls; + + Nous pouvons dire que myproject + est un dépôt Mercurial car il contient un répertoire + .hg. + + &interaction.ch01-new.ls2; + + Si vous voulons ajouter quelques fichiers préexistants + dans ce dépôt, il suffit de les recopier dans le répertoire de travail, + et demander à Mercurial de commencer les suivre en utilisant la + commande hg add. + + &interaction.ch01-new.add; + + Une fois que nous sommes satisfait de notre projet, + nous pouvons commencer à ajouter nos révisions. + + &interaction.ch01-new.commit; + + Il ne prend que quelques instants pour commencer à + utiliser Mercurial sur un nouveau projet, ce qui fait aussi de ses + points forts. Travailler avec une gestion de révision devient très + facile, nous pouvons même l'utiliser pour les plus petits projets où + nous aurions probablement jamais penser utiliser un outils aussi + complexe. + \ No newline at end of file +-->