belaran@970: 
bos@559: 
bos@686: <appendix id="svn">
bos@687:   <?dbhtml filename="migrating-to-mercurial.html"?>
belaran@970: <title>Migrer vers Mercurial</title>
belaran@970: 
belaran@970:   <para id="x_6e1">Une manière courante de s'essayer à un nouveau
belaran@970:   gestionnaire de révisions est d'expérimenter consiste à migrer un
belaran@970:   projet existant, plutôt que le faire avec un nouveau projet.
belaran@970:   </para>
belaran@970: 
belaran@970:   <para id="x_6e2">Dans cette annexe, nous discuterons comment importer
belaran@970:   l'historique d'un projet dans Mercurial, et à quoi faire attention
belaran@970:   si vous êtes habitué à un autre outils de gestion de révisions.
belaran@970:    </para>
bos@686: 
bos@686:   <sect1>
belaran@970:     <title>Importer l'historique depuis un autre système</title>
belaran@970: 
belaran@970:     <para id="x_6e3">Mercurial est livré avec une extension nommée
belaran@970:       <literal>convert</literal>, qui permet d'importer son historique
belaran@970:       depuis les gestionnaire de révisions les plus courants. Lors de 
belaran@970:       l'écriture de ce livre, il pouvait importer l'historique depuis:
belaran@970:       </para>
bos@686:     <itemizedlist>
bos@686:       <listitem>
bos@691: 	<para id="x_6e4">Subversion</para>
bos@691:       </listitem>
bos@691:       <listitem>
bos@691: 	<para id="x_6e5">CVS</para>
bos@691:       </listitem>
bos@691:       <listitem>
bos@691: 	<para id="x_6e6">git</para>
bos@691:       </listitem>
bos@691:       <listitem>
bos@691: 	<para id="x_6e7">Darcs</para>
bos@691:       </listitem>
bos@691:       <listitem>
bos@691: 	<para id="x_6e8">Bazaar</para>
bos@691:       </listitem>
bos@691:       <listitem>
bos@691: 	<para id="x_6e9">Monotone</para>
bos@691:       </listitem>
bos@691:       <listitem>
bos@691: 	<para id="x_6ea">GNU Arch</para>
bos@691:       </listitem>
bos@691:       <listitem>
bos@691: 	<para id="x_6eb">Mercurial</para>
bos@686:       </listitem>
bos@686:     </itemizedlist>
bos@686: 
belaran@970:     <para id="x_6ec">(Pour savoir pourquoi Mercurial lui même est supporté
belaran@970:     comme source, voir, see <xref linkend="svn.filemap"/>.)</para>
belaran@970: 
belaran@970:     <para id="x_6ed">Vous pouvez activer l'extension de la manière
belaran@970:     habituelle, en éditant votre fichier <filename>~/.hgrc</filename> file.</para>
bos@686: 
bos@686:     <programlisting>[extensions]
bos@686: convert =</programlisting>
bos@686: 
belaran@970:     <para id="x_6ee">Ceci rendra la commande <command>hg convert</command>
belaran@970:     disponible. La commande est facile à utiliser. Par exemple, la 
belaran@970:     commande suivante va importer l'historique Subversion du <emphasis
belaran@970:     remap="it">framework</emphasis> de test Nose Unit dans Mercurial.
belaran@970:       </para>
bos@686: 
bos@686:     <screen><prompt>$</prompt> <userinput>hg convert http://python-nose.googlecode.com/svn/trunk</userinput></screen>
bos@686: 
belaran@970:     <para id="x_6ef">L'extension <literal>convert</literal> opère de 
belaran@970:     manière incrémentale. En d'autres mots, après que vous ayez exécuter
belaran@970:     la commande <command>hg convert</command> une première fois, l'exécuter
belaran@970:     de nouveau importera les nouvelles révisions, ajoutées depuis votre 
belaran@970:     précédente exécution. La conversion incrémentale ne réussiera que si
belaran@970:     vous exécutez <command>hg convert</command> dans le même dépôt que vous
belaran@970:     aviez utilisé à l'origine car l'extension <literal>convert</literal> 
belaran@970:     sauvegarde un certains nombres de méta-données privées dans le fichier,
belaran@970:     non versioné, <filename>.hg/shamap</filename>, au sein du dépôt cible.
belaran@970:     </para>
belaran@970: 
belaran@970:     <para id="x_707">Quand vous voulez faire des modifications en utilisant
belaran@970:     Mercurial, le mieux est de faire un clone de l'ensemble de l'arborescence 
belaran@970:     que vous souhaitez convertir, et laisser l'arborescence d'origine pour
belaran@970:     des conversions futures. C'est la manière la plus sûr pour vous laisser
belaran@970:     récupérer et fusionner les modifications futures depuis la gestionnaire de 
belaran@970:     révisions source dans votre dépôt Mercurial.</para>
bos@693: 
bos@693:     <sect2>
belaran@970:       <title>Convertir plusieurs branches</title>
belaran@970: 
belaran@970:       <para id="x_708">La commande <command>hg convert</command> cité 
belaran@970:       ci dessus converti seulement l'historique de la <literal>branche
belaran@970:       principal (trunk)</literal> du dépôt Subversion. Si vous utilisons
belaran@970:       à la place l'URL <literal>http://python-nose.googlecode.com/svn</literal>,
belaran@970:       Mercurial va automatiquement détecter les répertoires  
belaran@970:       <literal>branche principale (trunk)</literal>, les <literal>étiquettes 
belaran@970:       (tags)</literal>, et les <literal>branches</literal>  que les dépôt
belaran@970:       Subversion utilisent généralement, et il va les importer chacun dans
belaran@970:       une branche Mercurial distincte.</para>
belaran@970: 
belaran@970:       <para id="x_709">Par défaut, chaque branche Subversion importée 
belaran@970:      dans Mercurial se voit attribué un nom de branche. Une fois la
belaran@970:      conversion achevée, vous pouvez lister les noms des branches 
belaran@970:      actives dans le dépôt Mercurial en utilisant la commande
belaran@970:      <command>hg branches -a</command>. Si vous préférez importer les 
belaran@970:      branches Subversion sans noms, ajoutez l'option <option>--config
belaran@970:      convert.hg.usebranches=false</option> à la commande 
belaran@970:      <command>hg convert</command>.</para>
belaran@970: 
belaran@970:       <para id="x_70a">Une fois que vous avez converti votre arborescence,
belaran@970:       si vous voulez suivre la pratique habituel avec Mercurial dans une
belaran@970:       arborescence qui ne contient qu'une seule branche, vous pouvez cloner
belaran@970:       une seule branche en utilisant 
belaran@970:       <command>hg clone -r nomdemabranche</command>.</para>
bos@693:     </sect2>
bos@693: 
bos@686:     <sect2>
belaran@970:       <title>Associer les noms d'utilisateurs</title>
belaran@970: 
belaran@970:       <para id="x_6f0">Certains système de gestion de révisions
belaran@970:       ne sauvegarde, avec les modifications transférées, que les noms 
belaran@970:       d'utilisateurs raccourcis et ceci peuvent être difficile à 
belaran@970:       intépréter. La norme avec Mercurial est de sauvegarder le 
belaran@970:       nom du <emphasis remap="it">committer</emphasis> et son adresse
belaran@970:       mail, ce qui est beaucoup plus utile pour discuter avec lui
belaran@970:       par la suite.</para>
belaran@970: 
belaran@970:       <para id="x_6f1">Si vous convertissez une arborescence depuis
belaran@970:       un gestionnaire de révisions qui utilisent seulement les noms
belaran@970:       raccourcies, vous pouvez associer ces noms à des équivalents 
belaran@970:       plus détaillés en passant l'option <option>--authors</option>
belaran@970:       à la commande <command>hg convert</command>. Cette option
belaran@970:       attend un fichier qui contient des entrées de la forme suivante:
belaran@970:       </para>
bos@686: 
bos@686:       <programlisting>arist = Aristotle &lt;aristotle@phil.example.gr&gt;
bos@686: soc = Socrates &lt;socrates@phil.example.gr&gt;</programlisting>
bos@686: 
belaran@970:       <para id="x_6f2">Quand <literal>convert</literal> trouve une
belaran@970:       modification associé au nom <literal>arist</literal> dans le
belaran@970:       dépôt de source, il va utiliser le nom <literal>Aristotle
belaran@970:       &lt;aristotle@phil.example.gr&gt;</literal> dans les révisions
belaran@970:       Mercurial. Si aucune correspondance n'est trouvé, il utilise
belaran@970:       le nom tel quel.</para>
bos@686:     </sect2>
bos@686: 
bos@686:     <sect2 id="svn.filemap">
belaran@970:       <title>Nettoyer l'arboresence</title>
belaran@970: 
belaran@970:       <para id="x_6f3">Tout les projets n'ont pas un historique parfait.
belaran@970:       Il peut y avoir des répertoire qui n'auraient jamais dû être ajoutés,
belaran@970:       un fichier qui est trop volumineux, ou même une sous partie de la
belaran@970:       hiérarchie qui devraient être réorganisée.</para>
belaran@970: 
belaran@970:       <para id="x_6f4">L'extension <literal>convert</literal> permet
belaran@970:       d'utiliser un <quote>fichier d'association</quote> qui peut 
belaran@970:       réorganiser les fichiers et les répertoires dans un projet alors
belaran@970:       qu'il importe son historique. Ceci est utile non seulement quand vous
belaran@970:       importez l'historique d'un autre gestionnaire de révisions, mais
belaran@970:       aussi pour nettoyer ou refactorer l'arboresence d'un projet
belaran@970:       Mercurial.</para>
belaran@970: 
belaran@970:       <para id="x_6f5">Pour indiquer le fichier d'association, on utilise
belaran@970:       l'option <option>-filemap</option> en lui fournissant un nom de
belaran@970:       fichier. Le fichier d'association contient des lignes de la forme
belaran@970:       suivante:
belaran@970: 
belaran@970:       <programlisting># Ceci est un commentaire.
belaran@970: # Les lignes vides sont ignorées.
bos@686: 
bos@686: include path/to/file
bos@686: 
bos@686: exclude path/to/file
bos@686: 
bos@686: rename from/some/path to/some/other/place
bos@686: </programlisting>
bos@686: 
belaran@970:       <para id="x_6f6">La directive <literal>include</literal> inclus un
belaran@970:       fichier, ou l'ensemble des fichiers d'un répertoire, dans le dépôt
belaran@970:       de destination. La directive <literal>exclude</literal> omet les
belaran@970:       fichiers ou répertoires du dépôt. Ceci inclut aussi les autres
belaran@970:       fichiers et répertoires qui ne sont pas explicitement inclus.
belaran@970:       La directive <literal>exclude</literal> entraine l'omission
belaran@970:       des fichiers ou répertoires, et autres fichiers qui ne sont
belaran@970:       explicitement inclus.</para>
belaran@970: 
belaran@970:       <para id="x_6f7">Pour déplacer un fichier ou un répertoire d'un
belaran@970:       emplacement à un autre, il faut utiliser la directive
belaran@970:       <literal>rename</literal>. Si vous avez besoin de déplacer un 
belaran@970:       fichier ou un répertoire depuis un sous répertoire dans la raçine
belaran@970:       du dépôt, utilisez <literal>.</literal> comme second argument de 
belaran@970:       la directive <literal>rename</literal>.</para>
bos@686:     </sect2>
bos@693: 
bos@693:     <sect2>
belaran@970:       <title>Améliorer les performances la conversion Subversion</title>
belaran@970: 
belaran@970:       <para id="x_70b">Vous aurez souvent besoin de plusieurs essais
belaran@970:       avant d'arriver à la parfaite combinaison de fichier d'association,
belaran@970:       d'association de noms d'utilisateurs et d'autres paramètres. Hors,
belaran@970:       convertir un dépôt Mercurial via un protocol comme <literal>ssh</literal>
belaran@970:       or <literal>http</literal> peut être des milliers de fois plus long
belaran@970:       que ce dont le système d'exploitation est en fait capable de faire,
belaran@970:       à cause des latence réseau. Ceci peut rendre la conception de cette
belaran@970:       combinaison parfaite très douloureuse.</para>
belaran@970: 
belaran@970:       <para id="x_70c">La commande <ulink
bos@693: 	  url="http://svn.collab.net/repos/svn/trunk/notes/svnsync.txt"><command>svnsync</command></ulink> 
belaran@970: 	peut grandement améliorer la vitesse de conversion d'un dépôt
belaran@970:         Subversion. Il s'agit d'un programme de miroir de dépôt Subversion
belaran@970:         en lecture seule. L'idée est de créer un miroir local d'une
belaran@970:         arboresence Subversion, puis de convertir ce miroir en dépôt
belaran@970:         Mercurial.</para>
belaran@970:       
belaran@970:       <para id="x_70d">Supposez que nous voulions convertir le dépôt 
belaran@970:       Subversion du populaire projet Memcached en une arboresence Mercurial.
belaran@970:       Premièrement, nous créons un dépôt Subversion local.</para>
bos@693: 
bos@693:       <screen><prompt>$</prompt> <userinput>svnadmin create memcached-mirror</userinput></screen>
bos@693: 
belaran@970:       <para id="x_70e">Puis, nous allons mettre en place le 'hook' Subversion
belaran@970:       dont <command>svnsync</command> a besoin.</para>
bos@693: 
bos@693:       <screen><prompt>$</prompt> <userinput>echo '#!/bin/sh' > memcached-mirror/hooks/pre-revprop-change</userinput>
bos@693: <prompt>$</prompt> <userinput>chmod +x memcached-mirror/hooks/pre-revprop-change</userinput></screen>
bos@693: 
belaran@970:       <para id="x_70f">Nous initialisons <command>svnsync</command> dans ce
belaran@970:       dépôt.</para>
bos@693: 
bos@693:       <screen><prompt>$</prompt> <userinput>svnsync --init file://`pwd`/memcached-mirror \
bos@693:   http://code.sixapart.com/svn/memcached</userinput></screen>
bos@693: 
belaran@970:       <para id="x_710">La prochaine étape est de commencer le processus de
belaran@970:       miroir de <command>svnsync</command>.</para>
bos@693: 
bos@693:       <screen><prompt>$</prompt> <userinput>svnsync sync file://`pwd`/memcached-mirror</userinput></screen>
bos@693: 
belaran@970:       <para id="x_711">Enfin, nous importons l'historique de notre dépôt
belaran@970:       local Subversion dans Mercurial.</para>
bos@693: 
bos@693:       <screen><prompt>$</prompt> <userinput>hg convert memcached-mirror</userinput></screen>
bos@693:       
belaran@970:       <para id="x_712">Nous pouvons utiliser ce processus de manière
belaran@970:       incrémentale, si le dépôt Subversion est toujours en activité.
belaran@970:       Il suffit d'exécuter de nouveau <command>svnsync</command> pour
belaran@970:       récupérer les modifications dans notre miroir, puis <command>hg convert</command>
belaran@970:       les importe dans notre arboresence Mercurial.</para>
belaran@970: 
belaran@970:       <para id="x_713">Il y a deux avantages à utiliser un import à deux
belaran@970:       étages comme avec <command>svnsync</command></command>. Le premier
belaran@970:       est qu'il utilise plus efficassement la synchronisation à travers
belaran@970:       le réseau de Subversion que la commande <command>hg convert</command>,
belaran@970:       et donc il transfère moins de données à travers ce dernier. La deuxième
belaran@970:       est que l'import depuis un dépôt subversion local est si rapide que
belaran@970:       vous pouvez améliorer votre conversion de ce dernier, en le répétant
belaran@970:       succesivement, sans souffrir de la qualité de la connection
belaran@970:       réseau.</para>
bos@693:     </sect2>
bos@686:   </sect1>
bos@686: 
bos@686:   <sect1>
bos@686:     <title>Migrating from Subversion</title>
bos@686: 
belaran@970:     <para id="x_6f8">Subversion est aujourd'hui le plus utilisé des 
belaran@970:     système de gestion de révision Open Source. Bien qu'il y est des
belaran@970:     différences entre Mercurial et Subversion, faire la transition de
belaran@970:     l'un à l'autre n'est pas très difficile. Les deux disposent en effet 
belaran@970:     de jeux de commandes similaires et d'interfaces uniformes.</para>
bos@686: 
bos@686:     <sect2>
belaran@970:       <title>Différences philosophiques</title>
belaran@970: 
belaran@970:       <para id="x_6f9">La différence fondamentale entre Subversion et
belaran@970:       Mercurial est bien évidement que Subversion est centralisé, alors 
belaran@970:       que Mercurial est distribué. Puisque que Mercurial enregistre tout
belaran@970:       l'historique d'un projet sur votre disque dur local, il n'a besoin
belaran@970:       d'effectuer des accès au réseau que lorsque vous lui demandez
belaran@970:       explicitement de discuter avec un autre dépôt, distant. Par contraste,
belaran@970:       Subversion ne conserve que peu d'information localement, et le client
belaran@970:       doit donc régulièrement discuter avec le serveur central pour la
belaran@970:       plupart des opérations communes.</para>
belaran@970: 
belaran@970:       <para id="x_6fa">Subversion s'en tire plus ou moins bien sans de notion
belaran@970:       de branche réellement bien définie : quel part de l'espace de nommage
belaran@970:       du serveur est une branche est une simple question de convention, le
belaran@970:       logiciel ne fournissant aucune sécurité à ce sujet. Mercurial considère
belaran@970:       un dépôt comme une branche.</para>
belaran@970:       
bos@686:       <sect3>
belaran@970: 	<title>Portée des commandes</title>
belaran@970: 
belaran@970: 	<para id="x_6fb">Puisque que Subversion ne sait pas réellement
belaran@970:         quelle partie de son espace de nommage est en fait une branche, il
belaran@970:         traite la plupart des commandes comme des requêtes à exécuter sur le
belaran@970:         répertoire où vous vous situez, et ses sous répertoires. Par exemple,
belaran@970:         si vous exécuter <command>svn log</command>, vous verrez l'historique 
belaran@970:         de la partie de l'arboresence où vous vous situez, et non la
belaran@970:         hiérarchie entière.</para>
belaran@970: 
belaran@970: 	<para id="x_6fc">Les commandes de Mercurial ont un comportement
belaran@970:         différents, appliquant toutes commandes à l'ensemble de l'arboresence
belaran@970:         du dépôt. Exécutez la commande <command>hg log</command> et elle vous
belaran@970:         donnera l'historique de l'ensemble de l'arboresence, quelque soit le
belaran@970:         répertoire de cette dernière où vous vous situez à ce moment là. Si
belaran@970:         vous souhaitez l'historique d'une répertoire ou seulement d'un
belaran@970:         fichier, ajouter simplement le nom de celui-ci à la commande
belaran@970:         <command>hg log src</command>.</para>
belaran@970: 
belaran@970: 	<para id="x_6fd">De ma propre expérience, cette différence dans leur
belaran@970:         comportement par défaut est probablement ce qui risque de vous
belaran@970:         surprendre si vous basculez régulièrement d'un outil à l'autre.</para>
bos@686:       </sect3>
bos@686: 
bos@686:       <sect3>
belaran@970: 	<title>Opération multi utilisateur et sécurité</title>
belaran@970: 
belaran@970: 	<para id="x_6fe">Avec Subversion, il est normal (bien que légèrement
belaran@970:         désapprouvée) que différentes personnes collaborent sur une seule
belaran@970:         branche. Si Alice et Bob travaillent ensemble, et Alice ajoute ses
belaran@970:         modications à leur branche partagée, Bob doit alors mettre à jour
belaran@970:         la vue de la banche de son client avant d'ajouter lui même ses 
belaran@970:         modifications. Puisqu'il n'a, à ce moment, aucun enregistrement
belaran@970:         permanent des modifications qu'il a fait, il peut corrompre ou perdre
belaran@970:         des modifications pendant et après sa mise à jour.</para>
belaran@970: 
belaran@970: 	<para id="x_6ff">Mercurial encourage, à l'inverse, un modèle 
belaran@970:         "commit-puis-merge". Bob ajoute ses modifications de manière locale 
belaran@970:         avant de récupérer les modifications d'Alice, ou d'envoyer les siennes 
belaran@970:         au serveur qu'ils partagent. Si Alice envoye ses modifications avant
belaran@970:         que Alice n'envoye les siennes, il ne pourra envoyer ses
belaran@970:         modifications avant d'avoir récupérer les siennes. Si il fait une
belaran@970:         erreur lors de la fusion, il peut toujours à sa version d'origine,
belaran@970:         telle qu'elle a été enregistré.</para>
belaran@970:           
belaran@970: 	<para id="x_700">Il est important de souligner qu'il s'agit de la
belaran@970:         manière habituelle de travailler avec ses outils. Subversion propose
belaran@970:         une manière plus sûr de travailler-dans-votre-propre-branche, mais il
belaran@970:         est assez complexe pour que, en pratique, il ne soit jamais utiliser.
belaran@970:         Mercurial propose un mode, un peu moyen sûr, mais permettant de
belaran@970:         récupérer des modifications par dessus des modifications non
belaran@970:         commitées, mais c'est considéré comme assez inhabituel.</para> 
bos@686:       </sect3>
bos@686: 
bos@686:       <sect3>
belaran@970: 	<title>Publication vs changement locaux</title>
belaran@970: 
belaran@970: 	<para id="x_701">Une commande Subversion <command>svn
belaran@970:         commit</command> publie immédiatement les modifications sur le
belaran@970:         serveur, où ils peuvent être vu par n'importe qui doté du privilège
belaran@970:         de lecture.</para>
belaran@970: 
belaran@970: 	<para id="x_702">Avec Mercurial, les modifications sont toujours
belaran@970:         enregistrées localement, et doivent être par la suite transférer par
belaran@970:         la commande <command>hg push</command>.</para>
belaran@970: 
belaran@970: 	<para id="x_703">Chaque approche à ses avantages et ses désavantages.
belaran@970:         Le modèle Subversion implique que les modifications sont publiées, et
belaran@970:         donc disponible immédiatement. D'un autre coté, il implique aussi
belaran@970:         qu'un utilisateur doit avoir le droit d'écriture dans le dépôt pour
belaran@970:         permettre l'utiliser normalement, et ce privilège n'est pas concédé 
belaran@970:         facilement par les projets Open Source.</para>
belaran@970: 
belaran@970: 	<para id="x_704">L'approche de Mercurial permet à quiquonque de faire
belaran@970:         un clone du dépôt et d'y ajouter ses modifications sans jamais avoir
belaran@970:         besoin de la permission de quiquonque, et l'on peut même publier ses
belaran@970:         modifications et continuer à participer comme on le désir. La
belaran@970:         distinction entre les commits et le transfert de ces derniers ouvre
belaran@970:         la possibilité néanmoins que quelqu'un oublie pendant une longue
belaran@970:         période de transférer ses modifications, ce qui dans certains cas
belaran@970:         rares, peut piéger ses collaborateurs.</para>
bos@686:       </sect3>
bos@686:     </sect2>
bos@686: 
bos@686:     <sect2>
belaran@970:       <title>Références des commandes</title>
bos@686: 
bos@686:       <table>
belaran@970: 	<title>Commandes Subversion et leurs équivalents Mercurial</title>
bos@686: 	<tgroup cols="3">
bos@686: 	  <thead>
bos@686: 	    <row>
bos@686: 	      <entry>Subversion</entry>
bos@686: 	      <entry>Mercurial</entry>
bos@686: 	      <entry>Notes</entry>
bos@686: 	    </row>
bos@686: 	  </thead>
bos@686: 	  <tbody>
bos@686: 	    <row>
bos@686: 	      <entry><command>svn add</command></entry>
bos@686: 	      <entry><command>hg add</command></entry>
bos@686: 	      <entry></entry>
bos@686: 	    </row>
bos@686: 	    <row>
bos@686: 	      <entry><command>svn blame</command></entry>
bos@686: 	      <entry><command>hg annotate</command></entry>
bos@686: 	      <entry></entry>
bos@686: 	    </row>
bos@686: 	    <row>
bos@686: 	      <entry><command>svn cat</command></entry>
bos@686: 	      <entry><command>hg cat</command></entry>
bos@686: 	      <entry></entry>
bos@686: 	    </row>
bos@686: 	    <row>
bos@686: 	      <entry><command>svn checkout</command></entry>
bos@686: 	      <entry><command>hg clone</command></entry>
bos@686: 	      <entry></entry>
bos@686: 	    </row>
bos@686: 	    <row>
bos@686: 	      <entry><command>svn cleanup</command></entry>
bos@686: 	      <entry>n/a</entry>
belaran@970: 	      <entry>Aucun nettoyage nécessaire.</entry>
bos@686: 	    </row>
bos@686: 	    <row>
bos@686: 	      <entry><command>svn commit</command></entry>
bos@686: 	      <entry><command>hg commit</command>; <command>hg
bos@686: 		  push</command></entry>
belaran@970: 	      <entry><command>hg push</command> publie les modifications
belaran@970:               après leur enregistrement.</entry>
bos@686: 	    </row>
bos@686: 	    <row>
bos@686: 	      <entry><command>svn copy</command></entry>
bos@686: 	      <entry><command>hg clone</command></entry>
belaran@970: 	      <entry>Pour créer une nouvelle branche</entry>
bos@686: 	    </row>
bos@686: 	    <row>
bos@686: 	      <entry><command>svn copy</command></entry>
bos@686: 	      <entry><command>hg copy</command></entry>
belaran@970: 	      <entry>Pour copier des fichiers ou des répertoires</entry>
bos@686: 	    </row>
bos@686: 	    <row>
bos@686: 	      <entry><command>svn delete</command> (<command>svn
bos@686: 		  remove</command>)</entry>
bos@686: 	      <entry><command>hg remove</command></entry>
bos@686: 	      <entry></entry>
bos@686: 	    </row>
bos@686: 	    <row>
bos@686: 	      <entry><command>svn diff</command></entry>
bos@686: 	      <entry><command>hg diff</command></entry>
bos@686: 	      <entry></entry>
bos@686: 	    </row>
bos@686: 	    <row>
bos@686: 	      <entry><command>svn export</command></entry>
bos@686: 	      <entry><command>hg archive</command></entry>
bos@686: 	      <entry></entry>
bos@686: 	    </row>
bos@686: 	    <row>
bos@686: 	      <entry><command>svn help</command></entry>
bos@686: 	      <entry><command>hg help</command></entry>
bos@686: 	      <entry></entry>
bos@686: 	    </row>
bos@686: 	    <row>
bos@686: 	      <entry><command>svn import</command></entry>
bos@686: 	      <entry><command>hg addremove</command>; <command>hg
bos@686: 		  commit</command></entry>
bos@686: 	      <entry></entry>
bos@686: 	    </row>
bos@686: 	    <row>
bos@686: 	      <entry><command>svn info</command></entry>
bos@686: 	      <entry><command>hg parents</command></entry>
belaran@970: 	      <entry>Affiche quelle révision est extraite</entry>
bos@686: 	    </row>
bos@686: 	    <row>
bos@686: 	      <entry><command>svn info</command></entry>
bos@686: 	      <entry><command>hg showconfig
bos@686: 		  paths.parent</command></entry>
belaran@970: 	      <entry>Affiche de quelle URL est extrait ce dépôt</entry>
bos@686: 	    </row>
bos@686: 	    <row>
bos@686: 	      <entry><command>svn list</command></entry>
bos@686: 	      <entry><command>hg manifest</command></entry>
bos@686: 	      <entry></entry>
bos@686: 	    </row>
bos@686: 	    <row>
bos@686: 	      <entry><command>svn log</command></entry>
bos@686: 	      <entry><command>hg log</command></entry>
bos@686: 	      <entry></entry>
bos@686: 	    </row>
bos@686: 	    <row>
bos@686: 	      <entry><command>svn merge</command></entry>
bos@686: 	      <entry><command>hg merge</command></entry>
bos@686: 	      <entry></entry>
bos@686: 	    </row>
bos@686: 	    <row>
bos@686: 	      <entry><command>svn mkdir</command></entry>
bos@686: 	      <entry>n/a</entry>
belaran@970: 	      <entry>Mercurial ne versionne pas les répertoires</entry>
bos@686: 	    </row>
bos@686: 	    <row>
bos@686: 	      <entry><command>svn move</command> (<command>svn
bos@686: 		  rename</command>)</entry>
bos@686: 	      <entry><command>hg rename</command></entry>
bos@686: 	      <entry></entry>
bos@686: 	    </row>
bos@686: 	    <row>
bos@686: 	      <entry><command>svn resolved</command></entry>
bos@686: 	      <entry><command>hg resolve -m</command></entry>
bos@686: 	      <entry></entry>
bos@686: 	    </row>
bos@686: 	    <row>
bos@686: 	      <entry><command>svn revert</command></entry>
bos@686: 	      <entry><command>hg revert</command></entry>
bos@686: 	      <entry></entry>
bos@686: 	    </row>
bos@686: 	    <row>
bos@686: 	      <entry><command>svn status</command></entry>
bos@686: 	      <entry><command>hg status</command></entry>
bos@686: 	      <entry></entry>
bos@686: 	    </row>
bos@686: 	    <row>
bos@686: 	      <entry><command>svn update</command></entry>
bos@686: 	      <entry><command>hg pull -u</command></entry>
bos@686: 	      <entry></entry>
bos@686: 	    </row>
bos@686: 	  </tbody>
bos@686: 	</tgroup>
bos@686:       </table>
bos@686:     </sect2>
bos@686:   </sect1>
bos@686: 
bos@686:   <sect1>
belaran@970:     <title>Conseils utiles pour les débutants</title>
belaran@970: 
belaran@970:     <para id="x_705">Avec la plupart des gestionnaire de révisions, afficher
belaran@970:     un diff associé à une révision peut être assez douloureux. Par exemple,
belaran@970:     avec Subversion, pour voir ce qui a été modifiée dans la révision 104654,
belaran@970:     vous devez saisir <command>svn diff -r104653:104654</command>. Mercurial
belaran@970:     élimine le besoin de saisir l'identifiant d'une révision deux fois dans
belaran@970:     ce cas classique. Pour un simple diff, <command>hg
belaran@970:     export<command></command>
belaran@970:     104654</command> suffit. Pour l'entrée du journal suivi du diff,
belaran@970:     <command>hg log -r104654</command>. </para>
belaran@970: 
belaran@970:     <para id="x_706">Quand vous exécutez la commande <command>hg status</command>
belaran@970:     sans aucun arguments, elle affiche l'état de l'ensemble de l'arboresence,
belaran@970:     avec des chemins relatifs partant de la raçine du dépôt. Ceci rend
belaran@970:     difficile de copier un nom de fichier depuis la sortie de la commande
belaran@970:     <command>hg status</command> dans une autre ligne de commande. Si vous
belaran@970:     fournissez un fichier ou un répertoire à la commande <command>hg
belaran@970:     status</command>, elle va afficher les chemins relatif depuis votre
belaran@970:     répertoire courant à la place. Ainsi, pour avoir un état sur l'ensemble
belaran@970:     de l'arboresence à l'aide  de <command>hg status</command>, avec des
belaran@970:     chemins relatifs à votre répertoire courant, et non le raçine du dépôt,
belaran@970:     ajoutez la sortie de <command>hg root</command> à la commande
belaran@970:     <command>hg status</command>. Vous pouvez le faire aisément sur un
belaran@970:     système Unix ainsi :</para>
bos@686: 
bos@686:     <screen><prompt>$</prompt> <userinput>hg status `hg root`</userinput></screen>
bos@686:   </sect1>
bos@559: </appendix>
bos@559: 
bos@559: <!--
bos@559: local variables: 
bos@559: sgml-parent-document: ("00book.xml" "book" "appendix")
bos@559: end:
bos@559: -->