# HG changeset patch # User Romain PELISSE # Date 1252771106 -7200 # Node ID 56953b292c8aa5efb9f0e77da3628c53c87588ac # Parent c40dac4f63d8e3c8f779edfa013b84a289b7b04b finishing fixes on ch03 due to transformation from Latex files diff -r c40dac4f63d8 -r 56953b292c8a fr/ch03-tour-merge.xml --- a/fr/ch03-tour-merge.xml Fri Sep 04 18:55:53 2009 +0200 +++ b/fr/ch03-tour-merge.xml Sat Sep 12 17:58:26 2009 +0200 @@ -15,364 +15,433 @@ travaille iavec un gestionnaire de source distribué. - Alice et Bob ont chacun une copie personnelle du dépôt d'un - projet sur lequel ils collaborent. Alice corrige un \textit{bug} - dans son dépôt, et Bob ajoute une nouvelle fonctionnalité dans le - sien. Ils veulent un dépôt partagé avec à la fois le correctif du - \textit{bug} et la nouvelle fonctionnalité. - -Je travaille régulièrement sur plusieurs tâches différentes sur - un seul projet en même temps, chacun isolé dans son propre dépôt. - Travailler ainsi signifie que je dois régulièrement fusionner une - partie de mon code avec celui des autres. - - -Parce que la fusion est une opération si commune à réaliser, -Mercurial la rend facile. Étudions ensemble le déroulement des opérations. -Nous commencerons encore par faire un clone d'un autre dépôt (vous voyez -que l'on fait ça tout le temps ?) puis nous ferons quelques modifications -dessus. - -Nous devrions avoir maintenant deux copies de hello.c avec -des contenus différents. Les historiques de ces deux dépôts ont aussi -divergés, comme illustré dans la figure . - - - - - - XXX add text - Historiques récent divergents des dépôts \dirname{my-hello - et my-new-hello} - \label{fig:tour-merge:sep-repos} - - -Nous savons déjà que récupérer les modifications depuis notre dépôt -my-hello n'aura aucun effet sur l'espace de travail. - - - - - -Néanmoins, la commande hg pull nous indique quelque chose au -sujet des heads. - - - -\textit{Head changesets} - -Une \textit{head}\footnote{NdT: Je garde \textit{head} que j'accorde -au féminin comme la coutume orale l'a imposé.} est un \textit{changeset} -sans descendants, ou enfants, comme on les désigne parfois. La révision -\textit{tip} est une \textit{head}, car la dernière révision dans un dépôt -n'a aucun enfant, mais il est important de noter qu'un dépôt peut contenir -plus d'une \textit{head}. - - - - - XXX add text - \caption{Contenu d'un dépôt après avoir transféré le contenu du dépôt - my-hello dans le dépôt my-new-hello} - \label{fig:tour-merge:pull} - - - -Dans la figure , vous pouvez constater l'effet -d'un \textit{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 , -vous pouvez voir que le \textit{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 \textit{changeset}.) Vous -pouvez voir les \texit{heads} présentes dans le dépôt en utilisant la -commande hg heads. - - - - - -Effectuer la fusion - -Que se passe-t-il quand vous essayez d'utiliser la commande hg update -pour mettre à jour votre espace de travail au nouveau \textit{tip}. - -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 \textit{heads}. - - - - - - XXX add text - \caption{Espace de travail et dépôt lors d'une fusion, et dans le - \textit{commit} qui suit.} - \label{fig:tour-merge:merge} - - - -Ceci met à jour l'espace de travail de manière à ce qu'il contienne -les modifications des deux \textit{heads}, ce qui apparaît dans -les sorties de la commande hg parents et le contenu de -hello.c. - - - - - -Effectuer le \textit{commit} du résultat de la fusion - -Dès l'instant où vous avez effectué une fusion, hg parents vous -affichera deux parents, avant que vous n'exécutiez la commande -hg commit sur le résultat de la fusion. - -Nous avons maintenant un nouveau \textit{tip}, remarquer qu'il contient -à la fois nos anciennes \textit{heads} et leurs parents. Ce sont -les mêmes révisions que nous avions affichées avec la commande -hg parents. - - - -Dans la figure , 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 \textit{commit}. Pendant la fusion, l'espace de travail, -qui a deux \texit{changesets} comme parents, voit ces derniers devenir le parent -%%% TODO: le parent ou "les parents" : plus logique mais si il reste seulement -%%% un changeset, alors c'est effectivement un parent (le changeset est hermaphrodite) -d'un nouveau \textit{changeset}. - - - - - -Fusionner les modifications en conflit - -La plupart des fusions sont assez simple à réaliser, mais parfois -vous vous retrouverez à fusionner des fichiers où la modification touche -la même portion de code, au sein d'un même fichier. À moins que ces -modification ne soient identiques, ceci aboutira à un conflit, -et vous devrez décider comment réconcilier les différentes modifications -dans un tout cohérent. - - - - - XXX add text - Modifications conflictuelles dans un document - \label{fig:tour-merge:conflict} - - - -La figure illustre un cas de modifications -conflictuelles dans un document. Nous avons commencé avec une version simple -de ce fichier, puis nous avons ajouté des modifications, pendant que -quelqu'un d'autre modifiait le même texte. Notre tâche dans la résolution -du conflit est de décider à quoi le fichier devrait ressembler. - - -Mercurial n'a pas de mécanisme interne pour gérer les conflits. -À la place, il exécute un programme externe appelé hgmerge. -Il s'agit d'un script shell qui est embarqué par Mercurial, vous -pouvez le modifier si vous le voulez. Ce qu'il fait par défaut est -d'essayer de trouver un des différents outils de fusion qui seront -probablement installés sur le système. Il commence par les outils -totalement automatiques, et si ils échouent (parce que la résolution -du conflit nécessite une intervention humaine) ou si ils sont absents, -le script tente d'exécuter certains outils graphiques de fusion. - - -Il est aussi possible de demander à Mercurial d'exécuter un autre -programme ou un autre script au lieu de la commande hgmerge, -en définissant la variable d'environnement HGMERGE avec le nom -du programme de votre choix. - - - -Utiliser un outil graphique de fusion - -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 . Cet outil -effectue une fusion \textit{three-way}, car il y a trois différentes -versions du fichier qui nous intéresse. Le fichier découpe la partie -supérieure de la fenêtre en trois panneaux: - - - -A gauche on la version de base du fichier, soit la plus - récente version des deux versions qu'on souhaite fusionner. - - -Au centre, il y a notre version du fichier, avec le contenu - que nous avons modifié. - - -Sur la droite, on trouve leur version du fichier, celui qui - contient le \textit{changeset} que nous souhaitons intégré. - - - -Dans le panneau en dessous, on trouve le résultat actuel de notre -fusion. Notre tâche consiste donc à remplacement tous les textes en rouges, -qui indiquent des conflits non résolus, avec une fusion manuelle et pertinente -de notre version et de la leur. - - -Tous 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. - - - - - XXX add text - Utilisation de \command{kdiff3 pour fusionner différentes versions - d'un fichier.} - \label{fig:tour-merge:kdiff3} - - - -Pour chaque portion de fichier posant problème, nous pouvons choisir -de résoudre le conflit en utilisant une combinaison -de texte depuis la version de base, la notre, 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 -en parler de tous ici. Leurs disponibilités varient selon les plate formes -ainsi que leurs avantages et inconvénients. La plupart sont optimisé pour -la fusion de fichier contenant un texte plat, certains sont spécialisé -dans un format de fichier précis (généralement XML). - - - - -Un exemple concret - -Dans cet exemple, nous allons reproduire la modification de l'historique -du fichier de la figure ci dessus. Commençons -par créer un dépôt avec une version de base de notre document. - - - -Créons un clone de ce dépôt et faisons une modification dans le fichier. - -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 \textit{merge} 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). - -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 \textit{merge}. - - - -Dans cette exemple, je n'utiliserais pas la commande Mercurial -habituelle hgmerge pour effectuer le \textit{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 embarquée par de nombreux systèmes à la Unix. -Si vous exécutez cet exemple depuis votre ordinateur, ne vous -occupez pas de définir HGMERGE. - -Parce que merge ne peut pas résoudre les modifications -conflictuelles, il laisse des marqueurs de différences -\footnote{NdT: Oui, je traduis \textit{merge markers} par un sens -inverse en Français, mais je pense vraiment que c'est plus clair -comme ça...} à l'intérieur du fichier qui a des conflits, indiquant -clairement quelles lignes sont en conflits, 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 le \textit{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 le \textit{merge} automatique ou manuel é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 \textit{commit} du fichier: - - - - - - -Simplification de la séquence pull-merge-commit -\label{sec:tour-merge:fetch} - - -La procédure pour effectuer la fusion indiquée ci-dessus est simple, -mais requiert le lancement de trois commandes à la suite. - - - hg pull - hg merge - hg commit -m 'Merged remote changes' - - - -Lors du \textit{commit} final, vous devez également saisir un message, -qui aura vraisemblablement assez peu d'intérêt. - - -Il serait assez sympathique de pouvoir réduire le nombre d'opérations -nécessaire, si possible. De fait Mercurial est fourni avec une -extension appelé fetch qui fait justement cela. - - -Mercurial fourni un mécanisme d'extension flexible qui permet à chacun -d'étendre ces fonctionnalités, tout en conservant le cœur de Mercurial -léger et facile à utiliser. Certains extensions ajoutent de nouvelles -commandes que vous pouvez utiliser en ligne de commande, alors que -d'autres travaillent en coulisse, par exemple en ajoutant des -possibilités au serveur. - - -L'extension fetch ajoute une nouvelle commande nommée, sans -surprise, hg fetch. Cette extension résulte en une combinaison -de hg pull, hg update and hg merge. Elle commence par -récupérer les modifications d'un autre dépôt dans le dépôt courant. -Si elle trouve que les modifications ajoutent une nouvelle \textit{head}, -elle effectue un \textit{merge}, et ensuite \texit{commit} le résultat -du \textit{merge} avec un message généré automatiquement. Si aucune -\textit{head} n'ont été ajouté, elle met à jour le répertoire de travail -au niveau du nouveau \textit{changeset} \textit{tip}. - - - -Activer l'extension fetch est facile. Modifiez votre .hgrc, -et soit allez à la section extensions soit créer une -section extensions. Ensuite ajoutez une ligne qui consiste -simplement en \Verb+fetch =. - - - - [extensions] - fetch = - - -(Normalement, sur la partie droite de = devrait apparaître -le chemin de l'extension, mais étant donné que l'extension fetch -fait partie de la distribution standard, Mercurial sait où la trouver.) - - - + + Alice et Bob ont chacun une copie personnelle du dépôt d'un + projet sur lequel ils collaborent. Alice corrige un bug + dans son dépôt, et Bob ajoute une nouvelle fonctionnalité dans le + sien. Ils veulent un dépôt partagé avec à la fois le correctif du + bug et la nouvelle fonctionnalité. + + + Je travaille régulièrement sur plusieurs tâches différentes sur + un seul projet en même temps, chacun isolé dans son propre dépôt. + Travailler ainsi signifie que je dois régulièrement fusionner une + partie de mon code avec celui des autres. + + + + Parce que la fusion est une opération si commune à réaliser, + Mercurial la rend facile. Étudions ensemble le déroulement des + opérations. Nous commencerons encore par faire un clone d'un autre + dépôt (vous voyez que l'on fait ça tout le temps ?) puis nous ferons + quelques modifications dessus. + + &interaction.tour.merge.clone; + + Nous devrions avoir maintenant deux copies de + hello.c avec des contenus différents. Les + historiques de ces deux dépôts ont aussi divergés, comme illustré dans + la figure . + + &interaction.tour.merge.cat1; + + Et ici est notre légèrement différente version du + dépôt. + + &interaction.tour.merge.cat2; + +
+ Historique divergent des dépôts <filename + class="directory">my-hello</filename> et <filename + class="directory">my-new-hello</filename>. + + + XXX ajoute un test + +
+ + Nous savons déjà que récupérer les modifications depuis + notre dépôt my-hello n'aura + aucun effet sur l'espace de travail. + + &interaction.tour.merge.pull; + + Néanmoins, la commande hg + pull nous indique quelque chose au sujet des + heads. + + + Les révisions 'heads' + + Rappellez 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 "head". + +
+ Contenu du dépôt après une récupération ("pull") depuis le + dépôt <filename + class="directory">my-hello</filename> vers le dépôt <filename + class="directory">my-new-hello</filename> + + + + + XXX ajoute un texte + +
+ + Dans la figure , + vous pouvez constater l'effet d'un \textit{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 , vous pouvez voir que le + 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 \textit{changeset}.) Vous pouvez voir les "heads" + présentes dans le dépôt en utilisant la commande hg heads. + + &interaction.tour.merge.heads; + + + + Effectuer la fusion + + Que se passe-t-il quand vous essayez d'utiliser la + commande hg update pour mettre à + jour votre espace de travail au nouveau "tip" + + &interaction.tour.merge.update; + + + 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. + + &interaction.tour.merge.merge; + + 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 ne provenance des + deux "heads", ce qui est indiqué par la + la sortie de la commande hg + parents et le contenu du fichier + hello.c. + + &interaction.tour.merge.parents; + + + + Effectuer l'ajout (commit) du résultat de la fusion + + 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. + + &interaction.tour.merge.commit; + + Nous avons maintenant un nouveau tip, remarquer 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. + + &interaction.tour.merge.tip; + + Dans la figure , + 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). + +
+ Working directory and repository during merge, and + following commit + + + + + XXX ajoute texte + +
+ + + + + + Fusionner les modifications en conflit + + La plupart des fusions sont assez simple à réaliser, mais + parfois vous vous retrouverez à fusionner des fichiers où la modification + touche la même portion de code, au sein d'un même fichier. À moins + que ces modification ne soient identiques, ceci aboutira à un + conflit, et vous devrez décider comment réconcilier + les différentes modifications dans un tout cohérent. + +
+ Modifications en conflits dans un document + + + XXX ajoute texte + +
+ + La figure + illustre un cas de modifications conflictuelles dans un document. Nous + avons commencé avec une version simple de ce fichier, puis nous avons + ajouté des modifications, pendant que quelqu'un d'autre modifiait le même + texte. Notre tâche dans la résolution du conflit est de décider à quoi le + fichier devrait ressembler. + + Mercurial n'a pas de mécanisme interne pour gérer + les conflits. À la place, il exécute un programme externe appelé + hgmerge. Il s'agit d'un script shell qui est + embarqué par Mercurial, vous pouvez le modifier si vous le voulez. + Ce qu'il fait par défaut est d'essayer de trouver un des différents + outils de fusion qui seront probablement installés sur le système. + Il commence par les outils totalement automatiques, et si ils + échouent (parce que la résolution du conflit nécessite une + intervention humaine) ou si ils sont absents, le script tente + d'exécuter certains outils graphiques de fusion. + + Il est aussi possible de demander à Mercurial d'exécuter + un autre programme ou un autre script en définissant la variable + d'environnement HGMERGE avec le nom + du programme de votre choix. + + + Utiliser un outil graphique de fusion + + 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 . Cet outil + effectue une fusion \textit{three-way}, car il y a + trois différentes versions du fichier qui nous intéresse. Le fichier + découpe la partie supérieure de la fenêtre en trois panneaux: + + A gauche on la version de + base du fichier, soit la plus récente version + des deux versions qu'on souhaite fusionner. + Au centre, il y a notre + version du fichier, avec le contenu que nous avons modifié. + Sur la droite, on trouve + leur version du fichier, celui qui contient la + révision que nous souhaitons intégré. + + Dans le panneau en dessous, on trouve le + résultat actuel de notre fusion. Notre tâche + consiste donc à remplacement tous les textes en rouges, + qui indiquent des conflits non résolus, avec une fusion manuelle et + pertinente de notre version et de la leur. + + + Tous 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. + +
+ Utiliser <command>kdiff3</command> pour fusionner les + différentes version d'un fichier. + + + + + XXX ajoute texte + + +
+ + Pour chaque portion de fichier posant problème, nous + pouvons choisir de résoudre le conflit en utilisant une combinaison de + texte depuis la version de base, la notre, 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 en parler de tous ici. Leurs + disponibilités varient selon les plate formes ainsi que leurs + avantages et inconvénients. La plupart sont optimisé pour + la fusion de fichier contenant un texte plat, certains sont spécialisé + dans un format de fichier précis (généralement XML). + + + + Un exemple concret + + Dans cet exemple, nous allons reproduire la + modification de l'historique du fichier de la figure ci dessus. Commençons par créer + un dépôt avec une version de base de notre document. + + &interaction.tour-merge-conflict.wife; + + Créons un clone de ce dépôt et faisons une + modification dans le fichier. + + &interaction.tour-merge-conflict.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). + + &interaction.tour-merge-conflict.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). + + &interaction.tour-merge-conflict.pull; + + Dans cette exemple, je n'utiliserais pas la commande Mercurial + habituelle hgmerge pour effectuer le + 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 embarquée par de nombreux systèmes à la Unix. + Si vous exécutez cet exemple depuis votre ordinateur, ne vous + occupez pas de définir HGMERGE. + + &interaction.tour-merge-conflict.merge; + + + 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 conflits, 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: + + &interaction.tour-merge-conflict.commit; + + + Où est la <ocmmand>hg resolve</ocmmand> ? + + La commande hg resolve a été + introduit dans la version 1.1 de Mercurial, qui a été publié en + décembre 2008. Si vous utilisez une version plus anciennne de + Mercurial (exécutez la command hg version pour en + avoir le coeur 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 à une version plus récente avant + d'essayer de régler des fusions complexes. + + + + + + Simplification de la séquence pull-merge-commit + + La procédure pour effectuer la fusion indiquée + ci-dessus est simple, mais requiert le lancement de trois commandes à la + suite. + + hg pull -u +hg merge +hg commit -m 'Merged remote changes' + + Lors du "commit" final, vous devez également saisir un + message, qui aura vraisemblablement assez peu d'intérêt. + + Il serait assez sympathique de pouvoir réduire le + nombre d'opérations nécessaire, si possible. De fait Mercurial est + fourni avec une extension appelé fetch + qui fait justement cela. + + Mercurial fourni un mécanisme d'extension flexible qui permet à chacun + d'étendre ces fonctionnalités, tout en conservant le cœur de Mercurial + léger et facile à utiliser. Certains extensions ajoutent de nouvelles + commandes que vous pouvez utiliser en ligne de commande, alors que + d'autres travaillent en coulisse, par exemple en ajoutant des + possibilités au serveur. + + L'extension fetch + ajoute une nouvelle commande nommée, sans surprise, hg fetch. Cette extension résulte en une + combinaison de hg pull, hg update and hg + merge. Elle commence par récupérer les modifications d'un + autre dépôt dans le dépôt courant. Si elle trouve que les + modifications ajoutent une nouvelle "head", elle effectue un "merge", + et ensuite "commit" le résultat du "merge" avec un message généré + automatiquement. Si aucune "head" n'ont été ajouté, elle met à jour le + répertoire de travail au niveau de la nouvelle révision tip. + + Activer l'extension fetch est facile. Modifiez votre .hgrc, et soit allez à la section extensions soit créer une section + extensions. Ensuite ajoutez + une ligne qui consiste simplement en \Verb+fetch =. + + [extensions] +fetch = + + (Normalement, sur la partie droite de + = devrait apparaître le chemin de + l'extension, mais étant donné que l'extension fetch fait partie de la distribution standard, + Mercurial sait où la trouver.) + + + + + Renommer, copier, et fusionner (merge) + + En cours de la vie d'un projet, nous allons souvent + vouloir changer la disposition de ses fichiers et de ses répertoires. + Ceci peut être aussi simple que de changer le nom d'un seul fichier, + et aussi compliqué que de restructurer une hiérarchie entiere de fichier + au sein du projet. + + Mercurial permet de faire ce genre de modification de + manière fluide, à condition de l'informer de ce que nous faisons. Si + vous voulez renommenr un ficher, vous devriez utiliser les commande + hg rename + Si vous un utilisateur de Unix, vous serez content + de savoir que la commande hg rename command + peut être abrégée en hg mv. + pour changer son nom, ainsi Mercurial peut ensuite prendre + la bonne décision, plus tard, en cas de fusionv (merge). + + Nous étudierojns en détail l'utilisation de ces commandes, + en détail, dans le chapitre . +