1.1 --- a/fr/appA-svn.xml	Sat Sep 12 17:58:26 2009 +0200
     1.2 +++ b/fr/appA-svn.xml	Sat Sep 12 17:58:56 2009 +0200
     1.3 @@ -11,7 +11,7 @@
     1.4  
     1.5    <para id="x_6e2">Dans cette annexe, nous discuterons comment importer
     1.6    l'historique d'un projet dans Mercurial, et à quoi faire attention
     1.7 -  si vous êtes habitué à un autre outil de gestion de révisions.
     1.8 +  si vous êtes habitués à un autre outil de gestion de révisions.
     1.9     </para>
    1.10  
    1.11    <sect1>
    1.12 @@ -70,7 +70,7 @@
    1.13      manière incrémentale. En d'autres mots, après une première exécution de
    1.14      la commande <command>hg convert</command>, les exécutions ultérieures
    1.15      importeront les révisions ultérieures à l'exécution précédente.
    1.16 -    La conversion incrémentale ne réussiera que si
    1.17 +    La conversion incrémentale ne réussira que si
    1.18      vous exécutez <command>hg convert</command> dans le même dépôt que vous
    1.19      aviez utilisé à l'origine, ceci parce que l'extension <literal>convert</literal> 
    1.20      sauvegarde un certain nombre de méta-données privées dans le fichier
    1.21 @@ -93,7 +93,7 @@
    1.22        à la place l'URL <literal>http://python-nose.googlecode.com/svn</literal>,
    1.23        Mercurial va automatiquement détecter la  
    1.24        <literal>branche principale (trunk)</literal>, les <literal>étiquettes 
    1.25 -      (tags)</literal>, et les <literal>branches</literal>  que les dépôt
    1.26 +      (tags)</literal>, et les <literal>branches</literal>  que les dépôts
    1.27        Subversion utilisent généralement, et les importera chacun dans
    1.28        une branche Mercurial distincte.</para>
    1.29  
    1.30 @@ -162,7 +162,7 @@
    1.31        <para id="x_6f5">Pour indiquer le fichier d'association, on utilise
    1.32        l'option <option>--filemap</option> en lui fournissant un nom de
    1.33        fichier. Le fichier d'association contient des lignes de la forme
    1.34 -      suivante:</para>
    1.35 +      suivante :</para>
    1.36  
    1.37        <programlisting># Ceci est un commentaire.
    1.38  # Les lignes vides sont ignorées.
    1.39 @@ -196,8 +196,8 @@
    1.40  
    1.41        <para id="x_70b">Vous aurez souvent besoin de plusieurs essais
    1.42        avant d'arriver à la parfaite combinaison de fichier d'association de fichiers,
    1.43 -      de fichier d'association de noms d'utilisateurs et des autres paramètres. Hors,
    1.44 -      convertir un dépôt Mercurial via un protocol comme <literal>ssh</literal>
    1.45 +      de fichier d'association de noms d'utilisateurs et des autres paramètres. Or,
    1.46 +      convertir un dépôt Mercurial via un protocole comme <literal>ssh</literal>
    1.47        ou <literal>http</literal> peut être des milliers de fois plus long
    1.48        que ce dont le système d'exploitation est en fait capable de faire,
    1.49        à cause des latence réseau. Ceci peut rendre la conception de cette
    1.50 @@ -212,7 +212,7 @@
    1.51          Mercurial.</para>
    1.52        
    1.53        <para id="x_70d">Supposez que nous voulions convertir le dépôt 
    1.54 -      Subversion du populaire projet Memcached en une arboresence Mercurial.
    1.55 +      Subversion du populaire projet Memcached en une arborescence Mercurial.
    1.56        Tout d'abord, nous créons un dépôt Subversion local.</para>
    1.57  
    1.58        <screen><prompt>$</prompt> <userinput>svnadmin create memcached-mirror</userinput></screen>
    1.59 @@ -244,7 +244,7 @@
    1.60        Il suffit d'exécuter de nouveau <command>svnsync</command> pour
    1.61        récupérer les récentes modifications dans notre miroir, puis <command>hg 
    1.62        convert</command>
    1.63 -      les importe dans notre arboresence Mercurial.</para>
    1.64 +      les importe dans notre arborescence Mercurial.</para>
    1.65  
    1.66        <para id="x_713">Il y a deux avantages à utiliser un import à deux
    1.67        étages comme avec <command>svnsync</command>. Le premier
    1.68 @@ -253,7 +253,7 @@
    1.69        et donc transfère moins de données par le réseau. Le deuxième
    1.70        est que l'import depuis un dépôt Subversion local est si rapide que
    1.71        vous pouvez peaufiner et réitérer les paramètres de conversion de 
    1.72 -      ce dernier sans souffrir de la qualité de la connection réseau.</para>
    1.73 +      ce dernier sans souffrir de la qualité de la connexion réseau.</para>
    1.74      </sect2>
    1.75    </sect1>
    1.76  
    1.77 @@ -275,7 +275,7 @@
    1.78        l'historique d'un projet sur votre disque dur local, il n'a besoin
    1.79        d'effectuer des accès au réseau que lorsque vous voulez
    1.80        explicitement communiquer avec un autre dépôt. Subversion, par contre,
    1.81 -      ne conserve que peu d'information localement, et le client
    1.82 +      ne conserve que peu d'informations localement, et le client
    1.83        doit donc communiquer avec le serveur central pour la
    1.84        plupart des opérations communes.</para>
    1.85  
    1.86 @@ -293,21 +293,21 @@
    1.87          traite la plupart des commandes comme des requêtes à exécuter sur le
    1.88          répertoire où vous vous situez, et ses sous répertoires. Par exemple,
    1.89          si vous exécutez <command>svn log</command>, vous verrez l'historique 
    1.90 -        de la partie de l'arboresence où vous vous situez, et non de la
    1.91 +        de la partie de l'arborescence où vous vous situez, et non de la
    1.92          hiérarchie entière.</para>
    1.93  
    1.94  	<para id="x_6fc">Les commandes de Mercurial ont un comportement
    1.95 -        différent : toutes les commandes s'appliquent à l'ensemble de l'arboresence
    1.96 +        différent : toutes les commandes s'appliquent à l'ensemble de l'arborescence
    1.97          du dépôt. Exécutez la commande <command>hg log</command> et elle vous
    1.98 -        donnera l'historique de l'ensemble de l'arboresence, quel que soit le
    1.99 +        donnera l'historique de l'ensemble de l'arborescence, quel que soit le
   1.100          sous-répertoire où vous vous situez. Si
   1.101          vous souhaitez obtenir l'historique d'un répertoire ou seulement d'un
   1.102          fichier, ajouter simplement le nom de celui-ci à la commande, par
   1.103          exemple <command>hg log src</command>.</para>
   1.104  
   1.105  	<para id="x_6fd">De ma propre expérience, cette différence dans leur
   1.106 -        comportement par défaut est le plus probablement ce qui risque de vous
   1.107 -        surprendre si vous passez régulièrement d'un outil à l'autre.</para>
   1.108 +        comportement par défaut est probablement ce qui risque de vous
   1.109 +        surprendre le plus si vous passez régulièrement d'un outil à l'autre.</para>
   1.110        </sect3>
   1.111  
   1.112        <sect3>
   1.113 @@ -316,7 +316,7 @@
   1.114  	<para id="x_6fe">Avec Subversion, il est normal (bien que légèrement
   1.115          désapprouvé) que différentes personnes collaborent sur une seule
   1.116          branche. Si Alice et Bob travaillent ensemble, et Alice ajoute ses
   1.117 -        modications à leur branche partagée, Bob doit alors mettre à jour
   1.118 +        modifications à leur branche partagée, Bob doit alors mettre à jour
   1.119          sa vue de la branche avant de pouvoir appliquer un commit.
   1.120          Puisqu'il n'a, à ce moment, pas effectué de commit
   1.121          des modifications qu'il a faites, il se peut qu'il ne corrompe 
   1.122 @@ -340,7 +340,7 @@
   1.123          est assez complexe pour que, en pratique, elle ne soit que rarement utilisé.
   1.124          Mercurial propose de son côté un mode un peu moins sûr, permettant de
   1.125          récupérer des modifications par dessus des modifications non
   1.126 -        commitées, qui reste toutefois très peu répandu.</para> 
   1.127 +        committées, qui reste toutefois très peu répandu.</para> 
   1.128        </sect3>
   1.129  
   1.130        <sect3>
   1.131 @@ -355,16 +355,16 @@
   1.132          enregistrées localement, et doivent être par la suite transférés par
   1.133          la commande <command>hg push</command>.</para>
   1.134  
   1.135 -	<para id="x_703">Chaque approche à ses avantages et ses inconvénients.
   1.136 +	<para id="x_703">Chaque approche a ses avantages et ses inconvénients.
   1.137          Le modèle Subversion implique que les modifications soient publiées, et
   1.138          donc disponibles immédiatement. D'un autre coté, cela implique aussi
   1.139          que, pour pouvoir utiliser le logiciel normalement, un utilisateur doit 
   1.140          avoir les droits d'écriture dans le dépôt, et ce privilège n'est pas concédé 
   1.141          facilement par la plupart des projets Open Source.</para>
   1.142  
   1.143 -	<para id="x_704">L'approche de Mercurial permet à quiquonque de faire
   1.144 +	<para id="x_704">L'approche de Mercurial permet à quiconque de faire
   1.145          un clone du dépôt et d'y ajouter ses modifications sans jamais avoir
   1.146 -        besoin de la permission de quiquonque, et l'on peut même publier ses
   1.147 +        besoin de la permission de quiconque, et l'on peut même publier ses
   1.148          modifications et continuer à participer comme on le désire. Toutefois, la
   1.149          distinction entre les commits et le transfert de ces derniers présente
   1.150          le risque que quelqu'un applique ses modifications par un commit local
   1.151 @@ -533,15 +533,15 @@
   1.152      <command>hg log -r104654 -p</command>.</para>
   1.153  
   1.154      <para id="x_706">Quand vous exécutez la commande <command>hg status</command>
   1.155 -    sans aucun arguments, elle affiche l'état de l'ensemble de l'arboresence,
   1.156 -    avec des chemins relatifs partant de la raçine du dépôt. Ceci rend
   1.157 +    sans aucun argument, elle affiche l'état de l'ensemble de l'arborescence,
   1.158 +    avec des chemins relatifs partant de la racine du dépôt. Ceci rend
   1.159      difficile de copier un nom de fichier depuis la sortie de la commande
   1.160      <command>hg status</command> dans une autre ligne de commande. Si vous
   1.161      fournissez un fichier ou un répertoire à la commande <command>hg
   1.162      status</command>, elle va afficher les chemins relatif depuis votre
   1.163      répertoire courant à la place. Ainsi, pour avoir un état sur l'ensemble
   1.164 -    de l'arboresence à l'aide  de <command>hg status</command>, avec des
   1.165 -    chemins relatifs à votre répertoire courant, et non le racine du dépôt,
   1.166 +    de l'arborescence à l'aide  de <command>hg status</command>, avec des
   1.167 +    chemins relatifs à votre répertoire courant, et non la racine du dépôt,
   1.168      ajoutez la sortie de <command>hg root</command> à la commande
   1.169      <command>hg status</command>. Vous pouvez le faire aisément sur un
   1.170      système Unix ainsi :</para>

     2.1 --- a/fr/appC-srcinstall.xml	Sat Sep 12 17:58:26 2009 +0200
     2.2 +++ b/fr/appC-srcinstall.xml	Sat Sep 12 17:58:56 2009 +0200
     2.3 @@ -18,7 +18,7 @@
     2.4  	<programlisting>gzip -dc mercurial-MYVERSION.tar.gz | tar xf -</programlisting>
     2.5        </listitem>
     2.6        <listitem><para id="x_5e3">Allez dans le répertoires où les sources ont
     2.7 -    été extraites et executez le script d'installation. Ce dernier compilera
     2.8 +    été extraites et exécutez le script d'installation. Ce dernier compilera
     2.9      Mercurial et l'installera dans votre répertoire utilisateur.</para>
    2.10  	<programlisting>cd mercurial-MYVERSION
    2.11  python setup.py install --force --home=$HOME</programlisting>
    2.12 @@ -32,7 +32,7 @@
    2.13  
    2.14      <para id="x_5e5">Vous devrez vraisemblablement définir la variable
    2.15        d'environnement <envar>PYTHONPATH</envar> de manière à ce que
    2.16 -      l'executable de Mercurial puisse trouver le reste des paquets logiciels.
    2.17 +      l'exécutable de Mercurial puisse trouver le reste des paquets logiciels.
    2.18        Par exemple, sur mon ordinateur portable, je dois le définir ainsi:
    2.19        <literal>/home/bos/lib/python</literal>. Le chemin exact à utiliser
    2.20        dépendra de la manière dont Python aura été construit pour votre 

     3.1 --- a/fr/appD-license.xml	Sat Sep 12 17:58:26 2009 +0200
     3.2 +++ b/fr/appD-license.xml	Sat Sep 12 17:58:56 2009 +0200
     3.3 @@ -1,185 +1,179 @@
     3.4  <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
     3.5  
     3.6 -<chapter>
     3.7 -<title>Open Publication License</title>
     3.8 -<para>\label{cha:opl}</para>
     3.9 +<appendix id="cha:opl">
    3.10 +  <?dbhtml filename="open-publication-license.html"?>
    3.11 +  <title>Open Publication License</title>
    3.12  
    3.13 -<para>Version 1.0, 8 June 1999</para>
    3.14 +  <para id="x_638">Version 1.0, 8 June 1999</para>
    3.15  
    3.16 -<sect1>
    3.17 -<title>Requirements on both unmodified and modified versions</title>
    3.18 +  <sect1>
    3.19 +    <title>Requirements on both unmodified and modified
    3.20 +      versions</title>
    3.21  
    3.22 -<para>The Open Publication works may be reproduced and distributed in whole
    3.23 -or in part, in any medium physical or electronic, provided that the
    3.24 -terms of this license are adhered to, and that this license or an
    3.25 -incorporation of it by reference (with any options elected by the
    3.26 -author(s) and/or publisher) is displayed in the reproduction.</para>
    3.27 +    <para id="x_639">The Open Publication works may be reproduced and distributed
    3.28 +      in whole or in part, in any medium physical or electronic,
    3.29 +      provided that the terms of this license are adhered to, and that
    3.30 +      this license or an incorporation of it by reference (with any
    3.31 +      options elected by the author(s) and/or publisher) is displayed
    3.32 +      in the reproduction.</para>
    3.33  
    3.34 -<para>Proper form for an incorporation by reference is as follows:</para>
    3.35 +    <para id="x_63a">Proper form for an incorporation by reference is as
    3.36 +      follows:</para>
    3.37  
    3.38 -<blockquote>
    3.39 -<para>  Copyright (c) <emphasis>year</emphasis> by <emphasis>author's name or designee</emphasis>. This
    3.40 -  material may be distributed only subject to the terms and conditions
    3.41 -  set forth in the Open Publication License, v<emphasis>x.y</emphasis> or later (the
    3.42 -  latest version is presently available at
    3.43 -  <ulink url="http://www.opencontent.org/openpub/">http://www.opencontent.org/openpub/</ulink>).</para>
    3.44 -</blockquote>
    3.45 +    <blockquote>
    3.46 +      <para id="x_63b">  Copyright (c) <emphasis>year</emphasis> by
    3.47 +	<emphasis>author's name or designee</emphasis>. This material
    3.48 +	may be distributed only subject to the terms and conditions
    3.49 +	set forth in the Open Publication License,
    3.50 +	v<emphasis>x.y</emphasis> or later (the latest version is
    3.51 +	presently available at <ulink
    3.52 +	  url="http://www.opencontent.org/openpub/">http://www.opencontent.org/openpub/</ulink>).</para>
    3.53 +    </blockquote>
    3.54  
    3.55 -<para>The reference must be immediately followed with any options elected by
    3.56 -the author(s) and/or publisher of the document (see
    3.57 -section <xref linkend="sec:opl:options"/>).</para>
    3.58 +    <para id="x_63c">The reference must be immediately followed with any options
    3.59 +      elected by the author(s) and/or publisher of the document (see
    3.60 +      <xref linkend="sec:opl:options"/>).</para>
    3.61  
    3.62 -<para>Commercial redistribution of Open Publication-licensed material is
    3.63 -permitted.</para>
    3.64 +    <para id="x_63d">Commercial redistribution of Open Publication-licensed
    3.65 +      material is permitted.</para>
    3.66  
    3.67 -<para>Any publication in standard (paper) book form shall require the
    3.68 -citation of the original publisher and author. The publisher and
    3.69 -author's names shall appear on all outer surfaces of the book. On all
    3.70 -outer surfaces of the book the original publisher's name shall be as
    3.71 -large as the title of the work and cited as possessive with respect to
    3.72 -the title.</para>
    3.73 +    <para id="x_63e">Any publication in standard (paper) book form shall require
    3.74 +      the citation of the original publisher and author. The publisher
    3.75 +      and author's names shall appear on all outer surfaces of the
    3.76 +      book. On all outer surfaces of the book the original publisher's
    3.77 +      name shall be as large as the title of the work and cited as
    3.78 +      possessive with respect to the title.</para>
    3.79  
    3.80 -</sect1>
    3.81 -<sect1>
    3.82 -<title>Copyright</title>
    3.83 +  </sect1>
    3.84 +  <sect1>
    3.85 +    <title>Copyright</title>
    3.86  
    3.87 -<para>The copyright to each Open Publication is owned by its author(s) or
    3.88 -designee.
    3.89 -</para>
    3.90 +    <para id="x_63f">The copyright to each Open Publication is owned by its
    3.91 +      author(s) or designee.</para>
    3.92  
    3.93 -</sect1>
    3.94 -<sect1>
    3.95 -<title>Scope of license</title>
    3.96 +  </sect1>
    3.97 +  <sect1>
    3.98 +    <title>Scope of license</title>
    3.99  
   3.100 -<para>The following license terms apply to all Open Publication works,
   3.101 -unless otherwise explicitly stated in the document.
   3.102 -</para>
   3.103 +    <para id="x_640">The following license terms apply to all Open Publication
   3.104 +      works, unless otherwise explicitly stated in the
   3.105 +      document.</para>
   3.106  
   3.107 -<para>Mere aggregation of Open Publication works or a portion of an Open
   3.108 -Publication work with other works or programs on the same media shall
   3.109 -not cause this license to apply to those other works. The aggregate
   3.110 -work shall contain a notice specifying the inclusion of the Open
   3.111 -Publication material and appropriate copyright notice.
   3.112 -</para>
   3.113 +    <para id="x_641">Mere aggregation of Open Publication works or a portion of
   3.114 +      an Open Publication work with other works or programs on the
   3.115 +      same media shall not cause this license to apply to those other
   3.116 +      works. The aggregate work shall contain a notice specifying the
   3.117 +      inclusion of the Open Publication material and appropriate
   3.118 +      copyright notice.</para>
   3.119  
   3.120 -<para><emphasis role="bold">Severability</emphasis>. If any part of this license is found to be
   3.121 -unenforceable in any jurisdiction, the remaining portions of the
   3.122 -license remain in force.
   3.123 -</para>
   3.124 +    <para id="x_642"><emphasis role="bold">Severability</emphasis>. If any part
   3.125 +      of this license is found to be unenforceable in any
   3.126 +      jurisdiction, the remaining portions of the license remain in
   3.127 +      force.</para>
   3.128  
   3.129 -<para><emphasis role="bold">No warranty</emphasis>. Open Publication works are licensed and provided
   3.130 -<quote>as is</quote> without warranty of any kind, express or implied, including,
   3.131 -but not limited to, the implied warranties of merchantability and
   3.132 -fitness for a particular purpose or a warranty of non-infringement.
   3.133 -</para>
   3.134 +    <para id="x_643"><emphasis role="bold">No warranty</emphasis>. Open
   3.135 +      Publication works are licensed and provided <quote>as is</quote>
   3.136 +      without warranty of any kind, express or implied, including, but
   3.137 +      not limited to, the implied warranties of merchantability and
   3.138 +      fitness for a particular purpose or a warranty of
   3.139 +      non-infringement.</para>
   3.140  
   3.141 -</sect1>
   3.142 -<sect1>
   3.143 -<title>Requirements on modified works</title>
   3.144 +  </sect1>
   3.145 +  <sect1>
   3.146 +    <title>Requirements on modified works</title>
   3.147  
   3.148 -<para>All modified versions of documents covered by this license, including
   3.149 -translations, anthologies, compilations and partial documents, must
   3.150 -meet the following requirements:
   3.151 -</para>
   3.152 +    <para id="x_644">All modified versions of documents covered by this license,
   3.153 +      including translations, anthologies, compilations and partial
   3.154 +      documents, must meet the following requirements:</para>
   3.155  
   3.156 -<orderedlist>
   3.157 -<listitem><para>The modified version must be labeled as such.
   3.158 -</para>
   3.159 -</listitem>
   3.160 -<listitem><para>The person making the modifications must be identified and the
   3.161 -  modifications dated.
   3.162 -</para>
   3.163 -</listitem>
   3.164 -<listitem><para>Acknowledgement of the original author and publisher if
   3.165 -  applicable must be retained according to normal academic citation
   3.166 -  practices.
   3.167 -</para>
   3.168 -</listitem>
   3.169 -<listitem><para>The location of the original unmodified document must be
   3.170 -  identified.
   3.171 -</para>
   3.172 -</listitem>
   3.173 -<listitem><para>The original author's (or authors') name(s) may not be used to
   3.174 -  assert or imply endorsement of the resulting document without the
   3.175 -  original author's (or authors') permission.
   3.176 -</para>
   3.177 -</listitem></orderedlist>
   3.178 +    <orderedlist>
   3.179 +      <listitem><para id="x_645">The modified version must be labeled as
   3.180 +	  such.</para>
   3.181 +      </listitem>
   3.182 +      <listitem><para id="x_646">The person making the modifications must be
   3.183 +	  identified and the modifications dated.</para>
   3.184 +      </listitem>
   3.185 +      <listitem><para id="x_647">Acknowledgement of the original author and
   3.186 +	  publisher if applicable must be retained according to normal
   3.187 +	  academic citation practices.</para>
   3.188 +      </listitem>
   3.189 +      <listitem><para id="x_648">The location of the original unmodified document
   3.190 +	  must be identified.</para>
   3.191 +      </listitem>
   3.192 +      <listitem><para id="x_649">The original author's (or authors') name(s) may
   3.193 +	  not be used to assert or imply endorsement of the resulting
   3.194 +	  document without the original author's (or authors')
   3.195 +	  permission.</para>
   3.196 +      </listitem></orderedlist>
   3.197  
   3.198 -</sect1>
   3.199 -<sect1>
   3.200 -<title>Good-practice recommendations</title>
   3.201 +  </sect1>
   3.202 +  <sect1>
   3.203 +    <title>Good-practice recommendations</title>
   3.204  
   3.205 -<para>In addition to the requirements of this license, it is requested from
   3.206 -and strongly recommended of redistributors that:
   3.207 -</para>
   3.208 +    <para id="x_64a">In addition to the requirements of this license, it is
   3.209 +      requested from and strongly recommended of redistributors
   3.210 +      that:</para>
   3.211  
   3.212 -<orderedlist>
   3.213 -<listitem><para>If you are distributing Open Publication works on hardcopy or
   3.214 -  CD-ROM, you provide email notification to the authors of your intent
   3.215 -  to redistribute at least thirty days before your manuscript or media
   3.216 -  freeze, to give the authors time to provide updated documents. This
   3.217 -  notification should describe modifications, if any, made to the
   3.218 -  document.
   3.219 -</para>
   3.220 -</listitem>
   3.221 -<listitem><para>All substantive modifications (including deletions) be either
   3.222 -  clearly marked up in the document or else described in an attachment
   3.223 -  to the document.
   3.224 -</para>
   3.225 -</listitem>
   3.226 -<listitem><para>Finally, while it is not mandatory under this license, it is
   3.227 -  considered good form to offer a free copy of any hardcopy and CD-ROM
   3.228 -  expression of an Open Publication-licensed work to its author(s).
   3.229 -</para>
   3.230 -</listitem></orderedlist>
   3.231 +    <orderedlist>
   3.232 +      <listitem><para id="x_64b">If you are distributing Open Publication works
   3.233 +	  on hardcopy or CD-ROM, you provide email notification to the
   3.234 +	  authors of your intent to redistribute at least thirty days
   3.235 +	  before your manuscript or media freeze, to give the authors
   3.236 +	  time to provide updated documents. This notification should
   3.237 +	  describe modifications, if any, made to the document.</para>
   3.238 +      </listitem>
   3.239 +      <listitem><para id="x_64c">All substantive modifications (including
   3.240 +	  deletions) be either clearly marked up in the document or
   3.241 +	  else described in an attachment to the document.</para>
   3.242 +      </listitem>
   3.243 +      <listitem><para id="x_64d">Finally, while it is not mandatory under this
   3.244 +	  license, it is considered good form to offer a free copy of
   3.245 +	  any hardcopy and CD-ROM expression of an Open
   3.246 +	  Publication-licensed work to its author(s).</para>
   3.247 +      </listitem></orderedlist>
   3.248  
   3.249 -</sect1>
   3.250 -<sect1>
   3.251 -<title>License options</title>
   3.252 -<para>\label{sec:opl:options}
   3.253 -</para>
   3.254 +  </sect1>
   3.255 +  <sect1 id="sec:opl:options">
   3.256 +    <title>License options</title>
   3.257  
   3.258 -<para>The author(s) and/or publisher of an Open Publication-licensed
   3.259 -document may elect certain options by appending language to the
   3.260 -reference to or copy of the license. These options are considered part
   3.261 -of the license instance and must be included with the license (or its
   3.262 -incorporation by reference) in derived works.
   3.263 -</para>
   3.264 +    <para id="x_64e">The author(s) and/or publisher of an Open
   3.265 +      Publication-licensed document may elect certain options by
   3.266 +      appending language to the reference to or copy of the license.
   3.267 +      These options are considered part of the license instance and
   3.268 +      must be included with the license (or its incorporation by
   3.269 +      reference) in derived works.</para>
   3.270  
   3.271 -<orderedlist>
   3.272 -<listitem><para>To prohibit distribution of substantively modified versions
   3.273 -  without the explicit permission of the author(s). <quote>Substantive
   3.274 -  modification</quote> is defined as a change to the semantic content of the
   3.275 -  document, and excludes mere changes in format or typographical
   3.276 -  corrections.
   3.277 -</para>
   3.278 -</listitem>
   3.279 -<listitem><para>  To accomplish this, add the phrase <quote>Distribution of substantively
   3.280 -  modified versions of this document is prohibited without the
   3.281 -  explicit permission of the copyright holder.</quote> to the license
   3.282 -  reference or copy.
   3.283 -</para>
   3.284 -</listitem>
   3.285 -</para>
   3.286 -</listitem>
   3.287 -<listitem><para>To prohibit any publication of this work or derivative works in
   3.288 -  whole or in part in standard (paper) book form for commercial
   3.289 -  purposes is prohibited unless prior permission is obtained from the
   3.290 -  copyright holder.
   3.291 -</para>
   3.292 -</listitem>
   3.293 -<listitem><para>  To accomplish this, add the phrase <quote>Distribution of the work or
   3.294 -  derivative of the work in any standard (paper) book form is
   3.295 -  prohibited unless prior permission is obtained from the copyright
   3.296 -  holder.</quote> to the license reference or copy.
   3.297 -</para>
   3.298 -</listitem></orderedlist>
   3.299 +    <orderedlist>
   3.300 +      <listitem><para id="x_64f">To prohibit distribution of substantively
   3.301 +	  modified versions without the explicit permission of the
   3.302 +	  author(s). <quote>Substantive modification</quote> is
   3.303 +	  defined as a change to the semantic content of the document,
   3.304 +	  and excludes mere changes in format or typographical
   3.305 +	  corrections.</para>
   3.306 +      </listitem>
   3.307 +      <listitem><para id="x_650">  To accomplish this, add the phrase
   3.308 +	  <quote>Distribution of substantively modified versions of
   3.309 +	    this document is prohibited without the explicit
   3.310 +	    permission of the copyright holder.</quote> to the license
   3.311 +	  reference or copy.</para>
   3.312 +      </listitem>
   3.313 +      <listitem><para id="x_651">To prohibit any publication of this work or
   3.314 +	  derivative works in whole or in part in standard (paper)
   3.315 +	  book form for commercial purposes is prohibited unless prior
   3.316 +	  permission is obtained from the copyright holder.</para>
   3.317 +      </listitem>
   3.318 +      <listitem><para id="x_652">To accomplish this, add the phrase
   3.319 +	  <quote>Distribution of the work or derivative of the work in
   3.320 +	    any standard (paper) book form is prohibited unless prior
   3.321 +	    permission is obtained from the copyright holder.</quote>
   3.322 +	  to the license reference or copy.</para>
   3.323 +      </listitem></orderedlist>
   3.324  
   3.325 -</sect1>
   3.326 -</chapter>
   3.327 +  </sect1>
   3.328 +</appendix>
   3.329  
   3.330  <!--
   3.331  local variables: 
   3.332 -sgml-parent-document: ("00book.xml" "book" "chapter")
   3.333 +sgml-parent-document: ("00book.xml" "book" "appendix")
   3.334  end:
   3.335 --->
   3.336 \ No newline at end of file
   3.337 +-->

     4.1 --- a/fr/ch00-preface.xml	Sat Sep 12 17:58:26 2009 +0200
     4.2 +++ b/fr/ch00-preface.xml	Sat Sep 12 17:58:56 2009 +0200
     4.3 @@ -8,13 +8,13 @@
     4.4      <title>Un conte technique</title>
     4.5  
     4.6      <para id="x_72e">Il y a quelques années, quand j'ai voulu expliqué
     4.7 -    pourquoi je pensais que le gestion de révision distribué est importante,
     4.8 +    pourquoi je pensais que le gestion de révision distribuée est importante,
     4.9      le domaine était encore si nouveau qu'il n'y avait presque aucune 
    4.10 -    littérature publiée pour servir de référence aux personnes intéressés.</para>
    4.11 -
    4.12 -    <para id="x_72f">Bien que à cette époque je passais beaucoup de temps
    4.13 +    littérature publiée pour servir de référence aux personnes intéressées.</para>
    4.14 +
    4.15 +    <para id="x_72f">Bien qu'à cette époque je passais beaucoup de temps
    4.16      à travailler sur les entrailles de Mercurial, je me suis mis à la 
    4.17 -    rédaction de ce livre parce qu'il me semblait la manière la plus efficase 
    4.18 +    rédaction de ce livre parce qu'il me semblait la manière la plus efficace
    4.19      d'aider notre logiciel à atteindre un vaste auditoire, toujours avec 
    4.20      l'idée que la gestion de révision devrait être distribuée par nature. J'ai 
    4.21      publié ce libre en ligne sous une licence libre pour la même raison : pour 
    4.22 @@ -24,54 +24,54 @@
    4.23      qui ressemble de près au fait de conter une histoire : Pourquoi ceci est ? 
    4.24      Pourquoi ceci est important ? Comment peut il m'aider ? Comment m'en 
    4.25      servir ? Dans ce livre, j'essaye de répondre à toutes ces questions pour
    4.26 -    la gestion de révision distribuée en générale, et pour Mercurial en 
    4.27 -    particuliers.</para>
    4.28 +    la gestion de révision distribuée en général, et pour Mercurial en 
    4.29 +    particulier.</para>
    4.30    </sect1>
    4.31      
    4.32    <sect1>
    4.33      <title>Merci de votre soutien à Mercurial</title>
    4.34  
    4.35      <para id="x_731">En achetant une copie de ce livre, vous soutenez le
    4.36 -    développement et la libérté de Mercurial en particulier, et dans 
    4.37 -    l'Open Source et du logiciel libre en général. O'Reilly Media et 
    4.38 -    moi-même donnons le revenu issu des ventes de ce livre à la
    4.39 +    développement et la liberté de Mercurial en particulier, et dans 
    4.40 +    l'Open Source, au logiciel libre en général. O'Reilly Media et 
    4.41 +    moi-même donnons les revenus issus des ventes de ce livre à la
    4.42      Software Freedom Conservancy (<ulink
    4.43          url="http://www.softwarefreedom.org/">http://www.softwarefreedom.org/</ulink>) 
    4.44        qui fournit un support juridique à Mercurial et à de 
    4.45 -      nombreux autres projets Open Source proméminent et de qualité.</para>
    4.46 +      nombreux autres projets Open Source proéminents et de qualité.</para>
    4.47    </sect1>
    4.48  
    4.49    <sect1>
    4.50      <title>Remerciements</title>
    4.51  
    4.52 -    <para id="x_732">Ce livre ne serait pas venu au jour sans les
    4.53 +    <para id="x_732">Ce livre n'aurait pas vu le jour sans les
    4.54      efforts de Matt Mackal, l'auteur et le chef du projet Mercurial.
    4.55 -    Il est assisté très efficasement par des centaines de contributeurs
    4.56 -    volontaire à travers le monde.</para>
    4.57 -
    4.58 -    <para id="x_733">Les enfants, Cian and Ruairi, ont toujours été prêt
    4.59 -    à m'aider à me reposer avec de merveilleux, impulsif jeux d'enfants. 
    4.60 +    Il est assisté très efficacement par des centaines de contributeurs
    4.61 +    volontaires à travers le monde.</para>
    4.62 +
    4.63 +    <para id="x_733">Les enfants, Cian et Ruairi, ont toujours été prêt
    4.64 +    à m'aider à me reposer avec de merveilleux et impulsif jeux d'enfants. 
    4.65      Je tiens aussi à remercier mon ex-femme, Shannon, pour son soutien.
    4.66      </para>
    4.67  
    4.68      <para id="x_734">Mes collègues et amis m'ont aidé et assisté de 
    4.69 -    de nombreuse manière indénombrable. Cette liste de personne est 
    4.70 -    nécessaire mais très incomplète : Stephen Hahn, Karyn Ritter, 
    4.71 -    Bonnie Corwin, James Vasile, Matt Norwood, Eben Moglen, Bradley Kuhn, 
    4.72 -    Robert Walsh, Jeremy Fitzhardinge, Rachel Chalmers.</para>
    4.73 +    de nombreuses manières. Cette liste de personne est nécessaire mais très
    4.74 +    incomplète : Stephen Hahn, Karyn Ritter, Bonnie Corwin, James Vasile,
    4.75 +    Matt Norwood, Eben Moglen, Bradley Kuhn, Robert Walsh, Jeremy
    4.76 +    Fitzhardinge, Rachel Chalmers.</para>
    4.77  
    4.78      <para id="x_735">J'ai conçu ce livre de manière ouverte, en publiant
    4.79 -    des brouillons des chapitres du libre sur des site web, au fur et à 
    4.80 -    mesure que je les réalisés. Leurs lecteurs m'ont fait des retours 
    4.81 -    utilisant l'application web que j'avais développé. A la fin de sa
    4.82 +    des brouillons des chapitres du livre sur des site web, au fur et à 
    4.83 +    mesure que je les réalisais. Leurs lecteurs m'ont fait des retours 
    4.84 +    utilisant l'application web que j'avais développée. A la fin de sa
    4.85      conception, plus de 100 personnes m'avaient fait des commentaires, 
    4.86      un chiffre incroyable quand l'on considère que ce système de 
    4.87 -    commentaire n'a tourné que dans les deux dernièrs mois de la 
    4.88 +    commentaire n'a tourné que dans les deux derniers mois de la 
    4.89      rédaction du livre.</para>
    4.90  
    4.91      <para id="x_736">J'aimerais particulièrement remercier les 
    4.92      personnes suivantes, dont les commentaires représentent plus
    4.93 -    d'un tiers des l'ensemble de ces derniers. Je voudrais les 
    4.94 +    d'un tiers de l'ensemble de ces derniers. Je voudrais les 
    4.95      remercier pour leur attention et effort à me faire des retours
    4.96      très détaillés.</para>
    4.97  
    4.98 @@ -113,15 +113,16 @@
    4.99    <sect1>
   4.100      <title>Conventions utilisées dans ce livre</title>
   4.101  
   4.102 -    <para id="x_73a">Les conventions typographiques suivantes sont utilisées dans ce livre.:</para>
   4.103 +    <para id="x_73a">Les conventions typographiques suivantes sont utilisées dans ce livre :</para>
   4.104  
   4.105      <variablelist>
   4.106        <varlistentry>
   4.107          <term>Italique</term>
   4.108  
   4.109          <listitem>
   4.110 -          <para id="x_73b">Indique les termes nouveaux, les URLs, les adresse mail, les noms de fichiers,
   4.111 -            et les extensions de fichier.</para>
   4.112 +          <para id="x_73b">Indique les termes nouveaux, les URLs, les
   4.113 +            adresses mail, les noms de fichiers et les extensions de
   4.114 +            fichier.</para>
   4.115          </listitem>
   4.116        </varlistentry>
   4.117  
   4.118 @@ -129,11 +130,11 @@
   4.119          <term><literal>Taille constante</literal></term>
   4.120  
   4.121          <listitem>
   4.122 -          <para id="x_73c">Utilisé pour les extrait de code, comme 
   4.123 +          <para id="x_73c">Utilisé pour les extraits de code, comme 
   4.124            dans les paragraphes pour référer aux éléments du programme,
   4.125 -          tel que les variables ou les noms de fonctions, de base
   4.126 -          de données, de types de données, de variables d'environement,
   4.127 -          d'instructions, et de mot clés.</para>
   4.128 +          tels que les variables ou les noms de fonctions, de bases
   4.129 +          de données, de types de données, de variables d'environnement,
   4.130 +          d'instructions, et de mots clés.</para>
   4.131          </listitem>
   4.132        </varlistentry>
   4.133  
   4.134 @@ -142,7 +143,7 @@
   4.135  
   4.136          <listitem>
   4.137            <para id="x_73d">Afficher les commandes ou autres textes qui
   4.138 -          devraient saisie par l'utilisateur.</para>
   4.139 +          devraient être saisis par l'utilisateur.</para>
   4.140          </listitem>
   4.141        </varlistentry>
   4.142  
   4.143 @@ -158,20 +159,20 @@
   4.144      </variablelist>
   4.145  
   4.146      <tip>
   4.147 -      <para id="x_73f">Cette icone indique une astuce, une suggestion ou 
   4.148 +      <para id="x_73f">Cette icône indique une astuce, une suggestion ou 
   4.149        une note d'ordre général.</para>
   4.150      </tip>
   4.151  
   4.152      <caution>
   4.153 -      <para id="x_740">Cette icone est un message d'alerte ou de prudence.</para>
   4.154 +      <para id="x_740">Cette icône est un message d'alerte ou de prudence.</para>
   4.155      </caution>
   4.156    </sect1>
   4.157  
   4.158    <sect1>
   4.159 -    <title>Utiliser les examples de codes</title>
   4.160 +    <title>Utiliser les exemples de code</title>
   4.161  
   4.162      <para id="x_741">Ce livre est ici pour vous aider dans votre
   4.163 -    travail. De manière général, vous pouvez donc utiliser le code
   4.164 +    travail. De manière générale, vous pouvez donc utiliser le code
   4.165      de ce livre dans vos programmes et votre documentation. Vous
   4.166      n'avez pas à nous contacter pour nous demander la permission
   4.167      de le faire, à moins que vous ne reproduisiez une partie significative
   4.168 @@ -199,17 +200,17 @@
   4.169  
   4.170      <note role="safarienabled">
   4.171        <para id="x_744">Quand vous voyez l'icône de Safari® Books Online 
   4.172 -      sur la couverture d'un de vos livres techniques préféré, il signifie
   4.173 +      sur la couverture d'un de vos livres techniques préférés, cela signifie
   4.174        que le livre est disponible, en ligne, à travers le O’Reilly Network Safari
   4.175          Bookshelf.</para>
   4.176      </note>
   4.177  
   4.178 -    <para id="x_745">Safari offre une solution qui est meilleur que
   4.179 +    <para id="x_745">Safari offre une solution qui est meilleure que
   4.180      les e-books. C'est une bibliothèque virtuelle qui vous laisse
   4.181      aisément rechercher dans des milliers de livres, mais aussi 
   4.182 -    copier-coller leur exemples, télécharger des chapitres, et 
   4.183 +    copier-coller leurs exemples, télécharger des chapitres, et 
   4.184      trouver des réponses rapides quand vous avez besoin d'une 
   4.185 -    information précise et à jour. Essaye le gratuitement :
   4.186 +    information précise et à jour. Essayez le gratuitement :
   4.187      <ulink role="orm:hideurl:ital"
   4.188          url="http://my.safaribooksonline.com/?portal=oreilly">http://my.safaribooksonline.com</ulink>.</para>
   4.189    </sect1>
   4.190 @@ -254,8 +255,8 @@
   4.191      </simplelist>
   4.192  
   4.193      <para id="x_749">Pour plus d'informations sur nos livres, nos
   4.194 -    conférences, nos centre d'informations, et le O’Reilly Network, 
   4.195 -    voyez notre site  web site:</para>
   4.196 +    conférences, nos centres d'informations, et le réseau O’Reilly, 
   4.197 +    voyez notre site web :</para>
   4.198  
   4.199      <simplelist type="vert">
   4.200        <member><ulink url="http://www.oreilly.com"></ulink></member>

     5.1 --- a/fr/ch01-intro.xml	Sat Sep 12 17:58:26 2009 +0200
     5.2 +++ b/fr/ch01-intro.xml	Sat Sep 12 17:58:56 2009 +0200
     5.3 @@ -14,7 +14,7 @@
     5.4  à chaque fois plus grand que celui de la version précédente.</para>
     5.5  
     5.6      <para id="x_6e">Ce genre de gestion de version manuelle est cependant facilement sujette
     5.7 -à des erreurs, ainsi, depuis longtemps, des logiciels existent pour
     5.8 +aux erreurs, ainsi, depuis longtemps, des logiciels existent pour
     5.9  résoudre cette problématique. Les premiers outils de gestion de sources
    5.10  étaient destinés à aider un seul utilisateur, à automatiser la gestion
    5.11  des versions d'un seul fichier. Dans les dernières décades, cette cible
    5.12 @@ -26,15 +26,15 @@
    5.13  
    5.14      <para id="x_6f">L'arrivée de la gestion de révision distribuée est
    5.15      relativement récente, et, pour le moment, ce nouveau domaine a grandi
    5.16 -    grâce à la volonté des gens d'explorer ces territoires encores inconnues.
    5.17 +    grâce à la volonté des gens d'explorer ces territoires encore inconnus.
    5.18      </para>
    5.19  
    5.20      <para id="x_70">J'écris un livre sur la gestion de révision distribuée
    5.21      parce que je pense qu'il s'agit d'un sujet important qui mérite un guide
    5.22      du terrain. J'ai choisi d'écrire un livre sur Mercurial car il est
    5.23      l'outil le plus facile pour découvrir ce nouveau domaine, tout en étant
    5.24 -    un outil efficase qui répond aux demandes d'environement réel et
    5.25 -    difficile, là où d'autres outils de révisions s'effondre.</para>
    5.26 +    un outil efficace qui répond aux demandes d'environnements réels et
    5.27 +    difficiles, là où d'autres outils de gestions de versions s'effondrent.</para>
    5.28  
    5.29      <sect2>
    5.30        <title>Pourquoi utiliser un gestionnaire de source ?</title>
    5.31 @@ -44,10 +44,10 @@
    5.32  
    5.33        <itemizedlist>
    5.34  	<listitem><para id="x_72">L'outil se chargera de suivre l'évolution de votre projet, sans
    5.35 -que vous n'ayez à le faire. Pour chaque modification, vous aurez à votre
    5.36 +que vous ayez à le faire. Pour chaque modification, vous aurez à votre
    5.37  disposition un journal indiquant <emphasis>qui</emphasis> a fait quoi, <emphasis>pourquoi</emphasis>
    5.38 -ils l'ont fait, <emphasis>quand</emphasis> ils l'ont fait, et <emphasis>ce</emphasis> qu'ils ont
    5.39 -modifiés.</para>
    5.40 +il l'a fait, <emphasis>quand</emphasis> il l'a fait, et
    5.41 +<emphasis>ce</emphasis> qu'il a modifié.</para>
    5.42  </listitem>
    5.43  <listitem><para id="x_73">Quand vous travaillez avec d'autres personnes, les logiciels de
    5.44  gestion de source facilitent le travail collaboratif. Par exemple, quand
    5.45 @@ -62,42 +62,48 @@
    5.46  de détails).</para>
    5.47  </listitem>
    5.48  <listitem><para id="x_75">L'outil vous permettra aussi de travailler sur plusieurs versions différentes
    5.49 -de votre projet et à gérer l'écart entre chacune.</para>
    5.50 +de votre projet et de gérer l'écart entre chacune.</para>
    5.51  </listitem></itemizedlist>
    5.52 -<para id="x_76">La plupart de ces raisons ont autant d'importances &emdash;du moins en théorie&emdash; que
    5.53 -vous travailliez sur un projet pour vous, ou avec une centaine d'autres
    5.54 -personnes.
    5.55 +<para id="x_76">La plupart de ces raisons ont autant d'importances &emdash;du
    5.56 +  moins en théorie&emdash; que vous travailliez sur un projet pour vous, ou
    5.57 +  avec une centaine d'autres personnes.
    5.58  </para>
    5.59  
    5.60 -<para id="x_77">Une question fondamentale à propos des outils de gestion de source, qu'il s'agisse
    5.61 -du projet d'une personne ou d'une grande équipe, est quels sont ses
    5.62 -<emphasis>avantages</emphasis> par rapport à ses <emphasis>coûts</emphasis>. Un outil qui est difficile à
    5.63 -utiliser ou à comprendre exigera un lourd effort d'adaptation.
    5.64 +<para id="x_77">Une question fondamentale à propos des outils de gestion de
    5.65 +  source, qu'il s'agisse du projet d'une personne ou d'une grande équipe, est
    5.66 +  quels sont ses <emphasis>avantages</emphasis> par rapport à ses
    5.67 +  <emphasis>coûts</emphasis>. Un outil qui est difficile à utiliser ou à
    5.68 +  comprendre exigera un lourd effort d'adaptation.
    5.69  </para>
    5.70  
    5.71 -<para id="x_78">)Un projet de cinq milles personnes s'effondrera très certainement de lui même
    5.72 -sans aucun processus et outil de gestion de source. Dans ce cas, le coût
    5.73 -d'utilisation d'un logiciel de gestion de source est dérisoire puisque
    5.74 -<emphasis>sans</emphasis>, l'échec est presque garanti.
    5.75 +<para id="x_78">)Un projet de cinq milles personnes s'effondrera très
    5.76 +  certainement de lui même sans aucun processus et outil de gestion de
    5.77 +  source. Dans ce cas, le coût d'utilisation d'un logiciel de gestion de
    5.78 +  source est dérisoire puisque <emphasis>sans</emphasis>, l'échec est presque
    5.79 +  garanti.
    5.80  </para>
    5.81  
    5.82 -<para id="x_79">D'un autre coté, un <quote>rapide hack</quote> d'une personne peut sembler un contexte
    5.83 -bien pauvre pour utiliser un outil de gestion de source, car, bien évidement
    5.84 -le coût d'utilisation dépasse le coût total du projet. N'est ce pas ?
    5.85 +<para id="x_79">D'un autre coté, un <quote>rapide hack</quote> d'une personne
    5.86 +  peut sembler un contexte bien pauvre pour utiliser un outil de gestion de
    5.87 +  source, car, bien évidement le coût d'utilisation dépasse le coût total du
    5.88 +  projet. N'est ce pas ?
    5.89  </para>
    5.90  
    5.91 -      <para id="x_7a">Mercurial supporte ces <emphasis>deux</emphasis> échelles de travail. Vous pouvez apprendre
    5.92 -les bases en quelques minutes seulement, et, grâce à sa performance, vous pouvez
    5.93 -l'utiliser avec facilité sur le plus petit des projets. Cette simplicité
    5.94 -signifie que vous n'avez pas de concept obscurs ou de séquence de commandes
    5.95 -défiant l'imagination, sans aucune corrélation avec <emphasis>ce que vous
    5.96 -êtes entrain de faire</emphasis>. En même temps, ces mêmes performances et sa
    5.97 -nature <quote>peer-to-peer</quote> vous permettent d'augmenter, sans difficulté, son
    5.98 -utilisation à de très grands projets.
    5.99 +      <para id="x_7a">Mercurial supporte ces <emphasis>deux</emphasis>
   5.100 +        échelles de travail. Vous pouvez apprendre les bases en quelques
   5.101 +        minutes seulement, et, grâce à sa performance, vous pouvez l'utiliser
   5.102 +        avec facilité sur le plus petit des projets. Cette simplicité
   5.103 +        signifie que vous n'avez pas de concept obscurs ou de séquence de
   5.104 +        commandes défiant l'imagination, sans aucune corrélation avec
   5.105 +        <emphasis>ce que vous êtes entrain de faire</emphasis>. En même
   5.106 +        temps, ces mêmes performances et sa nature
   5.107 +        <quote>peer-to-peer</quote> vous permettent d'adapter, sans
   5.108 +        difficulté, son utilisation à de très grands projets.
   5.109  </para>
   5.110  
   5.111 -      <para id="x_7b">Aucun outil de gestion de source ne peut sauver un projet mal mené, mais un
   5.112 -bon outil peut rendre beaucoup plus fluide votre travail.
   5.113 +      <para id="x_7b">Aucun outil de gestion de source ne peut sauver un
   5.114 +        projet mal mené, mais un bon outil peut rendre beaucoup plus fluide
   5.115 +        votre travail.
   5.116  </para>
   5.117  
   5.118      </sect2>
   5.119 @@ -105,19 +111,21 @@
   5.120      <sect2>
   5.121        <title>Les multiples noms de la gestion de source</title>
   5.122  
   5.123 -      <para id="x_7c">La gestion de source<!--
   5.124 -      TODO:<footnote><J'ai utilisé systématiquement le terme
   5.125 -<quote>gestion de source</quote> à travers tout l'ouvrage. Ce n'est pas forcement la
   5.126 -meilleure traduction, et ceci peut rendre la lecture un peu lourde, mais je
   5.127 -pense que le document y gagne en clarté et en précision. --> est un domaine
   5.128 -divers, tellement qu'il n'existe pas une seul nom ou acronyme pour le désigner.
   5.129 -Voilà quelqu'uns des noms ou
   5.130 -acronymes que vous rencontrerez le plus souvent <!-- TODO:<footnote> J'ai conservé la
   5.131 -liste des noms en anglais pour des raisons de commodité (ils sont plus
   5.132 -<quote>googelable</quote>). En outre, j'ai opté  pour conserver l'ensemble des opérations de
   5.133 -Mercurial (\textit{commit},\textit{push}, \textit{pull},...) en anglais, là
   5.134 -aussi pour faciliter la lecture d'autres documents en anglais, ainsi que
   5.135 -l'utilisation de Mercurial. -->
   5.136 +      <para id="x_7c">La gestion de source
   5.137 +        <!-- TODO:<footnote><J'ai utilisé systématiquement le terme
   5.138 +            <quote>gestion de source</quote> à travers tout l'ouvrage. Ce
   5.139 +            n'est pas forcement la meilleure traduction, et ceci peut rendre
   5.140 +            la lecture un peu lourde, mais je pense que le document y gagne
   5.141 +            en clarté et en précision. -->
   5.142 +        est un domaine tellement large qu'il n'existe pas qu'un seul nom ou
   5.143 +        acronyme pour le désigner. Voici quelques noms ou acronymes que vous
   5.144 +        rencontrerez le plus souvent.
   5.145 +        <!-- TODO:<footnote> J'ai conservé la liste des noms en anglais pour
   5.146 +          des raisons de commodité (ils sont plus <quote>googelable</quote>).
   5.147 +          En outre, j'ai opté  pour conserver l'ensemble des opérations de
   5.148 +          Mercurial (\textit{commit},\textit{push}, \textit{pull},...) en
   5.149 +          anglais, là aussi pour faciliter la lecture d'autres documents en
   5.150 +          anglais, ainsi que l'utilisation de Mercurial. -->
   5.151  </para>
   5.152  
   5.153  <para>:
   5.154 @@ -125,58 +133,60 @@
   5.155  
   5.156        <itemizedlist>
   5.157  	<listitem><para id="x_7d">Revision control (RCS)</para></listitem>
   5.158 -	<listitem><para id="x_7e">Software configuration management (SCM), or
   5.159 +	<listitem><para id="x_7e">Software configuration management (SCM), ou
   5.160  	    configuration management</para></listitem>
   5.161  	<listitem><para id="x_7f">Source code management</para></listitem>
   5.162 -	<listitem><para id="x_80">Source code control, or source
   5.163 -	    control</para></listitem>
   5.164 -	<listitem><para id="x_81">Version control
   5.165 -	    (VCS)</para></listitem></itemizedlist>
   5.166 -
   5.167 - <para id="x_82">Certaines personnes prétendent que ces termes ont en fait des sens
   5.168 -différents mais en pratique ils se recouvrent tellement qu'il n'y a pas
   5.169 -réellement de manière pertinente de les distinguer.
   5.170 -</para>
   5.171 +	<listitem><para id="x_80">Source code control, ou source control</para></listitem>
   5.172 +	<listitem><para id="x_81">Version control (VCS)</para></listitem></itemizedlist>
   5.173 +
   5.174 + <para id="x_82">Certaines personnes prétendent que ces termes ont en fait
   5.175 +   des sens différents mais en pratique ils se recouvrent tellement qu'il n'y
   5.176 +   a pas réellement de manière pertinente de les distinguer. </para>
   5.177  
   5.178      </sect2>
   5.179    </sect1>
   5.180  
   5.181    <sect1>
   5.182  
   5.183 -<title>About the examples in this book</title>
   5.184 -
   5.185 -    <para id="x_84">This book takes an unusual approach to code samples.  Every
   5.186 -      example is <quote>live</quote>&emdash;each one is actually the result
   5.187 -      of a shell script that executes the Mercurial commands you see.
   5.188 -      Every time an image of the book is built from its sources, all
   5.189 -      the example scripts are automatically run, and their current
   5.190 -      results compared against their expected results.</para>
   5.191 -
   5.192 -    <para id="x_85">The advantage of this approach is that the examples are
   5.193 -      always accurate; they describe <emphasis>exactly</emphasis> the
   5.194 -      behavior of the version of Mercurial that's mentioned at the
   5.195 -      front of the book.  If I update the version of Mercurial that
   5.196 -      I'm documenting, and the output of some command changes, the
   5.197 -      build fails.</para>
   5.198 -
   5.199 -    <para id="x_86">There is a small disadvantage to this approach, which is
   5.200 -      that the dates and times you'll see in examples tend to be
   5.201 -      <quote>squashed</quote> together in a way that they wouldn't be
   5.202 -      if the same commands were being typed by a human.  Where a human
   5.203 -      can issue no more than one command every few seconds, with any
   5.204 -      resulting timestamps correspondingly spread out, my automated
   5.205 -      example scripts run many commands in one second.</para>
   5.206 -
   5.207 -    <para id="x_87">As an instance of this, several consecutive commits in an
   5.208 -      example can show up as having occurred during the same second.
   5.209 -      You can see this occur in the <literal
   5.210 -	role="hg-ext">bisect</literal> example in <xref
   5.211 -	linkend="sec:undo:bisect"/>, for instance.</para>
   5.212 -
   5.213 -    <para id="x_88">So when you're reading examples, don't place too much weight
   5.214 -      on the dates or times you see in the output of commands.  But
   5.215 -      <emphasis>do</emphasis> be confident that the behavior you're
   5.216 -      seeing is consistent and reproducible.</para>
   5.217 +<title>A propos des exemples dans ce livre</title>
   5.218 +
   5.219 +    <para id="x_84">Ce livre prend une approche non usuel pour les exemples
   5.220 +      de code. Tous les exemples sont en <quote>live</quote> &emdash; Chacun
   5.221 +      est actuellement le résultat d'un script shell qui exécute les
   5.222 +      commandes Mercurial que vous voyez. A chaque fois qu'une image du livre
   5.223 +      est construite à partir des sources, tous les scripts d'exemple sont
   5.224 +      lancés automatiquement, et leurs résultats effectifs sont comparés aux
   5.225 +      résultats attendus.</para>
   5.226 +
   5.227 +    <para id="x_85">L'avantage de dette approche est que les exemples sont
   5.228 +      toujours précis ; ils décrivent <emphasis>exactement</emphasis> la
   5.229 +      conduite de la version de Mercurial qui est mentionnée en entête du
   5.230 +      livre. Si je met à jour la version de Mercurial que je suis en train de
   5.231 +      documenter, et que la sortie de certaines commandes change, la
   5.232 +      construction du livre échoue.</para>
   5.233 +
   5.234 +    <para id="x_86">
   5.235 +      Il existe un petit désavantage à cette approche qui est que les dates et
   5.236 +      heures que vous verrez dans les exemples tendent à être
   5.237 +      <quote>écrasés</quote> ensemble, dans le sens où elles ne sont pas
   5.238 +      celles qu'elles auraient été si un humain avait tapé les commandes. En
   5.239 +      effet, humain ne peut pas taper plus d'une commande toutes les quelques
   5.240 +      secondes, avec le temps qui s'écoule, mes scripts d'exemples exécutent
   5.241 +      plusieurs commandes en une seconde.
   5.242 +    </para>
   5.243 +
   5.244 +    <para id="x_87">Une circonstance de ceci est que plusieurs commits
   5.245 +      consécutifs dans un exemple peuvent apparaître comme ayant eu lieu
   5.246 +      durant la même seconde.
   5.247 +      Vous pouvez observer le phénomène dans l'exemple <literal
   5.248 +        role="hg-ext">bisect</literal> dans <xref linkend="sec:undo:bisect"/>
   5.249 +    </para>
   5.250 +
   5.251 +    <para id="x_88">Donc, lorsque vous lisez ces exemples, ne prêtez pas trop
   5.252 +      d'importance aux dates et heures que vous voyez dans la sortie des
   5.253 +      commandes. Cependant, <emphasis>soyez</emphasis> confiants que le
   5.254 +      comportement que vous voyez est consistent et reproductible 
   5.255 +    </para>
   5.256  
   5.257    </sect1>
   5.258  
   5.259 @@ -185,604 +195,657 @@
   5.260    <sect1>
   5.261      <title>Tendances de la gestion de source</title>
   5.262  
   5.263 -    <para id="x_89">Il y a eu une tendance évidente dans le développement et l'utilisation d'outils
   5.264 -de gestion de source depuis les quatre dernières décades, au fur et à mesure
   5.265 -que les utilisateurs se sont habitués à leur outils et se sont sentis contraints
   5.266 -par leurs limitations.
   5.267 -</para>
   5.268 -
   5.269 -    <para id="x_8a">La première génération commença simplement par gérer un fichier unique sur un
   5.270 -ordinateur individuel. Cependant, même si ces outils présentaient une grande
   5.271 -avancée par rapport à la gestion manuelle des versions, leur modèle de
   5.272 -verrouillage et leur utilisation limitée à un seul ordinateur rendaient leur
   5.273 -utilisation possible uniquement dans une très petite équipe.
   5.274 -</para>
   5.275 -
   5.276 -    <para id="x_8b">La seconde génération a assoupli ces contraintes en adoptant une architecture
   5.277 -réseau et centralisée, permettant de gérer plusieurs projets entiers en même
   5.278 -temps. Alors que les projets grandirent en taille, ils rencontrèrent de nouveaux
   5.279 -problèmes. Avec les clients discutant régulièrement avec le serveurs, la montée
   5.280 -en charge devint un réel problème sur les gros projets. Une connexion réseau
   5.281 -peu fiable pouvait complètement empêcher les utilisateurs distants de dialoguer
   5.282 -avec le serveur. Alors que les projets <emphasis remap="it">Open Source</emphasis> commencèrent à
   5.283 -mettre en place des accès en lecture seule disponible anonymement, les
   5.284 -utilisateurs sans les privilèges de <quote>commit</quote> réalisèrent qu'ils ne pouvaient
   5.285 -pas utiliser les outils pour collaborer naturellement avec le projet, comme ils
   5.286 -ne pouvaient pas non plus enregistrer leurs modifications.
   5.287 -</para>
   5.288 -
   5.289 -    <para id="x_8c">La génération actuelle des outils de gestion de source est <quote>peer-to-peer</quote> par
   5.290 -nature. Tout ces systèmes ont abandonné la dépendance à un serveur central, et
   5.291 -ont permis à leur utilisateur de distribuer les données de leur gestion de
   5.292 -source à qui en a besoin. La collaboration à travers Internet a transformé la
   5.293 -contrainte technologique en une simple question de choix et de consencus. Les
   5.294 -outils modernes peuvent maintenant fonctionner en mode déconnecté sans limite et
   5.295 -de manière autonome, la connexion au réseau n'étant nécessaire que pour
   5.296 -synchroniser les modifications avec les autres dépôts.
   5.297 -</para>
   5.298 -
   5.299 +    <para id="x_89">Il y a eu une tendance évidente dans le développement et
   5.300 +      l'utilisation d'outils de gestion de source depuis les quatre dernières
   5.301 +      décades, au fur et à mesure que les utilisateurs se sont habitués à
   5.302 +      leur outils et se sont sentis contraints par leurs limitations.
   5.303 +    </para>
   5.304 +
   5.305 +    <para id="x_8a">La première génération commença simplement par gérer un
   5.306 +      fichier unique sur un ordinateur individuel. Cependant, même si ces
   5.307 +      outils présentaient une grande avancée par rapport à la gestion
   5.308 +      manuelle des versions, leur modèle de verrouillage et leur utilisation
   5.309 +      limitée à un seul ordinateur rendaient leur utilisation possible
   5.310 +      uniquement dans une très petite équipe.
   5.311 +    </para>
   5.312 +
   5.313 +    <para id="x_8b">La seconde génération a assoupli ces contraintes en
   5.314 +      adoptant une architecture réseau et centralisée, permettant de gérer
   5.315 +      plusieurs projets entiers en même temps. Alors que les projets
   5.316 +      grandirent en taille, ils rencontrèrent de nouveaux problèmes. Avec les
   5.317 +      clients discutant régulièrement avec le serveurs, la montée en charge
   5.318 +      devint un réel problème sur les gros projets. Une connexion réseau peu
   5.319 +      fiable pouvait complètement empêcher les utilisateurs distants de
   5.320 +      dialoguer avec le serveur. Alors que les projets <emphasis
   5.321 +        remap="it">Open Source</emphasis> commencèrent à mettre en place des
   5.322 +      accès en lecture seule disponible anonymement, les utilisateurs sans
   5.323 +      les privilèges de <quote>commit</quote> réalisèrent qu'ils ne pouvaient
   5.324 +      pas utiliser les outils pour collaborer naturellement avec le projet,
   5.325 +      comme ils ne pouvaient pas non plus enregistrer leurs modifications.
   5.326 +    </para>
   5.327 +
   5.328 +    <para id="x_8c">La génération actuelle des outils de gestion de source
   5.329 +      est <quote>peer-to-peer</quote> par nature. Tous ces systèmes ont
   5.330 +      abandonné la dépendance à un serveur central, et ont permis à leur
   5.331 +      utilisateur de distribuer les données de leur gestion de source à qui
   5.332 +      en a besoin. La collaboration à travers Internet a transformé la
   5.333 +      contrainte technologique en une simple question de choix et de
   5.334 +      consensus. Les outils modernes peuvent maintenant fonctionner en mode
   5.335 +      déconnecté sans limite et de manière autonome, la connexion au réseau
   5.336 +      n'étant nécessaire que pour synchroniser les modifications avec les
   5.337 +      autres dépôts.
   5.338 +    </para>
   5.339    </sect1>
   5.340 +    
   5.341    <sect1>
   5.342      <title>Quelques avantages des gestionnaires de source distribués</title>
   5.343 -
   5.344 -<para id="x_8d">Même si les gestionnaire de source distribués sont depuis plusieurs années
   5.345 -assez robustes et aussi utilisables que leurs prédécesseurs, les utilisateurs
   5.346 -d'autres outils n'y ont pas encore été sensibilisés. Les gestionnaires
   5.347 -de source distribués se distinguent particulièrement de leurs équivalents
   5.348 -centralisés de nombreuses manières.
   5.349 -</para>
   5.350 -
   5.351 -    <para id="x_8e">Pour un développeur individuel, ils restent beaucoup plus rapides que les
   5.352 -outils centralisés. Cela pour une raison simple : un outil centralisé doit
   5.353 -toujours dialoguer à travers le réseau pour la plupart des opérations, car
   5.354 -presque toutes les métadonnées sont stockées sur la seule copie du serveur
   5.355 -central. Un outil distribué stocke toute ses métadonnées localement. À tâche
   5.356 -égale, effectuer un échange avec le réseau ajoute un délai aux outils
   5.357 -centralisés. Ne sous-estimez pas la valeur d'un outil rapide : vous allez
   5.358 -passer beaucoup de temps à interagir avec un logiciel de gestion de source.
   5.359 -</para>
   5.360 -
   5.361 -    <para id="x_8f">Les outils distribués sont complètement indépendants des aléas de votre serveur,
   5.362 -d'autant plus qu'ils répliquent les métadonnées à beaucoup d'endroits. Si
   5.363 -votre serveur central prend feu, vous avez intérêt à ce que les médias de
   5.364 -sauvegardes soient fiables, et que votre dernier <quote>backup</quote> soit récent et
   5.365 -fonctionne sans problème. Avec un outil distribué, vous avez autant de
   5.366 -<quote>backup</quote> que de contributeurs.
   5.367 -</para>
   5.368 -
   5.369 -    <para id="x_90">En outre, la fiabilité de votre réseau affectera beaucoup moins les
   5.370 -outils distribués. Vous ne pouvez même pas utiliser un outil centralisé
   5.371 -sans connexion réseau, à l'exception de quelques commandes, très limitées.
   5.372 -Avec un outil distribué, si votre connexion réseau tombe pendant que vous
   5.373 -travaillez, vous pouvez ne même pas vous en rendre compte. La seule chose
   5.374 -que vous ne serez pas capable de faire sera de communiquer avec des dépôts
   5.375 -distants, opération somme toute assez rare en comparaison aux opérations
   5.376 -locales. Si vous avez une équipe de collaborateurs très dispersée ceci peut
   5.377 -être significatif.
   5.378 -</para>
   5.379 -
   5.380 +      
   5.381 +    <para id="x_8d">Même si les gestionnaire de source distribués sont depuis
   5.382 +      plusieurs années assez robustes et aussi utilisables que leurs
   5.383 +      prédécesseurs, les utilisateurs d'autres outils n'y ont pas encore été
   5.384 +      sensibilisés. Les gestionnaires de source distribués se distinguent
   5.385 +      particulièrement de leurs équivalents centralisés de nombreuses
   5.386 +      manières.
   5.387 +    </para>
   5.388 +
   5.389 +    <para id="x_8e">Pour un développeur individuel, ils restent beaucoup plus
   5.390 +      rapides que les outils centralisés. Cela pour une raison simple : un
   5.391 +      outil centralisé doit toujours dialoguer à travers le réseau pour la
   5.392 +      plupart des opérations, car presque toutes les métadonnées sont
   5.393 +      stockées sur la seule copie du serveur central. Un outil distribué
   5.394 +      stocke toute ses métadonnées localement. À tâche égale, effectuer un
   5.395 +      échange avec le réseau ajoute un délai aux outils centralisés. Ne
   5.396 +      sous-estimez pas la valeur d'un outil rapide : vous allez passer
   5.397 +      beaucoup de temps à interagir avec un logiciel de gestion de source.
   5.398 +    </para>
   5.399 +
   5.400 +    <para id="x_8f">Les outils distribués sont complètement indépendants des
   5.401 +      aléas de votre serveur, d'autant plus qu'ils répliquent les métadonnées
   5.402 +      à beaucoup d'endroits. Si votre serveur central prend feu, vous avez
   5.403 +      intérêt à ce que les médias de sauvegardes soient fiables, et que votre
   5.404 +      dernier <quote>backup</quote> soit récent et fonctionne sans problème.
   5.405 +      Avec un outil distribué, vous avez autant de <quote>backup</quote> que
   5.406 +      de contributeurs.
   5.407 +    </para>
   5.408 +
   5.409 +    <para id="x_90">En outre, la fiabilité de votre réseau affectera beaucoup
   5.410 +      moins les outils distribués. Vous ne pouvez même pas utiliser un outil
   5.411 +      centralisé sans connexion réseau, à l'exception de quelques commandes,
   5.412 +      très limitées. Avec un outil distribué, si votre connexion réseau tombe
   5.413 +      pendant que vous travaillez, vous pouvez ne même pas vous en rendre
   5.414 +      compte. La seule chose que vous ne serez pas capable de faire sera de
   5.415 +      communiquer avec des dépôts distants, opération somme toute assez rare
   5.416 +      en comparaison aux opérations locales. Si vous avez une équipe de
   5.417 +      collaborateurs très dispersée ceci peut être significatif.
   5.418 +    </para>
   5.419  
   5.420      <sect2>
   5.421        <title>Avantages pour les projets Open Source</title>
   5.422  
   5.423 -      <para id="x_91">Si vous prenez goût à un projet <emphasis remap="it">Open Source</emphasis> et que vous
   5.424 -décidez de commencer à toucher à son code, et que le projet utilise
   5.425 -un gestionnaire de source distribué, vous êtes immédiatement un "pair"
   5.426 -avec les personnes formant le <quote>cœur</quote> du projet. Si ils publient
   5.427 -leurs dépôts, vous pouvez immédiatement copier leurs historiques de
   5.428 -projet, faire des modifications, enregistrer votre travail en utilisant
   5.429 -les même outils qu'eux. Par comparaison, avec un outil centralisé, vous
   5.430 -devez utiliser un logiciel en mode <quote>lecture seule</quote> à moins que
   5.431 -quelqu'un ne vous donne les privilèges de <quote>commit</quote> sur le serveur
   5.432 -central. Avant ça, vous ne serez pas capable d'enregistrer vos
   5.433 -modifications, et vos propres modifications risqueront de se
   5.434 -corrompre chaque fois que vous essayerez de mettre à jour à votre
   5.435 -espace de travail avec le serveur central.
   5.436 -</para>
   5.437 -
   5.438 -      <sect3>
   5.439 -	<title>Le non-problème du "fork"</title>
   5.440 -
   5.441 -	<para id="x_92">Il a été souvent suggéré que les gestionnaires de source distribués
   5.442 -posent un risque pour les projets <emphasis remap="it">Open Source</emphasis> car ils
   5.443 -facilitent grandement la création de <quote>fork</quote>.<!-- footnote{NdT:Création
   5.444 -d'une
   5.445 -<ulink url="version alternative du logiciel">version alternative du
   5.446 -logiciel</ulink>{http://fr.wikipedia.org/wiki/Fork#Embranchement_d.27un_projet_informatique}
   5.447 --->
   5.448 -Un <quote>fork</quote> apparait quand il y des divergences d'opinion ou d'attitude
   5.449 -au sein d'un groupe de développeurs qui aboutissent à la décision de ne
   5.450 -plus travailler ensemble. Chaque parti s'empare d'une copie plus ou moins
   5.451 -complète du code source du projet et continue dans sa propre direction.
   5.452 -</para>
   5.453 -
   5.454 -	<para id="x_93">Parfois ces différents partis décident de se réconcilier. Avec un
   5.455 -serveur central, l'aspect <emphasis>technique</emphasis> de cette réconciliation
   5.456 -est un processus douloureux, et essentiellement manuel. Vous devez
   5.457 -décider quelle modification est <quote>la gagnante</quote>, et replacer, par un
   5.458 -moyen ou un autre, les modifications de l'autre équipe dans l'arborescence
   5.459 -du projet. Ceci implique généralement la perte d'une partie de l'historique
   5.460 -d'un des partis, ou même des deux.
   5.461 -</para>
   5.462 -
   5.463 -	<para id="x_94">Ce que les outils distribués permettent à ce sujet est probablement
   5.464 -la <emphasis>meilleure</emphasis> façon de développer un projet. Chaque modification
   5.465 -que vous effectuez est potentiellement un <quote>fork</quote>. La grande force de
   5.466 -cette approche est que les gestionnaires de source distribués doivent être
   5.467 -vraiment très efficaces pour <emphasis>fusionner</emphasis><!-- TODO footnote{NdT:j'ai choisi de
   5.468 -traduire ici <emphasis remap="it">merging</emphasis> par <quote>fusionner</quote> pour des raisons 
   5.469 -de clarté} --> des <quote>forks</quote>, car les <quote>forks</quote>, dans ce contexte, arrivent 
   5.470 -tout le temps.</para>
   5.471 -
   5.472 -	<para id="x_95">Si chaque altération que n'importe qui effectue, à tout moment, est vue
   5.473 -comme un <quote>fork</quote> à fusionner, alors ce que le monde de
   5.474 -l'<emphasis remap="it">Open Source</emphasis>
   5.475 -Source} voit comme un <quote>fork</quote> devient <emphasis>uniquement</emphasis> une problématique
   5.476 -sociale. En fait, les outils de gestions de source distribués <emphasis>réduisent</emphasis>
   5.477 -les chances de <quote>fork</quote>:
   5.478 -</para>
   5.479 -<itemizedlist>
   5.480 -    <listitem>
   5.481 -        <para>Ils éliminent la distinction sociale qu'imposent les outils centralisés
   5.482 -        entre les membres du projets (ceux qui ont accès au <quote>commit</quote>) et ceux de
   5.483 -        l'extérieur (ce qui ne l'ont pas).</para>
   5.484 -        <para>rendent plus facile la réconciliation après un <quote>fork</quote> social, car tout ce 
   5.485 -         qu'elle implique est une simple fusion.</para>
   5.486 -    </listitem>
   5.487 -</itemizedlist>
   5.488 -
   5.489 -	<para id="x_98">Certaines personnes font de la résistance envers les gestionnaires de source
   5.490 -distribués parce qu'ils veulent garder un contrôle ferme sur leur projet, et
   5.491 -ils pensent que les outils centralisés leur fournissent ce contrôle. Néanmoins,
   5.492 -si c'est votre cas, sachez que si vous publiez votre dépôt CVS ou Subversion
   5.493 -de manière publique, il existe une quantité d'outils disponibles pour récupérer
   5.494 -entièrement votre projet et son historique (quoique lentement) et le récréer
   5.495 -ailleurs, sans votre contrôle. En fait, votre contrôle sur votre projet est
   5.496 -illusoire, vous ne faites qu'interdire à vos collaborateurs de travailler
   5.497 -de manière fluide, en disposant d'un miroir ou d'un <quote>fork</quote> de votre
   5.498 -historique.
   5.499 -%%%TODO: Fussy, those last sentences are not really well translated:
   5.500 -%%%no problem for me (wilk)
   5.501 -%However, if you're of this belief, and you publish your CVS or Subversion
   5.502 -%repositories publically, there are plenty of tools available that can pull
   5.503 -%out your entire project's history (albeit slowly) and recreate it somewhere
   5.504 -%that you don't control.  So while your control in this case is illusory, you are
   5.505 -%forgoing the ability to fluidly collaborate with whatever people feel
   5.506 -%compelled to mirror and fork your history.
   5.507 -</para>
   5.508 -
   5.509 -      </sect3>
   5.510 +      <para id="x_91">Si vous prenez goût à un projet <emphasis
   5.511 +          remap="it">Open Source</emphasis> et que vous décidez de commencer
   5.512 +        à toucher à son code, et que le projet utilise un gestionnaire de
   5.513 +        source distribué, vous êtes immédiatement un "pair" avec les
   5.514 +        personnes formant le <quote>cœur</quote> du projet. S'ils publient
   5.515 +        leurs dépôts, vous pouvez immédiatement copier leurs historiques de
   5.516 +        projet, faire des modifications, enregistrer votre travail en
   5.517 +        utilisant les mêmes outils qu'eux. Par comparaison avec un outil
   5.518 +        centralisé, vous devez utiliser un logiciel en mode <quote>lecture
   5.519 +          seule</quote> à moins que quelqu'un ne vous donne les privilèges de
   5.520 +        <quote>commit</quote> sur le serveur central. Avant ça, vous ne serez
   5.521 +        pas capable d'enregistrer vos modifications, et vos propres
   5.522 +        modifications risqueront de se corrompre chaque fois que vous
   5.523 +        essayerez de mettre à jour à votre espace de travail avec le serveur
   5.524 +        central.
   5.525 +      </para>
   5.526 +
   5.527 +    <sect3>
   5.528 +      <title>Le non-problème du "fork"</title>
   5.529 +      
   5.530 +      <para id="x_92">Il a été souvent suggéré que les gestionnaires de
   5.531 +        source distribués posent un risque pour les projets <emphasis
   5.532 +          remap="it">Open Source</emphasis> car ils facilitent grandement la
   5.533 +        création de <quote>fork</quote>.
   5.534 +        <!--footnote{NdT:Création d'une <ulink url="version alternative du
   5.535 +          logiciel">version alternative du
   5.536 +          logiciel</ulink>{http://fr.wikipedia.org/wiki/Fork#Embranchement_d.27un_projet_informatique}
   5.537 +        -->
   5.538 +        Un <quote>fork</quote> apparait quand il y des divergences d'opinion
   5.539 +        ou d'attitude au sein d'un groupe de développeurs qui aboutissent à
   5.540 +        la décision de ne plus travailler ensemble. Chaque parti s'empare
   5.541 +        d'une copie plus ou moins complète du code source du projet et
   5.542 +        continue dans sa propre direction.
   5.543 +      </para>
   5.544 +
   5.545 +
   5.546 +      <para id="x_93">Parfois ces différents partis décident de se
   5.547 +        réconcilier. Avec un serveur central, l'aspect
   5.548 +        <emphasis>technique</emphasis> de cette réconciliation est un
   5.549 +        processus douloureux, et essentiellement manuel. Vous devez décider
   5.550 +        quelle modification est <quote>la gagnante</quote>, et replacer, par
   5.551 +        un moyen ou un autre, les modifications de l'autre équipe dans
   5.552 +        l'arborescence du projet. Ceci implique généralement la perte d'une
   5.553 +        partie de l'historique d'un des partis, ou même des deux.
   5.554 +      </para>
   5.555 +    
   5.556 +      <para id="x_94">Ce que les outils distribués permettent à ce sujet est
   5.557 +        probablement la <emphasis>meilleure</emphasis> façon de développer un
   5.558 +        projet. Chaque modification que vous effectuez est potentiellement un
   5.559 +        <quote>fork</quote>. La grande force de cette approche est que les
   5.560 +        gestionnaires de source distribués doivent être vraiment très
   5.561 +        efficaces pour <emphasis>fusionner (merge)</emphasis>
   5.562 +        <!-- TODO footnote{NdT:j'ai choisi de traduire ici <emphasis
   5.563 +          remap="it">merging</emphasis> par <quote>fusionner</quote> pour des
   5.564 +        raisons de clarté} -->
   5.565 +        des <quote>forks</quote>, car les <quote>forks</quote>, dans ce
   5.566 +        contexte, arrivent tout le temps.
   5.567 +      </para>
   5.568 +      
   5.569 +      <para id="x_95">Si chaque altération que n'importe qui effectue, à tout
   5.570 +        moment, est vue comme un <quote>fork</quote> à fusionner, alors ce
   5.571 +        que le monde de l'<emphasis remap="it">Open Source</emphasis> voit
   5.572 +        comme un <quote>fork</quote> devient <emphasis>uniquement</emphasis>
   5.573 +        une problématique sociale. En fait, les outils de gestions de source
   5.574 +        distribués <emphasis>réduisent</emphasis> les chances de
   5.575 +        <quote>fork</quote> :
   5.576 +      </para>
   5.577 +        
   5.578 +      <itemizedlist>
   5.579 +        <listitem>
   5.580 +        <para>Ils éliminent la distinction sociale qu'imposent les outils
   5.581 +          centralisés entre les membres du projets (ceux qui ont accès au
   5.582 +          <quote>commit</quote>) et ceux de l'extérieur (ce qui ne l'ont
   5.583 +          pas).
   5.584 +        </para>
   5.585 +        <para>Ils rendent plus facile la réconciliation après un
   5.586 +          <quote>fork</quote> social, car tout ce qu'elle implique est une
   5.587 +          simple fusion.
   5.588 +        </para>
   5.589 +        </listitem>
   5.590 +      </itemizedlist>
   5.591 +
   5.592 +      <para id="x_98">Certaines personnes font de la résistance envers les
   5.593 +        gestionnaires de source distribués parce qu'ils veulent garder un
   5.594 +        contrôle ferme sur leur projet, et ils pensent que les outils
   5.595 +        centralisés leur fournissent ce contrôle. Néanmoins, si c'est votre
   5.596 +        cas, sachez que si vous publiez votre dépôt CVS ou Subversion de
   5.597 +        manière publique, il existe une quantité d'outils disponibles pour
   5.598 +        récupérer entièrement votre projet et son historique (quoique
   5.599 +        lentement) et le récréer ailleurs, sans votre contrôle. En fait,
   5.600 +        votre contrôle sur votre projet est illusoire, vous ne faites
   5.601 +        qu'interdire à vos collaborateurs de travailler de manière fluide, en
   5.602 +        disposant d'un miroir ou d'un <quote>fork</quote> de votre
   5.603 +        historique.
   5.604 +      </para>
   5.605 +
   5.606 +    </sect3>
   5.607      </sect2>
   5.608      <sect2>
   5.609        <title>Avantages pour les projets commerciaux</title>
   5.610  
   5.611 -      <para id="x_99">Beaucoup de projets commerciaux sont réalisés par des équipes éparpillées
   5.612 -à travers le globe. Les contributeurs qui sont loin du serveur central
   5.613 -devront subir des commandes lentes et même parfois peu fiables. Les
   5.614 -solutions propriétaires de gestion de source tentent de palier ce problème
   5.615 -avec des réplications de sites distants qui sont à la fois coûteuses à mettre
   5.616 -en place et lourdes à administrer. Un système distribué ne souffre pas
   5.617 -de ce genre de problèmes. En outre, il est très aisé de mettre en place
   5.618 -plusieurs serveurs de références, disons un par site, de manière à ce qu'il
   5.619 -n'y ait pas de communication redondante entre les dépôts, sur une connexion
   5.620 -longue distance souvent onéreuse.
   5.621 -</para>
   5.622 -
   5.623 -      <para id="x_9a">Les systèmes de gestion de source supportent généralement assez mal la
   5.624 -montée en charge. Ce n'est pas rare pour un gestionnaire de source centralisé
   5.625 -pourtant onéreux de s'effondrer sous la charge combinée d'une douzaine
   5.626 -d'utilisateurs concurrents seulement. Une fois encore, la réponse à cette problématique
   5.627 -est généralement encore la mise en place d'un ensemble complexe de serveurs
   5.628 -synchronisés par un mécanisme de réplication. Dans le cas d'un gestionnaire
   5.629 -de source distribué, la charge du serveur central &emdash; si vous avez un&emdash; est
   5.630 -plusieurs fois inférieure (car toutes les données sont déjà répliquées ailleurs),
   5.631 -un simple serveur, pas très cher, peut gérer les besoins d'une plus grande
   5.632 -équipe, et la réplication pour balancer la charge devient le
   5.633 -travail d'un simple script.
   5.634 -</para>
   5.635 -
   5.636 -      <para id="x_9b">Si vous avez des employés sur le terrain, en train de chercher à résoudre un souci sur
   5.637 -le site d'un client, ils bénéficieront aussi d'un gestionnaire de source
   5.638 -distribué. Cet outil leur permettra de générer des versions personnalisées,
   5.639 -d'essayer différentes solutions, en les isolant aisément les unes des autres,
   5.640 -et de rechercher efficacement à travers l'historique des sources, la cause
   5.641 -des bugs ou des régressions, tout ceci sans avoir besoin de la moindre
   5.642 -connexion au réseau de votre compagnie.
   5.643 -</para>
   5.644 +      <para id="x_99">Beaucoup de projets commerciaux sont réalisés par des
   5.645 +        équipes éparpillées à travers le globe. Les contributeurs qui sont
   5.646 +        loin du serveur central devront subir des commandes lentes et même
   5.647 +        parfois peu fiables. Les solutions propriétaires de gestion de source
   5.648 +        tentent de palier ce problème avec des réplications de sites distants
   5.649 +        qui sont à la fois coûteuses à mettre en place et lourdes à
   5.650 +        administrer. Un système distribué ne souffre pas de ce genre de
   5.651 +        problèmes. En outre, il est très aisé de mettre en place plusieurs
   5.652 +        serveurs de références, disons un par site, de manière à ce qu'il n'y
   5.653 +        ait pas de communication redondante entre les dépôts, sur une
   5.654 +        connexion longue distance souvent onéreuse.
   5.655 +      </para>
   5.656 +
   5.657 +      <para id="x_9a">Les systèmes de gestion de source supportent
   5.658 +        généralement assez mal la monté en charge. Il n'est pas rare pour un
   5.659 +        gestionnaire de source centralisé pourtant onéreux de s'effondrer
   5.660 +        sous la charge combinée d'une douzaine d'utilisateurs concurrents
   5.661 +        seulement. Une fois encore, la réponse à cette problématique est
   5.662 +        généralement encore la mise en place d'un ensemble complexe de
   5.663 +        serveurs synchronisés par un mécanisme de réplication. Dans le cas
   5.664 +        d'un gestionnaire de source distribué, la charge du serveur central
   5.665 +        &emdash; si vous avez un&emdash; est plusieurs fois inférieure (car
   5.666 +        toutes les données sont déjà répliquées ailleurs), un simple serveur,
   5.667 +        pas très cher, peut gérer les besoins d'une plus grande équipe, et la
   5.668 +        réplication pour balancer la charge devient le travail d'un simple
   5.669 +        script.
   5.670 +      </para>
   5.671 +
   5.672 +      <para id="x_9b">Si vous avez des employés sur le terrain, en train de
   5.673 +        chercher à résoudre un souci sur le site d'un client, ils
   5.674 +        bénéficieront aussi d'un gestionnaire de source distribué. Cet outil
   5.675 +        leur permettra de générer des versions personnalisées, d'essayer
   5.676 +        différentes solutions, en les isolant aisément les unes des autres,
   5.677 +        et de rechercher efficacement à travers l'historique des sources, la
   5.678 +        cause des bugs ou des régressions, tout ceci sans avoir besoin de la
   5.679 +        moindre connexion au réseau de votre compagnie.
   5.680 +      </para>
   5.681  
   5.682      </sect2>
   5.683 -  </sect1>
   5.684 -  <sect1>
   5.685 -    <title>Pourquoi choisir Mercurial?</title>
   5.686 -
   5.687 -    <para id="x_9c">Mercurial a plusieurs caractéristiques qui en font un choix particulièrement
   5.688 -pertinent pour la gestion de source:
   5.689 -</para>
   5.690 +    </sect1>
   5.691 +    <sect1>
   5.692 +      <title>Pourquoi choisir Mercurial?</title>
   5.693 +
   5.694 +      <para id="x_9c">Mercurial a plusieurs caractéristiques qui en font un
   5.695 +        choix particulièrement pertinent pour la gestion de source :
   5.696 +      </para>
   5.697      <itemizedlist>
   5.698 -      <listitem><para id="x_9d">It is easy to learn and use.</para></listitem>
   5.699 -      <listitem><para id="x_9e">It is lightweight.</para></listitem>
   5.700 -      <listitem><para id="x_9f">It scales excellently.</para></listitem>
   5.701 -      <listitem><para id="x_a0">It is easy to
   5.702 -	  customise.</para></listitem></itemizedlist>
   5.703 -
   5.704 -    <para id="x_a1">Si vous êtes déjà familier d'un outil de gestion de source, vous serez
   5.705 -capable de l'utiliser en moins de 5 minutes. Sinon, ça ne sera pas beaucoup
   5.706 -plus long.
   5.707 -Les commandes utilisées par Mercurial, comme ses fonctionnalités, sont
   5.708 -généralement uniformes et cohérentes, et vous pouvez donc ainsi garder en tête
   5.709 -simplement quelques règles générales, plutôt qu'un lot complexe d'exceptions.
   5.710 -</para>
   5.711 -
   5.712 -    <para id="x_a2">Sur un petit projet, vous pouvez commencer à travailler avec Mercurial en
   5.713 -quelques instants. Ajouter des modifications ou des branches, transférer
   5.714 -ces modifications (localement ou via le réseau), et les opérations
   5.715 -d'historique ou de statut sont aussi très rapides. Mercurial reste hors de
   5.716 -votre chemin grâce à sa simplicité d'utilisation et sa rapidité d'exécution.
   5.717 -</para>
   5.718 -
   5.719 -    <para id="x_a3">L'utilité de Mercurial ne se limite pas à de petits projets: il est
   5.720 -aussi utilisé par des projets ayant des centaines ou même des milliers
   5.721 -de contributeurs, avec plusieurs dizaines de milliers de fichiers, et des
   5.722 -centaines de méga de code source.
   5.723 -</para>
   5.724 -
   5.725 -    <para id="x_a4">Si les fonctionnalités cœur de Mercurial ne sont pas suffisantes pour vous,
   5.726 -il est très aisé d'en construire d'autres. Mercurial est adapté à l'utilisation
   5.727 -de scripts, et son implémentation interne en Python, propre et claire,
   5.728 -rend encore plus facile l'ajout de fonctionnalités sous forme d'extensions. Il
   5.729 -en existe déjà un certain nombre de très populaires et très utiles,
   5.730 -dont le périmètre va de la recherche de bugs à l'amélioration des performances.
   5.731 -</para>
   5.732 +      <listitem><para id="x_9d">Il est simple à apprendre et à utiliser.</para></listitem>
   5.733 +      <listitem><para id="x_9e">Il est léger.</para></listitem>
   5.734 +      <listitem><para id="x_9f">Il s'adapte très bien à la charge.</para></listitem>
   5.735 +      <listitem><para id="x_a0">Il se personnalise facilement.</para></listitem>
   5.736 +    </itemizedlist>
   5.737 +
   5.738 +    <para id="x_a1">Si vous êtes déjà familier d'un outil de gestion de
   5.739 +      source, vous serez capable de l'utiliser en moins de 5 minutes. Sinon,
   5.740 +      ça ne sera pas beaucoup plus long. Les commandes utilisées par
   5.741 +      Mercurial, comme ses fonctionnalités, sont généralement uniformes et
   5.742 +      cohérentes, et vous pouvez ainsi garder en tête simplement quelques
   5.743 +      règles générales, plutôt qu'un lot complexe d'exceptions.
   5.744 +    </para>
   5.745 +
   5.746 +    <para id="x_a2">Sur un petit projet, vous pouvez commencer à travailler
   5.747 +      avec Mercurial en quelques instants. Ajouter des modifications ou des
   5.748 +      branches, transférer ces modifications (localement ou via le réseau),
   5.749 +      et les opérations d'historique ou de statut sont aussi très rapides.
   5.750 +      Mercurial reste hors de votre chemin grâce à sa simplicité
   5.751 +      d'utilisation et sa rapidité d'exécution.
   5.752 +    </para>
   5.753 +
   5.754 +    <para id="x_a3">L'utilité de Mercurial ne se limite pas à de petits
   5.755 +      projets: il est aussi utilisé par des projets ayant des centaines ou
   5.756 +      même des milliers de contributeurs, avec plusieurs dizaines de milliers
   5.757 +      de fichiers, et des centaines de méga octets de code source.
   5.758 +    </para>
   5.759 +
   5.760 +    <para id="x_a4">Si les fonctionnalités au cœur de Mercurial ne sont pas
   5.761 +      suffisantes pour vous, il est très aisé d'en construire d'autres.
   5.762 +      Mercurial est adapté à l'utilisation de scripts, et son implémentation
   5.763 +      interne en Python, propre et claire, rend encore plus facile l'ajout de
   5.764 +      fonctionnalités sous forme d'extensions. Il en existe déjà un certain
   5.765 +      nombre de très populaires et très utiles, dont le périmètre va de la
   5.766 +      recherche de bugs à l'amélioration des performances.
   5.767 +    </para>
   5.768  
   5.769    </sect1>
   5.770    <sect1>
   5.771      <title>Mercurial comparé aux autres outils</title>
   5.772  
   5.773 -    <para id="x_a5">Avant que vous n'alliez plus loin, comprenez bien que cette section
   5.774 -reflète mes propres expériences, et elle est donc (j'ose le dire)
   5.775 -peu objective. Néanmoins, j'ai utilisé les outils de gestion de source
   5.776 -listés ci dessous, dans la plupart des cas, pendant plusieurs années.
   5.777 -%% TODO: Fussy translation.
   5.778 -</para>
   5.779 -
   5.780 +    <para id="x_a5">Avant que vous n'alliez plus loin, comprenez bien que
   5.781 +      cette section reflète mes propres expériences, et elle est donc (j'ose
   5.782 +      le dire) peu objective. Néanmoins, j'ai utilisé les outils de gestion
   5.783 +      de source listés ci dessous, dans la plupart des cas, pendant plusieurs
   5.784 +      années.
   5.785 +    </para>
   5.786  
   5.787      <sect2>
   5.788        <title>Subversion</title>
   5.789  
   5.790 -      <para id="x_a6">Subversion est un des outils de gestion de source les plus populaire, il fût
   5.791 -développé pour remplacer CVS. Il a une architecture client/server centralisée.
   5.792 -</para>
   5.793 -
   5.794 -    <para id="x_a7">Subversion et Mercurial ont des noms de commandes très similaires pour
   5.795 -les mêmes opérations, ainsi si vous êtes familier avec l'un, c'est facile
   5.796 -d'apprendre l'autre. Ces deux outils sont portables sur les systèmes
   5.797 -d'exploitation les plus populaires
   5.798 -</para>
   5.799 -
   5.800 -      <para id="x_a8">Avant la version 1.5, Subversion n'offrait aucune forme de support pour les fusions. Lors
   5.801 -de l'écriture de ce livre, ses capacités de fusion étaient nouvelles, et réputées pour être
   5.802 -<ulink url="http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword">
   5.803 -complexes et boguées</ulink>.
   5.804 -</para>
   5.805 -
   5.806 -      <para id="x_a9">Mercurial dispose d'un avantage substantiel en terme de performance par rapport à
   5.807 -Subversion sur la plupart des opérations que j'ai pu tester. J'ai mesuré
   5.808 -une différence de performance allant de deux à six fois plus rapide avec
   5.809 -le système de stockage de fichier local de Subversion 1.4.3
   5.810 -(<emphasis>ra_local</emphasis>), qui est la méthode d'accès la plus rapide disponible. Dans
   5.811 -un déploiement plus réaliste, impliquant un stockage réseau, Subversion
   5.812 -serait encore plus désavantagé. Parce que la plupart des commandes Subversion
   5.813 -doivent communiquer avec le serveur et que Subversion n'a pas de mécanisme
   5.814 -de réplication, la capacité du serveur et la bande passante sont devenues des
   5.815 -goulots d'étranglement pour les projets de taille moyenne ou grande.
   5.816 -</para>
   5.817 -
   5.818 -      <para id="x_aa">En outre, Subversion implique une surcharge substantielle dans le stockage local
   5.819 -de certaines données, pour éviter des transactions avec le serveur, pour
   5.820 -certaines opérations communes, telles que la recherche des fichiers modifiés
   5.821 -(<literal>status</literal>) et l'affichage des modifications par rapport à la révision
   5.822 -courante (<literal>diff</literal>). En conséquence, un répertoire de travail Subversion
   5.823 -a souvent la même taille, ou est plus grand, qu'un dépôt Mercurial et son
   5.824 -espace de travail, et ceci bien que le dépôt Mercurial contienne l'intégralité
   5.825 -de l'historique.
   5.826 -</para>
   5.827 -
   5.828 -      <para id="x_ab">Subversion est largement supporté par les outils tierces. Mercurial est
   5.829 -actuellement encore en retrait de ce point de vue. L'écart se réduit, néanmoins,
   5.830 -et en effet certains des outils graphiques sont maintenant supérieurs à leurs
   5.831 -équivalents Subversion. Comme Mercurial, Subversion dispose d'un excellent
   5.832 -manuel utilisateur.
   5.833 -</para>
   5.834 -
   5.835 -      <para id="x_ac">Parce que Subversion ne stocke pas l'historique chez ses clients, il est
   5.836 -parfaitement adapté à la gestion de projets qui doivent suivre un ensemble
   5.837 -de larges fichiers binaires et opaques. Si vous suivez une cinquantaine de
   5.838 -versions d'un fichier incompressible de 10MB, l'occupation disque coté client
   5.839 -d'un projet sous Subversion restera à peu près constante. A l'inverse,
   5.840 -l'occupation disque du même projet sous n'importe lequel des gestionnaires
   5.841 -de source distribués grandira rapidement, proportionnellement aux nombres
   5.842 -de versions, car les différences entre chaque révisions seront très grandes.
   5.843 -</para>
   5.844 -
   5.845 -      <para id="x_ad">En outre, c'est souvent difficile ou, généralement, impossible de fusionner
   5.846 -des différences dans un fichier binaire. La capacité de Subversion de
   5.847 -verrouiller des fichiers, pour permettre à l'utilisateur d'être le seul
   5.848 -à le mettre à jour (<quote>commit</quote>) temporairement, est un avantage significatif
   5.849 -dans un projet doté de beaucoup de fichiers binaires.
   5.850 -</para>
   5.851 -
   5.852 -      <para id="x_ae">Mercurial peut importer l'historique depuis un dépôt Subversion. Il peut
   5.853 -aussi exporter l'ensemble des révisions d'un projet vers un dépôt Subversion.
   5.854 -Ceci rend très facile de <quote>prendre la température</quote> et d'utiliser Mercurial et Subversion
   5.855 -en parallèle, avant de décider de migrer vers Mercurial. La conversion de
   5.856 -l'historique est incrémentale, donc vous pouvez effectuer une conversion
   5.857 -initiale, puis de petites additions par la suite pour ajouter les nouvelles
   5.858 -modifications.
   5.859 -</para>
   5.860 +      <para id="x_a6">Subversion est un des outils de gestion de source les
   5.861 +        plus populaire, il fût développé pour remplacer CVS. Il a une
   5.862 +        architecture client/server centralisée.
   5.863 +      </para>
   5.864 +
   5.865 +      <para id="x_a7">Subversion et Mercurial ont des noms de commandes très
   5.866 +        similaires pour les mêmes opérations, ainsi si vous êtes familier
   5.867 +        avec l'un, c'est facile d'apprendre l'autre. Ces deux outils sont
   5.868 +        portables sur les systèmes d'exploitation les plus populaires.
   5.869 +      </para>
   5.870 +
   5.871 +      <para id="x_a8">Avant la version 1.5, Subversion n'offrait aucune forme
   5.872 +        de support pour les fusions. Lors de l'écriture de ce livre, ses
   5.873 +        capacités de fusion étaient nouvelles, et réputées pour être <ulink
   5.874 +          url="http://svnbook.red-bean.com/nightly/en/svn.branchmerge.advanced.html#svn.branchmerge.advanced.finalword">
   5.875 +          complexes et buguées</ulink>.
   5.876 +      </para>
   5.877 +
   5.878 +      <para id="x_a9">Mercurial dispose d'un avantage substantiel en terme de
   5.879 +        performance par rapport à Subversion sur la plupart des opérations
   5.880 +        que j'ai pu tester. J'ai mesuré une différence de performance allant
   5.881 +        de deux à six fois plus rapide avec le système de stockage de fichier
   5.882 +        local de Subversion 1.4.3 (<emphasis>ra_local</emphasis>), qui est la
   5.883 +        méthode d'accès la plus rapide disponible. Dans un déploiement plus
   5.884 +        réaliste, impliquant un stockage réseau, Subversion serait encore
   5.885 +        plus désavantagé. Parce que la plupart des commandes Subversion
   5.886 +        doivent communiquer avec le serveur et que Subversion n'a pas de
   5.887 +        mécanisme de réplication, la capacité du serveur et la bande passante
   5.888 +        sont devenues des goulots d'étranglement pour les projets de taille
   5.889 +        moyenne ou grande.
   5.890 +      </para>
   5.891 +
   5.892 +      <para id="x_aa">En outre, Subversion implique une surcharge
   5.893 +        substantielle dans le stockage local de certaines données, pour
   5.894 +        éviter des transactions avec le serveur, pour certaines opérations
   5.895 +        communes, telles que la recherche des fichiers modifiés
   5.896 +        (<literal>status</literal>) et l'affichage des modifications par
   5.897 +        rapport à la révision courante (<literal>diff</literal>). En
   5.898 +        conséquence, un répertoire de travail Subversion a souvent la même
   5.899 +        taille, ou est plus grand, qu'un dépôt Mercurial et son espace de
   5.900 +        travail, et ceci bien que le dépôt Mercurial contienne l'intégralité
   5.901 +        de l'historique.
   5.902 +      </para>
   5.903 +
   5.904 +      <para id="x_ab">Subversion est largement supporté par les outils
   5.905 +        tierces. Mercurial est actuellement encore en retrait de ce point de
   5.906 +        vue. L'écart se réduit néanmoins, en effet, certains des outils
   5.907 +        graphiques sont maintenant supérieurs à leurs équivalents Subversion.
   5.908 +        Comme Mercurial, Subversion dispose d'un excellent manuel
   5.909 +        utilisateur.
   5.910 +      </para>
   5.911 +
   5.912 +      <para id="x_ac">Parce que Subversion ne stocke pas l'historique chez
   5.913 +        ses clients, il est parfaitement adapté à la gestion de projets qui
   5.914 +        doivent suivre un ensemble de larges fichiers binaires et opaques. Si
   5.915 +        vous suivez une cinquantaine de versions d'un fichier incompressible
   5.916 +        de 10MB, l'occupation disque coté client d'un projet sous Subversion
   5.917 +        restera à peu près constante. A l'inverse, l'occupation disque du
   5.918 +        même projet sous n'importe lequel des gestionnaires de source
   5.919 +        distribués grandira rapidement, proportionnellement aux nombres de
   5.920 +        versions, car les différences entre chaque révisions seront très
   5.921 +        grandes.
   5.922 +      </para>
   5.923 +
   5.924 +      <para id="x_ad">En outre, c'est souvent difficile ou, généralement,
   5.925 +        impossible de fusionner des différences dans un fichier binaire. La
   5.926 +        capacité de Subversion de verrouiller des fichiers, pour permettre à
   5.927 +        l'utilisateur d'être le seul à le mettre à jour
   5.928 +        (<quote>commit</quote>) temporairement, est un avantage significatif
   5.929 +        dans un projet doté de beaucoup de fichiers binaires.
   5.930 +      </para>
   5.931 +
   5.932 +      <para id="x_ae">Mercurial peut importer l'historique depuis un dépôt
   5.933 +        Subversion. Il peut aussi exporter l'ensemble des révisions d'un
   5.934 +        projet vers un dépôt Subversion. Ceci rend très facile de
   5.935 +        <quote>prendre la température</quote> et d'utiliser Mercurial et
   5.936 +        Subversion en parallèle, avant de décider de migrer vers Mercurial.
   5.937 +        La conversion de l'historique est incrémentale, donc vous pouvez
   5.938 +        effectuer une conversion initiale, puis de petites additions par la
   5.939 +        suite pour ajouter les nouvelle modifications.
   5.940 +      </para>
   5.941  
   5.942  
   5.943      </sect2>
   5.944      <sect2>
   5.945        <title>Git</title>
   5.946  
   5.947 -      <para id="x_af">Git est un outil de gestion de source distribué qui fût développé pour gérer
   5.948 -le code source de noyau de Linux. Comme Mercurial, sa conception initiale a
   5.949 -été inspirée par Monotone.
   5.950 -</para>
   5.951 -
   5.952 -      <para id="x_b0">Git dispose d'un ensemble conséquent de commandes, avec plus de 139 commandes
   5.953 -individuelles pour la version 1.5.0. Il a aussi la réputation d'être difficile
   5.954 -à apprendre. Comparé à Git, le point fort de Mercurial est clairement sa
   5.955 -simplicité.
   5.956 -</para>
   5.957 -
   5.958 -      <para id="x_b1">En terme de performance, Git est extrêmement rapide. Dans la plupart des
   5.959 -cas, il est plus rapide que Mercurial, tout du moins sur Linux, alors que
   5.960 -Mercurial peut être plus performant sur d'autres opérations. Néanmoins, sur
   5.961 -Windows, les performances et le niveau de support général fourni par Git,
   5.962 -au moment de l'écriture de cet ouvrage, est bien derrière celui de Mercurial.
   5.963 -</para>
   5.964 -
   5.965 -      <para id="x_b2">Alors que le dépôt Mercurial ne demande aucune maintenance, un dépôt Git
   5.966 -exige d'exécuter manuellement et régulièrement la commande <quote>repacks</quote> sur
   5.967 -ces métadonnées. Sans ceci, les performances de git se dégradent et la
   5.968 -consommation de l'espace disque augmente rapidement. Un serveur qui contient
   5.969 -plusieurs dépôts Git qui ne sont pas régulièrement et fréquemment <quote>repacked</quote>
   5.970 -deviendra un vrai problème lors des <quote>backups</quote> du disque, et il y eu des
   5.971 -cas, où un <quote>backup</quote> journalier pouvait durer plus de 24 heures. Un dépôt
   5.972 -fraichement <quote>repacked</quote> sera légèrement plus petit qu'un dépôt Mercurial,
   5.973 -mais un dépôt non <quote>repacked</quote> est beaucoup plus grand.
   5.974 -</para>
   5.975 -
   5.976 -      <para id="x_b3">Le cœur de Git est écrit en C. La plupart des commandes Git sont implémentées
   5.977 -sous forme de scripts Shell ou Perl, et la qualité de ces scripts varie
   5.978 -grandement. J'ai plusieurs fois constaté que certains de ces scripts étaient
   5.979 -chargés en mémoire aveuglément et que la présence d'erreurs pouvait s'avérer
   5.980 -fatal.
   5.981 -</para>
   5.982 -
   5.983 -      <para id="x_b4">Mercurial peut importer l'historique d'un dépôt Git.
   5.984 -</para>
   5.985 -
   5.986 -
   5.987 +      <para id="x_af">Git est un outil de gestion de source distribué qui fût
   5.988 +        développé pour gérer le code source de noyau de Linux. Comme
   5.989 +        Mercurial, sa conception initiale a été inspirée par Monotone.
   5.990 +      </para>
   5.991 +
   5.992 +      <para id="x_b0">Git dispose d'un ensemble conséquent de commandes, avec
   5.993 +        plus de 139 commandes individuelles pour la version 1.5.0. Il a aussi
   5.994 +        la réputation d'être difficile à apprendre. Comparé à Git, le point
   5.995 +        fort de Mercurial est clairement sa simplicité.
   5.996 +      </para>
   5.997 +
   5.998 +      <para id="x_b1">En terme de performance, Git est extrêmement rapide.
   5.999 +        Dans la plupart des cas, il est plus rapide que Mercurial, tout du
  5.1000 +        moins sur Linux, alors que Mercurial peut être plus performant sur
  5.1001 +        d'autres opérations. Néanmoins, sur Windows, les performances et le
  5.1002 +        niveau de support général fourni par Git, au moment de l'écriture de
  5.1003 +        cet ouvrage, est bien derrière celui de Mercurial.
  5.1004 +      </para>
  5.1005 +
  5.1006 +      <para id="x_b2">Alors que le dépôt Mercurial ne demande aucune
  5.1007 +        maintenance, un dépôt Git exige d'exécuter manuellement et
  5.1008 +        régulièrement la commande <quote>repacks</quote> sur ses métadonnées.
  5.1009 +        Sans ceci, les performances de git se dégradent et la consommation de
  5.1010 +        l'espace disque augmente rapidement. Un serveur qui contient
  5.1011 +        plusieurs dépôts Git qui ne sont pas régulièrement et fréquemment
  5.1012 +        <quote>repacked</quote> deviendra un vrai problème lors des
  5.1013 +        <quote>backups</quote> du disque, et il y eu des cas, où un
  5.1014 +        <quote>backup</quote> journalier pouvait durer plus de 24 heures. Un
  5.1015 +        dépôt fraichement <quote>repacked</quote> sera légèrement plus petit
  5.1016 +        qu'un dépôt Mercurial, mais un dépôt non <quote>repacked</quote> est
  5.1017 +        beaucoup plus grand.
  5.1018 +      </para>
  5.1019 +
  5.1020 +      <para id="x_b3">Le cœur de Git est écrit en C. La plupart des commandes
  5.1021 +        Git sont implémentées sous forme de scripts Shell ou Perl, et la
  5.1022 +        qualité de ces scripts varie grandement. J'ai plusieurs fois constaté
  5.1023 +        que certains de ces scripts étaient chargés en mémoire aveuglément et
  5.1024 +        que la présence d'erreurs pouvait s'avérer fatal.
  5.1025 +      </para>
  5.1026 +
  5.1027 +      <para id="x_b4">Mercurial peut importer l'historique d'un dépôt Git.</para>
  5.1028  
  5.1029      </sect2>
  5.1030      <sect2>
  5.1031        <title>CVS</title>
  5.1032  
  5.1033 -      <para id="x_b5">CVS est probablement l'outil de gestion de source le plus utilisé aujourd'hui
  5.1034 -dans le monde. À cause de son manque de clarté interne, il n'est plus
  5.1035 -maintenu depuis plusieurs années.
  5.1036 -</para>
  5.1037 -
  5.1038 -      <para id="x_b6">Il a une architecture client/serveur centralisée. Il ne regroupe pas les
  5.1039 -modifications de fichiers dans une opération de <quote>commit</quote> atomique, ce
  5.1040 -qui permet à ses utilisateurs de <quote>casser le <emphasis>build</emphasis></quote> assez
  5.1041 -facilement : une personne peut effectuer une opération de <quote>commit</quote>
  5.1042 -sans problème puis être bloquée par besoin de fusion, avec comme conséquence
  5.1043 -néfaste, que les autres utilisateurs ne récupèreront qu'une partie de ses
  5.1044 -modifications. Ce problème affecte aussi la manière de travailler avec
  5.1045 -l'historique du projet. Si vous voulez voir toutes les modifications d'une
  5.1046 -personne du projet, vous devrez injecter manuellement les descriptions et les
  5.1047 -<emphasis remap="it">timestamps</emphasis> des modifications de chacun des fichiers impliqués (si
  5.1048 -vous savez au moins quels sont ces fichiers).
  5.1049 -</para>
  5.1050 +      <para id="x_b5">CVS est probablement l'outil de gestion de source le
  5.1051 +        plus utilisé aujourd'hui dans le monde. À cause de son manque de
  5.1052 +        clarté interne, il n'est plus maintenu depuis plusieurs années.
  5.1053 +      </para>
  5.1054 +
  5.1055 +      <para id="x_b6">Il a une architecture client/serveur centralisée. Il ne
  5.1056 +        regroupe pas les modifications de fichiers dans une opération de
  5.1057 +        <quote>commit</quote> atomique, ce qui permet à ses utilisateurs de
  5.1058 +        <quote>casser le <emphasis>build</emphasis></quote> assez facilement
  5.1059 +        : une personne peut effectuer une opération de <quote>commit</quote>
  5.1060 +        sans problème puis être bloquée par besoin de fusion, avec comme
  5.1061 +        conséquence néfaste, que les autres utilisateurs ne récupèreront
  5.1062 +        qu'une partie de ses modifications. Ce problème affecte aussi la
  5.1063 +        manière de travailler avec l'historique du projet. Si vous voulez
  5.1064 +        voir toutes les modifications d'une personne du projet, vous devrez
  5.1065 +        injecter manuellement les descriptions et les <emphasis
  5.1066 +          remap="it">timestamps</emphasis> des modifications de chacun des
  5.1067 +        fichiers impliqués (si vous savez au moins quels sont ces fichiers).
  5.1068 +      </para>
  5.1069  
  5.1070        <para id="x_b7">CVS a une notion étrange des <emphasis
  5.1071 -      remap="it">tags</emphasis> et des branches que je n'essayerai
  5.1072 -même pas de décrire ici. Il ne supporte pas bien les opérations de renommage d'un
  5.1073 -fichier ou d'un répertoire, ce qui facilite la corruption de son dépôt. Il n'a
  5.1074 -presque pas pour ainsi dire de contrôle de cohérence interne, il est donc
  5.1075 -pratiquement impossible de dire si un dépôt est corrompu ni à quel point. Je
  5.1076 -ne recommanderai pas CVS pour un projet existant ou nouveau.
  5.1077 -</para>
  5.1078 -
  5.1079 -      <para id="x_b8">Mercurial peut importer l'historique d'un projet CVS. Néanmoins, il y a
  5.1080 -quelques principes à respecter; ce qui est vrai aussi pour les autres
  5.1081 -outils d'import de projet CVS. À cause de l'absence de <quote>commit</quote> atomique
  5.1082 -et gestion de version de l'arborescence, il n'est pas possible de reconstruire
  5.1083 -de manière précise l'ensemble de l'historique. Un travail de <quote>devinette</quote>
  5.1084 -est donc nécessaire, et les fichiers renommés ne sont pas détectés. Parce
  5.1085 -qu'une bonne part de l'administration d'un dépôt CVS est effectuée manuellement,
  5.1086 -et est donc, sujette à erreur, il est courant que les imports CVS rencontrent
  5.1087 -de nombreux problèmes avec les dépôt corrompus (des <emphasis
  5.1088 -remap="it">timestamps</emphasis> de révision complètement buggés et des fichiers 
  5.1089 -verrouillés depuis des années sont deux des problèmes les moins intéressants dont 
  5.1090 -je me souvienne).
  5.1091 -</para>
  5.1092 +          remap="it">tags</emphasis> et des branches que je n'essayerai même
  5.1093 +        pas de décrire ici. Il ne supporte pas bien les opérations de
  5.1094 +        renommage d'un fichier ou d'un répertoire, ce qui facilite la
  5.1095 +        corruption de son dépôt. Il n'a presque pas pour ainsi dire de
  5.1096 +        contrôle de cohérence interne, il est donc pratiquement impossible de
  5.1097 +        dire si un dépôt est corrompu ni à quel point. Je ne recommanderai
  5.1098 +        pas CVS pour un projet existant ou nouveau.
  5.1099 +      </para>
  5.1100 +
  5.1101 +      <para id="x_b8">Mercurial peut importer l'historique d'un projet CVS.
  5.1102 +        Néanmoins, il y a quelques principes à respecter; ce qui est vrai
  5.1103 +        aussi pour les autres outils d'import de projet CVS. À cause de
  5.1104 +        l'absence de <quote>commit</quote> atomique et gestion de version de
  5.1105 +        l'arborescence, il n'est pas possible de reconstruire de manière
  5.1106 +        précise l'ensemble de l'historique. Un travail de
  5.1107 +        <quote>devinette</quote> est donc nécessaire, et les fichiers
  5.1108 +        renommés ne sont pas détectés. Parce qu'une bonne part de
  5.1109 +        l'administration d'un dépôt CVS est effectuée manuellement, et est
  5.1110 +        donc, sujette à erreur, il est courant que les imports CVS
  5.1111 +        rencontrent de nombreux problèmes avec les dépôt corrompus (des
  5.1112 +        <emphasis remap="it">timestamps</emphasis> de révision complètement
  5.1113 +        buggés et des fichiers verrouillés depuis des années sont deux des
  5.1114 +        problèmes les moins intéressants dont je me souvienne).
  5.1115 +      </para>
  5.1116  
  5.1117        <para id="x_b9">Mercurial peut importer l'historique depuis un dépôt CVS.
  5.1118 -</para>
  5.1119 +      </para>
  5.1120  
  5.1121  
  5.1122      </sect2>
  5.1123      <sect2>
  5.1124        <title>Outils propriétaires</title>
  5.1125  
  5.1126 -      <para id="x_ba">Perforce a une architecture client/serveur centralisée, sans aucun
  5.1127 -mécanisme de mise en cache de données coté client. Contrairement à la plupart
  5.1128 -des outils modernes de gestion de source, Perforce exige de ses
  5.1129 -utilisateurs d'exécuter une commande pour informer le serveur
  5.1130 -central de tout fichier qu'ils souhaitent modifier.
  5.1131 -</para>
  5.1132 -
  5.1133 -      <para id="x_bb">Les performances de Perforce sont plutôt bonnes pour des petites
  5.1134 -équipes, mais elles s'effondrent rapidement lorsque le nombre
  5.1135 -d'utilisateurs augmente au delà de la douzaine. Des installations
  5.1136 -de Perforce assez larges nécessitent le déploiement de proxies pour
  5.1137 -supporter la montée en charge associée.
  5.1138 -</para>
  5.1139 -
  5.1140 +      <para id="x_ba">Perforce a une architecture client/serveur centralisée,
  5.1141 +        sans aucun mécanisme de mise en cache de données coté client.
  5.1142 +        Contrairement à la plupart des outils modernes de gestion de source,
  5.1143 +        Perforce exige de ses utilisateurs d'exécuter une commande pour
  5.1144 +        informer le serveur central de tout fichier qu'ils souhaitent
  5.1145 +        modifier.
  5.1146 +      </para>
  5.1147 +
  5.1148 +      <para id="x_bb">Les performances de Perforce sont plutôt bonnes pour
  5.1149 +        des petites équipes, mais elles s'effondrent rapidement lorsque le
  5.1150 +        nombre d'utilisateurs augmente au delà de la douzaine. Des
  5.1151 +        installations de Perforce assez larges nécessitent le déploiement de
  5.1152 +        proxies pour supporter la montée en charge associée.
  5.1153 +      </para>
  5.1154  
  5.1155      </sect2>
  5.1156      <sect2>
  5.1157        <title>Choisir un outil de gestion de source</title>
  5.1158  
  5.1159 -      <para id="x_bc">A l'exception de CVS, tous les outils listés ci-dessus ont des
  5.1160 -forces qui leur sont propres et qui correspondent à certaines
  5.1161 -formes de projet. Il n'y a pas un seul meilleur outil de gestion
  5.1162 -de source qui correspondrait le mieux à toutes les situations.
  5.1163 -</para>
  5.1164 -
  5.1165 -      <para id="x_bd">En guise exemple, Subversion est un très bon choix lorsqu'on travaille
  5.1166 -avec beaucoup de fichiers binaires, qui évoluent régulièrement, grâce
  5.1167 -à sa nature centralisée et sa capacité à verrouiller des fichiers.
  5.1168 -</para>
  5.1169 -
  5.1170 -      <para id="x_be">Personnellement, je préfère Mercurial pour sa simplicité, ses
  5.1171 -performances et sa bonne capacité de fusion, et il m'a très bien rendu service
  5.1172 -de plusieurs années maintenant.
  5.1173 -</para>
  5.1174 -
  5.1175 +      <para id="x_bc">A l'exception de CVS, tous les outils listés ci-dessus
  5.1176 +        ont des forces qui leur sont propres et qui correspondent à certaines
  5.1177 +        formes de projet. Il n'y a pas un seul meilleur outil de gestion de
  5.1178 +        source qui correspondrait le mieux à toutes les situations.
  5.1179 +      </para>
  5.1180 +
  5.1181 +      <para id="x_bd">En guise exemple, Subversion est un très bon choix
  5.1182 +        lorsqu'on travaille avec beaucoup de fichiers binaires, qui évoluent
  5.1183 +        régulièrement, grâce à sa nature centralisée et sa capacité à
  5.1184 +        verrouiller des fichiers.
  5.1185 +      </para>
  5.1186 +
  5.1187 +      <para id="x_be">Personnellement, je préfère Mercurial pour sa
  5.1188 +        simplicité, ses performances et sa bonne capacité de fusion, et il
  5.1189 +        m'a très bien rendu service de plusieurs années maintenant.
  5.1190 +      </para>
  5.1191  
  5.1192      </sect2>
  5.1193    </sect1>
  5.1194    <sect1>
  5.1195      <title>Migrer depuis un outil à Mercurial</title>
  5.1196  
  5.1197 -    <para id="x_bf">Mercurial est livré avec une extension nommée <literal role="hg-ext">convert</literal>, qui
  5.1198 -peut de manière incrémentale importer des révisions depuis différents
  5.1199 -autres outils de gestion de source. Par <quote>incrémental</quote>, j'entends que
  5.1200 -vous pouvez convertir l'historique entier du projet en une seule fois,
  5.1201 -puis relancer l'outil d'import plus tard pour obtenir les modifications
  5.1202 -effectuées depuis votre import initial.
  5.1203 -</para>
  5.1204 -
  5.1205 -    <para id="x_c0">Les outils de gestion de source supportés par <literal role="hg-ext">convert</literal> sont :
  5.1206 -</para>
  5.1207 +    <para id="x_bf">Mercurial est livré avec une extension nommée <literal
  5.1208 +        role="hg-ext">convert</literal>, qui peut, de manière incrémentale
  5.1209 +      importer des révisions depuis différents autres outils de gestion de
  5.1210 +      source. Par <quote>incrémental</quote>, j'entends que vous pouvez
  5.1211 +      convertir l'historique entier du projet en une seule fois, puis
  5.1212 +      relancer l'outil d'import plus tard pour obtenir les modifications
  5.1213 +      effectuées depuis votre import initial.
  5.1214 +    </para>
  5.1215 +
  5.1216 +    <para id="x_c0">Les outils de gestion de source supportés par <literal
  5.1217 +        role="hg-ext">convert</literal> sont :
  5.1218 +    </para>
  5.1219      <itemizedlist>
  5.1220        <listitem><para id="x_c1">Subversion</para></listitem>
  5.1221        <listitem><para id="x_c2">CVS</para></listitem>
  5.1222        <listitem><para id="x_c3">Git</para></listitem>
  5.1223 -      <listitem><para id="x_c4">Darcs</para></listitem></itemizedlist>
  5.1224 -
  5.1225 -    <para id="x_c5">En outre, <literal role="hg-ext">convert</literal> peut exporter les modifications depuis Mercurial
  5.1226 -vers Subversion. Ceci rend possible d'essayer Subversion en parallèle
  5.1227 -avant de choisir une solution définitive, sans aucun risque de perte de
  5.1228 -données.
  5.1229 -</para>
  5.1230 -
  5.1231 -    <para id="x_c6">La commande <command role="hg-ext-conver">convert</command> est très simple à utiliser. Simplement,
  5.1232 -indiquez le chemin ou l'URL du dépôt de source, en lui indiquant éventuellement
  5.1233 -le nom du chemin de destination, et la conversion se met en route. Après cet
  5.1234 -import initial, il suffit de relancer la commande encore une fois pour
  5.1235 -importer les modifications effectuées depuis.
  5.1236 -</para>
  5.1237 +      <listitem><para id="x_c4">Darcs</para></listitem>
  5.1238 +    </itemizedlist>
  5.1239 +
  5.1240 +    <para id="x_c5">En outre, <literal role="hg-ext">convert</literal> peut
  5.1241 +      exporter les modifications depuis Mercurial vers Subversion. Ceci rend
  5.1242 +      possible d'essayer Subversion en parallèle avant de choisir une
  5.1243 +      solution définitive, sans aucun risque de perte de données.
  5.1244 +    </para>
  5.1245 +
  5.1246 +    <para id="x_c6">La commande <command
  5.1247 +        role="hg-ext-conver">convert</command> est très simple à utiliser.
  5.1248 +      Simplement, indiquez le chemin ou l'URL du dépôt de source, en lui
  5.1249 +      indiquant éventuellement le nom du chemin de destination, et la
  5.1250 +      conversion se met en route. Après cet import initial, il suffit de
  5.1251 +      relancer la commande encore une fois pour importer les modifications
  5.1252 +      effectuées depuis.
  5.1253 +    </para>
  5.1254    </sect1>
  5.1255  
  5.1256    <sect1>
  5.1257      <title>Une courte histoire de la gestion de source</title>
  5.1258  
  5.1259      <para id="x_c7">Le plus célèbre des anciens outils de gestion de source
  5.1260 -    est <emphasis remap="it">SCCS</emphasis>
  5.1261 -(Source Code Control System)}, que Marc Rochkind conçu dans les laboratoires de
  5.1262 -recherche de Bell (<emphasis remap="it">Bell Labs</emphasis>), dans le début des années 70.
  5.1263 -<emphasis remap="it">SCCS</emphasis> ne fonctionnait que sur des fichiers individuels, et obligeait chaque
  5.1264 -personne travaillant sur le projet d'avoir un accès à un répertoire de
  5.1265 -travail commun, sur le même système. Seulement une seule personne pouvait
  5.1266 -modifier un fichier au même moment, ce fonctionnement était assuré par
  5.1267 -l'utilisation de verrou (<quote>lock</quote>). Il était courant que des personnes
  5.1268 -verrouillent des fichiers, et plus tard, oublient de le déverrouiller;
  5.1269 -empêchant n'importe qui d'autre de travailler sur ces fichiers sans l'aide de
  5.1270 -l'administrateur...
  5.1271 -</para>
  5.1272 +      est <emphasis remap="it">SCCS</emphasis> (Source Code Control System)},
  5.1273 +      que Marc Rochkind conçu dans les laboratoires de recherche de Bell
  5.1274 +      (<emphasis remap="it">Bell Labs</emphasis>), dans le début des années
  5.1275 +      70. <emphasis remap="it">SCCS</emphasis> ne fonctionnait que sur des
  5.1276 +      fichiers individuels, et obligeait chaque personne travaillant sur le
  5.1277 +      projet d'avoir un accès à un répertoire de travail commun, sur le même
  5.1278 +      système. Seulement une seule personne pouvait modifier un fichier au
  5.1279 +      même moment, ce fonctionnement était assuré par l'utilisation de verrou
  5.1280 +      (<quote>lock</quote>). Il était courant que des personnes verrouillent
  5.1281 +      des fichiers, et plus tard, oublient de le déverrouiller ; empêchant
  5.1282 +      n'importe qui d'autre de travailler sur ces fichiers sans l'aide de
  5.1283 +      l'administrateur...
  5.1284 +    </para>
  5.1285  
  5.1286      <para id="x_c8">Walter Tichy a développé une alternative libre à
  5.1287 -    <emphasis remap="it">SCCS</emphasis> au début des
  5.1288 -années 80, qu'il nomma <emphasis remap="it">RCS (Revision Control System)</emphasis>.  Comme
  5.1289 -<emphasis remap="it">SCCS</emphasis>, <emphasis remap="it">RCS</emphasis> demandait aux développeurs de travailler sur le même
  5.1290 -répertoire partagé, et de verrouiller les
  5.1291 -fichiers pour se prémunir de tout conflit issu de modifications concurrentes.
  5.1292 -</para>
  5.1293 -
  5.1294 -    <para id="x_c9">Un peu plus tard dans les années 1980, Dick Grune utilisa <emphasis remap="it">RCS</emphasis> comme
  5.1295 -une brique de base pour un ensemble de scripts <emphasis
  5.1296 -remap="it">shell</emphasis> qu'il intitula
  5.1297 -cmt, avant de la renommer en <emphasis remap="it">CVS (Concurrent Versions System)</emphasis>.  La
  5.1298 -grande innovation de CVS était que les développeurs pouvaient travailler
  5.1299 -simultanément et indépendamment dans leur propre espace de travail. Ces espaces
  5.1300 -de travail privés assuraient que les développeurs ne se marchent pas
  5.1301 -mutuellement sur les pieds, comme c'était souvent le cas avec RCS et SCCS.
  5.1302 -Chaque développeur disposait donc de sa copie de tous les fichiers du projet,
  5.1303 -et ils pouvaient donc librement les modifier. Ils devaient néanmoins effectuer
  5.1304 -la <quote>fusion</quote> (<emphasis
  5.1305 -remap="it"><quote>merge</quote></emphasis>) de leurs fichiers, avant d'effectuer le
  5.1306 -<quote>commit</quote> de leur modifications sur le dépôt central.
  5.1307 -</para>
  5.1308 -
  5.1309 -<para>Brian Berliner reprit les scripts de Grune's et les réécrit en C, qu'il publia
  5.1310 -en 1989. Depuis, ce code a été modifié jusqu'à devenir la version moderne de
  5.1311 -CVS. CVS a acquis ainsi la capacité de fonctionner en réseau, transformant son
  5.1312 -architecture en client/serveur. L'architecture de CVS est centralisée, seul le
  5.1313 -serveur a une copie de l'historique du projet. L'espace de travail client ne
  5.1314 -contient qu'une copie de la dernière version du projet, et quelques métadonnées
  5.1315 -pour indiquer où le serveur se trouve. CVS a été un grand succès, aujourd'hui
  5.1316 -il est probablement l'outil de gestion de contrôle le plus utilisé au monde.
  5.1317 -</para>
  5.1318 -
  5.1319 -<para>Au début des années 1990, Sun Microsystmes développa un premier outil de
  5.1320 -gestion de source distribué, nommé TeamWare. Un espace de travail TeamWare
  5.1321 -contient une copie complète de l'historique du projet. TeamWare n'a pas de
  5.1322 -notion de dépôt central. (CVS utilisait RCS pour le stockage de l'historique,
  5.1323 -TeamWare utilisait SCCS).
  5.1324 -</para>
  5.1325 -
  5.1326 -<para>Alors que les années 1990 avançaient, les utilisateurs ont pris conscience d'un
  5.1327 -certain nombre de problèmes avec CVS. Il enregistrait simultanément des
  5.1328 -modifications sur différents fichiers individuellement, au lieu de les
  5.1329 -regrouper dans une seule opération cohérente et atomique. Il ne gère pas bien
  5.1330 -sa hiérarchie de fichier, il est donc assez aisé de créer le chaos en renommant
  5.1331 -les fichiers et les répertoires. Pire encore, son code source est difficile à
  5.1332 -lire et à maintenir, ce qui agrandit largement le <quote>niveau de souffrance</quote>
  5.1333 -associé à la réparation de ces problèmes d'architecture de manière prohibitive.
  5.1334 -</para>
  5.1335 -
  5.1336 -<para>En 2001, Jim Blandy et Karl Fogel, deux développeurs qui avaient travaillé sur
  5.1337 -CVS, initièrent un projet pour le remplacer par un outil qui aurait une
  5.1338 -meilleure architecture et un code plus propre. Le résultat, Subversion, ne
  5.1339 -quitte pas le modèle centralisé et client/server de CVS, mais ajoute les
  5.1340 -opérations de <quote>commit</quote> atomique sur de multiples fichiers, une meilleure
  5.1341 -gestion des espaces de noms, et d'autres fonctionnalités qui en font un
  5.1342 -meilleur outil que CVS. Depuis sa première publication, il est rapidement
  5.1343 -devenu très populaire.
  5.1344 -</para>
  5.1345 -
  5.1346 -<para>Plus ou moins simultanément, Graydon Hoare a commencé sur l'ambitieux
  5.1347 -système de gestion distribué Monotone. Bien que Monotone corrige plusieurs
  5.1348 -défauts de CVS's tout en offrant une architecture <quote>peer-to-peer</quote>, il va aussi
  5.1349 -plus loin que la plupart des outils de révision de manière assez innovante. Il
  5.1350 -utilise des <quote>hash</quote> cryptographiques comme identifiants, et il a une notion
  5.1351 -complète de <quote>confiance</quote> du code issu des différentes sources.
  5.1352 -</para>
  5.1353 -
  5.1354 -<para>Mercurial est né en 2005. Bien que très influencé par Monotone, Mercurial se
  5.1355 -concentre sur la facilité d'utilisation, les performances et la capacité à
  5.1356 -monter en charge pour de très gros projets.
  5.1357 -</para>
  5.1358 -
  5.1359 -</sect1>
  5.1360 -
  5.1361 -
  5.1362 +      <emphasis remap="it">SCCS</emphasis> au début des années 80, qu'il
  5.1363 +      nomma <emphasis remap="it">RCS (Revision Control System)</emphasis>.
  5.1364 +      Comme <emphasis remap="it">SCCS</emphasis>, <emphasis
  5.1365 +        remap="it">RCS</emphasis> demandait aux développeurs de travailler
  5.1366 +      sur le même répertoire partagé, et de verrouiller les fichiers pour se
  5.1367 +      prémunir de tout conflit issu de modifications concurrentes.
  5.1368 +    </para>
  5.1369 +
  5.1370 +    <para id="x_c9">Un peu plus tard dans les années 1980, Dick Grune utilisa
  5.1371 +      <emphasis remap="it">RCS</emphasis> comme une brique de base pour un
  5.1372 +      ensemble de scripts <emphasis remap="it">shell</emphasis> qu'il
  5.1373 +      intitula cmt, avant de la renommer en <emphasis remap="it">CVS
  5.1374 +        (Concurrent Versions System)</emphasis>.  La grande innovation de CVS
  5.1375 +      était que les développeurs pouvaient travailler simultanément et
  5.1376 +      indépendamment dans leur propre espace de travail. Ces espaces de
  5.1377 +      travail privés assuraient que les développeurs ne se marchent pas
  5.1378 +      mutuellement sur les pieds, comme c'était souvent le cas avec RCS et
  5.1379 +      SCCS. Tous les développeurs disposaient donc de leur copie de tous les
  5.1380 +      fichiers du projet, et ils pouvaient donc librement les modifier. Ils
  5.1381 +      devaient néanmoins effectuer la <quote>fusion</quote> (<emphasis
  5.1382 +        remap="it"><quote>merge</quote></emphasis>) de leurs fichiers, avant
  5.1383 +      d'effectuer le <quote>commit</quote> de leurs modifications sur le dépôt
  5.1384 +      central.
  5.1385 +    </para>
  5.1386 +    
  5.1387 +    <para>Brian Berliner reprit les scripts de Grune's et les réécrit en C,
  5.1388 +      qu'il publia en 1989. Depuis, ce code a été modifié jusqu'à devenir la
  5.1389 +      version moderne de CVS. CVS a acquis ainsi la capacité de fonctionner
  5.1390 +      en réseau, transformant son architecture en client/serveur.
  5.1391 +      L'architecture de CVS est centralisée, seul le serveur a une copie de
  5.1392 +      l'historique du projet. L'espace de travail client ne contient qu'une
  5.1393 +      copie de la dernière version du projet, et quelques métadonnées pour
  5.1394 +      indiquer où le serveur se trouve. CVS a été un grand succès,
  5.1395 +      aujourd'hui il est probablement l'outil de gestion de contrôle le plus
  5.1396 +      utilisé au monde.
  5.1397 +    </para>
  5.1398 +    
  5.1399 +    <para>Au début des années 1990, Sun Microsystems développa un premier
  5.1400 +      outil de gestion de source distribué, nommé TeamWare. Un espace de
  5.1401 +      travail TeamWare contient une copie complète de l'historique du projet.
  5.1402 +      TeamWare n'a pas de notion de dépôt central. (CVS utilisait RCS pour le
  5.1403 +      stockage de l'historique, TeamWare utilisait SCCS).
  5.1404 +    </para>
  5.1405 +    
  5.1406 +    <para>Alors que les années 1990 avançaient, les utilisateurs ont pris
  5.1407 +      conscience d'un certain nombre de problèmes avec CVS. Il enregistrait
  5.1408 +      simultanément des modifications sur différents fichiers
  5.1409 +      individuellement, au lieu de les regrouper dans une seule opération
  5.1410 +      cohérente et atomique. Il ne gère pas bien sa hiérarchie de fichier, il
  5.1411 +      est donc assez aisé de créer le chaos en renommant les fichiers et les
  5.1412 +      répertoires. Pire encore, son code source est difficile à lire et à
  5.1413 +      maintenir, ce qui agrandit largement le <quote>niveau de
  5.1414 +        souffrance</quote> associé à la réparation de ces problèmes
  5.1415 +      d'architecture de manière prohibitive.
  5.1416 +    </para>
  5.1417 +    
  5.1418 +    <para>En 2001, Jim Blandy et Karl Fogel, deux développeurs qui avaient
  5.1419 +      travaillé sur CVS, initièrent un projet pour le remplacer par un outil
  5.1420 +      qui aurait une meilleure architecture et un code plus propre. Le
  5.1421 +      résultat, Subversion, ne quitte pas le modèle centralisé et
  5.1422 +      client/server de CVS, mais ajoute les opérations de
  5.1423 +      <quote>commit</quote> atomique sur de multiples fichiers, une meilleure
  5.1424 +      gestion des espaces de noms, et d'autres fonctionnalités qui en font un
  5.1425 +      meilleur outil que CVS. Depuis sa première publication, il est
  5.1426 +      rapidement devenu très populaire.
  5.1427 +    </para>
  5.1428 +    
  5.1429 +    <para>Plus ou moins simultanément, Graydon Hoare a commencé sur
  5.1430 +      l'ambitieux système de gestion distribué Monotone. Bien que Monotone
  5.1431 +      corrige plusieurs défauts de CVS tout en offrant une architecture
  5.1432 +      <quote>peer-to-peer</quote>, il va aussi plus loin que la plupart des
  5.1433 +      outils de révision de manière assez innovante. Il utilise des
  5.1434 +      <quote>hashs</quote> cryptographiques comme identifiants, et il a une
  5.1435 +      notion complète de <quote>confiance</quote> du code issu des
  5.1436 +      différentes sources.
  5.1437 +    </para>
  5.1438 +    
  5.1439 +    <para>Mercurial est né en 2005. Bien que très influencé par Monotone,
  5.1440 +      Mercurial se concentre sur la facilité d'utilisation, les performances
  5.1441 +      et la capacité à monter en charge pour de très gros projets.
  5.1442 +    </para>
  5.1443 +  
  5.1444 +  </sect1>
  5.1445  
  5.1446  </chapter>
  5.1447  

     6.1 --- a/fr/ch02-tour-basic.xml	Sat Sep 12 17:58:26 2009 +0200
     6.2 +++ b/fr/ch02-tour-basic.xml	Sat Sep 12 17:58:56 2009 +0200
     6.3 @@ -7,92 +7,94 @@
     6.4    <sect1>
     6.5      <title>Installer Mercurial sur votre système</title>
     6.6  
     6.7 -    <para id="x_1">Des paquetages binaires de Mercurial sont disponibles pour la plupart
     6.8 -des systèmes d'exploitation, ce qui rend facile l'utilisation immédiate
     6.9 -de Mercurial sur votre ordinateur.</para>
    6.10 +    <para id="x_1">Des paquetages binaires de Mercurial sont disponibles pour la
    6.11 +      plupart des systèmes d'exploitation, ce qui rend facile l'utilisation
    6.12 +      immédiate de Mercurial sur votre ordinateur.</para>
    6.13  
    6.14      <sect2>
    6.15        <title>Windows</title>
    6.16  
    6.17        <para id="x_c">La meilleur version de Mercurial pour Windows est
    6.18 -      TortoiseHg, qui peut être téléchargée ici : <ulink
    6.19 -      url="http://bitbucket.org/tortoisehg/stable/wiki/Home">http://bitbucket.org/tortoisehg/stable/wiki/Home</ulink>
    6.20 -      Ce logiciel n'a aucune dépendance exterieure; il fonctionne
    6.21 -      <quote>et c'est tout</quote>. Il fournit aussi bien les outils en ligne
    6.22 -      de commmande qu'un interface graphique.</para>
    6.23 - 
    6.24 -  <sect2>
    6.25 -
    6.26 -  <sect2>
    6.27 -    <title>Mac OS X</title>
    6.28 -
    6.29 -    <para id="x_a">Lee Cantey publie un installeur de Mercurial pour Mac OS X
    6.30 -    sur <ulink
    6.31 -    url="http://mercurial.berkwood.com">http://mercurial.berkwood.com</ulink>.</para>
    6.32 -  </sect2>
    6.33 -
    6.34 -  <sect2>
    6.35 -    <title>Linux</title>
    6.36 -
    6.37 -        <para id="x_2">Parce que chaque distribution de Linux a ses propres outils de gestion
    6.38 -          de paquets, politiques et rythmes de développements, il est difficile de
    6.39 -          donner un ensemble d'instructions uniques pour installer les binaires de
    6.40 -          Mercurial. La version de Mercurial avec laquelle vous vous retrouverez
    6.41 -          dépendra grandement de l'activité de la personne en charge du paquetage
    6.42 -          pour la distribution.</para>
    6.43 -
    6.44 -        <para id="x_3">Pour rester simple, je me concentrerai sur l'installation de Mercurial
    6.45 -          en ligne de commande, sous les distributions les plus courantes. La
    6.46 -          plupart des distributions fournissent des gestionnaires graphiques de
    6.47 -          paquetage qui vous permettront d'installer Mercurial en quelques clicks.
    6.48 -          Le paquetage devrait se nommer <literal>mercurial</literal>.</para>
    6.49 -
    6.50 -        <itemizedlist>
    6.51 -          <listitem><para id="x_4">Ubuntu et Debian:</para>
    6.52 -            <programlisting>apt-get install mercurial</listitem>
    6.53 -          <listitem><para id="x_5">Fedora:</para>
    6.54 -            <programlisting>yum install mercurial</programlisting>
    6.55 -          <listitem><para id="x_6">Gentoo:</para>
    6.56 -             <programlisting>emerge mercurial</programlisting></listitem>
    6.57 -          <listitem><para id="x_715">OpenSUSE:</para>
    6.58 -            <programlisting>zypper install mercurial</programlisting>
    6.59 -        </itemizedlist>
    6.60 -
    6.61 -      </sect2>
    6.62 -      <sect2>
    6.63 -        <title>Solaris</title>
    6.64 -
    6.65 -        <para id="x_09">SunFreeWare, à <ulink 
    6.66 -        url="http://www.sunfreeware.com">http://www.sunfreeware.com</ulink>,
    6.67 -        fournit des paquet précompilés pour Mercurial.</para>
    6.68 -     </sect2>
    6.69 -  <sect1>
    6.70 +        TortoiseHg, qui peut être téléchargée ici : <ulink
    6.71 +          url="http://bitbucket.org/tortoisehg/stable/wiki/Home">http://bitbucket.org/tortoisehg/stable/wiki/Home</ulink>.
    6.72 +        Ce logiciel n'a aucune dépendance exterieure; il fonctionne <quote>et
    6.73 +          c'est tout</quote>. Il fournit aussi bien les outils en ligne de
    6.74 +        commmande qu'une interface graphique.</para>
    6.75 + 
    6.76 +    </sect2>
    6.77 +
    6.78 +    <sect2>
    6.79 +      <title>Mac OS X</title>
    6.80 +  
    6.81 +      <para id="x_a">Lee Cantey publie un installeur de Mercurial pour Mac OS
    6.82 +        X sur <ulink
    6.83 +          url="http://mercurial.berkwood.com">http://mercurial.berkwood.com</ulink>.</para>
    6.84 +    </sect2>
    6.85 +      
    6.86 +    <sect2>
    6.87 +      <title>Linux</title>
    6.88 +
    6.89 +      <para id="x_2">Parce que chaque distribution de Linux a ses propres
    6.90 +        outils de gestion de paquets, politiques et rythmes de
    6.91 +        développements, il est difficile de donner un ensemble
    6.92 +        d'instructions unique pour installer les binaires de Mercurial. La
    6.93 +        version de Mercurial avec laquelle vous vous retrouverez dépendra
    6.94 +        grandement de l'activité de la personne en charge du paquetage pour
    6.95 +        la distribution.</para>
    6.96 +
    6.97 +      <para id="x_3">Pour rester simple, je me concentrerai sur
    6.98 +        l'installation de Mercurial en ligne de commande, sous les
    6.99 +        distributions les plus courantes. La plupart des distributions
   6.100 +        fournissent des gestionnaires graphiques de paquetage qui vous
   6.101 +        permettront d'installer Mercurial en quelques clicks. Le paquetage
   6.102 +        devrait se nommer <literal>mercurial</literal>.</para>
   6.103 +
   6.104 +      <itemizedlist>
   6.105 +        <listitem><para id="x_4">Ubuntu et Debian:</para>
   6.106 +          <programlisting>apt-get install mercurial</listitem>
   6.107 +        <listitem><para id="x_5">Fedora:</para>
   6.108 +          <programlisting>yum install mercurial</programlisting>
   6.109 +        <listitem><para id="x_6">Gentoo:</para>
   6.110 +           <programlisting>emerge mercurial</programlisting></listitem>
   6.111 +        <listitem><para id="x_715">OpenSUSE:</para>
   6.112 +          <programlisting>zypper install mercurial</programlisting>
   6.113 +      </itemizedlist>
   6.114 +
   6.115 +    </sect2>
   6.116 +    <sect2>
   6.117 +      <title>Solaris</title>
   6.118 +
   6.119 +      <para id="x_09">SunFreeWare, à <ulink 
   6.120 +      url="http://www.sunfreeware.com">http://www.sunfreeware.com</ulink>,
   6.121 +      fournit des paquets précompilés pour Mercurial.</para>
   6.122 +    </sect2>
   6.123 +  </sect1>
   6.124  
   6.125    <sect1>
   6.126      <title>Commencer à utiliser Mercurial</title>
   6.127  
   6.128 -      <para id="x_e">Pour commencer, nous utiliserons la commande <command role="hg-cmd">hg 
   6.129 -      version</command> pour vérifier si Mercurial est installé proprement. Les 
   6.130 -      informations affichées sur la version ne sont pas réellement importantes en 
   6.131 -      soit, c'est surtout de savoir si elles s'affichent qui nous
   6.132 -      intéresse.</para>
   6.133 -
   6.134 -  &interaction.tour.version;
   6.135 -
   6.136 -  <sect2>
   6.137 -    <title>L'aide intégrée</title>
   6.138 -
   6.139 -    <para id="x_e">Mercurial fournit un système d'aide intégré, ce qui est 
   6.140 -        inestimable quand vous vous retrouvez coincé à essayer de vous rappeler 
   6.141 -        comment lancer une commande. Si vous êtes bloqué, exécutez simplement 
   6.142 -        <command role="hg-cmd">hg help</command>; elle affichera une brève
   6.143 -        liste des commandes, avec une description pour chacune. Si vous demandez 
   6.144 -        de l'aide sur une commande spécifique (voir ci-dessous), elle affichera
   6.145 -        des informations plus détaillées.</para>
   6.146 -
   6.147 -        &interaction.tour.help;
   6.148 -
   6.149 -        <para id="x_10">Pour un niveau d'informations encore plus détaillées 
   6.150 +    <para id="x_e">Pour commencer, nous utiliserons la commande <command
   6.151 +        role="hg-cmd">hg version</command> pour vérifier si Mercurial est
   6.152 +      installé proprement. Les informations affichées sur la version ne sont
   6.153 +      pas réellement importantes en soit, c'est surtout de savoir si elles
   6.154 +      s'affichent qui nous intéresse.</para>
   6.155 +
   6.156 +    &interaction.tour.version;
   6.157 +
   6.158 +    <sect2>
   6.159 +      <title>L'aide intégrée</title>
   6.160 +
   6.161 +      <para id="x_e">Mercurial fournit un système d'aide intégré, ce qui est
   6.162 +        inestimable quand vous vous retrouvez coincé à essayer de vous
   6.163 +        rappeler comment lancer une commande. Si vous êtes bloqué, exécutez
   6.164 +        simplement <command role="hg-cmd">hg help</command>; elle affichera
   6.165 +        une brève liste des commandes, avec une description pour chacune. Si
   6.166 +        vous demandez de l'aide sur une commande spécifique (voir
   6.167 +        ci-dessous), elle affichera des informations plus détaillées.</para>
   6.168 +
   6.169 +      &interaction.tour.help;
   6.170 +
   6.171 +      <para id="x_10">Pour un niveau d'informations encore plus détaillé 
   6.172          (ce dont vous aurez rarement besoin), exécuter <command role="hg-cmd">hg 
   6.173          help <option role="hg-opt-global">-v</option></command>.  L'option 
   6.174          <option role="hg-opt-global">-v</option> est l'abréviation de 
   6.175 @@ -110,7 +112,7 @@
   6.176  
   6.177      <para id="x_12">Il n'y a rien de particulièrement magique au sujet de 
   6.178        ce dépôt, c'est simplement une arborescence sur votre système de fichiers 
   6.179 -      de Mercurial traite de manière spéciale. Vous pouvez renommer ou effacer 
   6.180 +      que Mercurial traite de manière spéciale. Vous pouvez renommer ou effacer 
   6.181        ce répertoire à n'impporte quel moment, en utilisant la ligne de commande 
   6.182        ou votre explorateur de fichiers.</para>
   6.183  
   6.184 @@ -123,32 +125,34 @@
   6.185          Mercurial. Cette commande est appelée <command role="hg-cmd">hg clone</command>, 
   6.186          car elle crée une copie identique à un dépôt existant.</para>
   6.187  
   6.188 -     &interaction.tour.clone;
   6.189 -
   6.190 -     <para id="x_67c">Un avantage de la commande <command
   6.191 -     role="hg-cmd">hg clone</command> est que, comme nous l'avons vu ci
   6.192 -     dessus, elle nous permet de faire de cloner les dépôts à travers le 
   6.193 -     réseau. Un autre est qu'elle se rappelle d'où a été cloné un dépôt, ce
   6.194 -     qui est utile quand on veut mettre à jour le clone.</para>
   6.195 -
   6.196 -     <para id="x_14">Si votre opération de clonage réussit, vous devriez maintenant
   6.197 +      &interaction.tour.clone;
   6.198 +
   6.199 +      <para id="x_67c">Un avantage de la commande <command role="hg-cmd">hg
   6.200 +          clone</command> est que, comme nous l'avons vu ci dessus, elle nous
   6.201 +        permet de faire de cloner les dépôts à travers le réseau. Un autre
   6.202 +        est qu'elle se rappelle d'où a été cloné un dépôt, ce qui est utile
   6.203 +        quand on veut mettre à jour le clone.</para>
   6.204 +
   6.205 +      <para id="x_14">Si votre opération de clonage réussit, vous devriez maintenant
   6.206          avoir un répertoire local appelé <filename class="directory">hello</filename>. 
   6.207          Ce répertoire contiendra quelques fichiers.</para>
   6.208  
   6.209 -     &interaction.tour.ls;
   6.210 -
   6.211 -     <para id="x_15">Ces fichiers ont le même contenu et historique dans votre dépôt
   6.212 -       qu'ils ont dans le dépôt que vous avez cloné.</para>
   6.213 -
   6.214 -     <para id="x_16">Chaque dépôt Mercurial est complet, autonome et indépendant. Il
   6.215 -       contient sa propre copie privée des fichiers du projet et de leur
   6.216 -       historique. Le clone d'un dépôt se souvient de la localisation du
   6.217 -       dépôt à partir duquel il a été clôné, mais il ne communique pas avec
   6.218 -       ce dernier, ou un autre, à moins que vous ne lui demandiez.</para>
   6.219 -
   6.220 -     <para id="x_17">Ce que tout ceci signifie pour le moment est que nous sommes libres
   6.221 -       d'expérimenter avec ce dépôt, confiants dans le fait qu'il s'agit d'un
   6.222 -       <quote>bac à sable</quote> qui n'affectera personne d'autre.</para>
   6.223 +      &interaction.tour.ls;
   6.224 +
   6.225 +      <para id="x_15">Ces fichiers ont le même contenu et historique dans votre dépôt
   6.226 +        qu'ils ont dans le dépôt que vous avez cloné.</para>
   6.227 +
   6.228 +      <para id="x_16">Chaque dépôt Mercurial est complet, autonome et
   6.229 +        indépendant. Il contient sa propre copie privée des fichiers du
   6.230 +        projet et de leur historique. Le clone d'un dépôt se souvient de la
   6.231 +        localisation du dépôt à partir duquel il a été clôné, mais il ne
   6.232 +        communique pas avec ce dernier, ou un autre, à moins que vous ne lui
   6.233 +        demandiez.</para>
   6.234 +
   6.235 +      <para id="x_17">Ce que tout ceci signifie pour le moment est que nous
   6.236 +        sommes libres d'expérimenter avec ce dépôt, confiants dans le fait
   6.237 +        qu'il s'agit d'un <quote>bac à sable</quote> qui n'affectera personne
   6.238 +        d'autre.</para>
   6.239  
   6.240      </sect2>  
   6.241      <sect2>
   6.242 @@ -159,7 +163,7 @@
   6.243          </filename>. C'est ici que Mercurial conserve toutes ses
   6.244          métadonnées.</para>
   6.245  
   6.246 -       &interaction.tour.ls-a; 
   6.247 +      &interaction.tour.ls-a; 
   6.248  
   6.249        <para id="x_19">Le contenu du répertoire <filename class="directory">.hg
   6.250          </filename> et ses sous répertoires sont les seuls propres à Mercurial. 
   6.251 @@ -186,7 +190,7 @@
   6.252        La commande <command role="hg-cmd">hg log</command> vous donne une 
   6.253        vue de l'historique.</para>
   6.254  
   6.255 -    &interaction.tour.log; -->
   6.256 +    &interaction.tour.log;
   6.257  
   6.258      <para "x_1c">Par défaut, cette commande affiche à l'écran un bref paragraphe pour chaque
   6.259        révision enregistrée pour ce projet. Dans la terminologie de Mercurial, nous
   6.260 @@ -194,36 +198,38 @@
   6.261        qu'il contient un ensemble de modifications sur plusieurs fichiers.</para>
   6.262  
   6.263      <para id="x_1d">La commande <command role="hg-cmd">hg log</command> affiche 
   6.264 -    ainsi ces informations:</para>
   6.265 +    ainsi ces informations :</para>
   6.266  
   6.267      <itemizedlist>
   6.268 -      <listitem><para id="x_1e"><literal>changeset</literal>: Ce champ contient 
   6.269 +      <listitem><para id="x_1e"><literal>changeset</literal> : Ce champ contient 
   6.270          un nombre, séparé par deux points (:), d'une chaine hexadécimale. Il 
   6.271          s'agit en fait d'<emphasis>identifiants</emphasis>  d'un changeset. Il y a 
   6.272          deux identifiants car le numéro de la révision est plus court et plus à 
   6.273          facile à saisir qu'une séquence hexadécimale.</para>
   6.274        </listitem>
   6.275 -      <listitem><para id="x_1f"><literal>user</literal>: L'identité de la personne 
   6.276 +      <listitem><para id="x_1f"><literal>user</literal> : L'identité de la personne 
   6.277          qui a créée ce  %%% laisser le terme anglais car il sera affiché
   6.278          changeset. C'est un champ libre de forme, mais la plupart du
   6.279          temps il contient le nom et l'email de la personne.</para>
   6.280        </listitem>
   6.281 -      <listitem><para id="x_20"><literal>date</literal>: La date et l'heure à 
   6.282 -        laquelle le \textit{changeset a été créé, ainsi que le fuseau horaire dans 
   6.283 -        laquelle il a été créé. <!--TODO: Translate 'timezone' properly : FUSEA -->. (La 
   6.284 -        date et l'heure sont locales à ce \textit{fuseau}, elles indiquent donc quelle 
   6.285 -        date et heure il était pour la personne qui a créé ce <!--%%%TODO: je suppose (quelle 
   6.286 -        "heure")  OUI --> changeset.</para>
   6.287 +      <listitem><para id="x_20"><literal>date</literal> : La date et l'heure à 
   6.288 +        laquelle le \textit{changeset} a été créé, ainsi que le fuseau horaire dans 
   6.289 +        lequelle il a été créé. (La date et l'heure sont locales à ce
   6.290 +        \textit{fuseau}, elles indiquent donc quelle date et heure il était
   6.291 +        pour la personne qui a créé ce changeset.</para>
   6.292        </listitem>
   6.293 -      <listitem><para id="x_21"><literal>résumé</literal>: La première du 
   6.294 +      <listitem><para id="x_21"><literal>résumé</literal>: La première ligne du 
   6.295          message que le créateur a associé à son changeset pour le décrire.</para>
   6.296        </listitem>
   6.297 -      <!-- TODO: Missing items here ! -->
   6.298 +      <listitem><para id="x_67d">Certains changesets, comme le premier de la
   6.299 +        liste ci-dessus ont un champ <literal>tag</literal>. Le tag est une autre
   6.300 +        façon d'identifier un changeset en lui donnant un nom simple à retenir.
   6.301 +        (Le tag nommé <literal>tip</literal> est spécial : il fait toujours
   6.302 +        référence aux derniers changements dans le dépôt.)</para></listitem>
   6.303      </itemizedlist>
   6.304  
   6.305      <para id="x_22">Par défaut, la commande <command role="hg-cmd">hg log</command> 
   6.306 -      n'affiche qu'un résumé, il manque
   6.307 -      beaucoup de détails.</para>
   6.308 +      n'affiche qu'un résumé, il manque beaucoup de détails.</para>
   6.309  
   6.310      <para id="x_23">La figure <xref linkend="fig:tour-basic:history"/> fournit une 
   6.311        représentation graphique de l'historique du dépôt <filename class="directory">hello
   6.312 @@ -245,23 +251,22 @@
   6.313      <sect2>
   6.314        <title>Changesets, révisions, et collaboration</title>
   6.315        
   6.316 -      <para id="x_25">Comme l'anglais est réputé pour être un langage maladroit, et que l'informatique
   6.317 -        est la source de bien des erreurs de terminologies (pourquoi utiliser un
   6.318 -        seul terme quand quatre feront l'affaire ?), la gestion de version a une
   6.319 -        variété de mots et de phrases qui veulent dire la même chose. Si vous
   6.320 -        discutez d'historique de Mercurial avec d'autres personnes,
   6.321 -<!--%%%TODO: ça ne veut rien dire: il faut supprimer une des personnes : soit "quelqu'un",
   6.322 -% soit "à d'autres personnes" -->
   6.323 -        vous constaterez que souvent le mot <quote>changeset</quote> est contracté simplement
   6.324 -        en <quote>change</quote> ou (à l'écrit) <quote>cset</quote>, et même parfois un
   6.325 -        changeset simplement <quote>révision</quote>, abrégé en <quote>rev</quote>.</para>
   6.326 +      <para id="x_25">Comme l'anglais est réputé pour être un langage maladroit,
   6.327 +        et que l'informatique est la source de bien des erreurs de terminologie
   6.328 +        (pourquoi utiliser un seul terme quand quatre feront l'affaire ?), la
   6.329 +        gestion de version a une variété de mots et de phrases qui veulent dire
   6.330 +        la même chose. Si vous discutez d'historique de Mercurial avec d'autres
   6.331 +        personnes, vous constaterez que souvent, le mot <quote>changeset</quote>
   6.332 +        est contracté simplement en <quote>change</quote> ou (à l'écrit)
   6.333 +        <quote>cset</quote>, et même parfois un changeset
   6.334 +        <quote>révision</quote>, abrégé en <quote>rev</quote>.</para>
   6.335  
   6.336        <para id="x_26">Bien que le <emphasis>mot</emphasis> que vous utilisez pour 
   6.337          désigner le concept de changeset importe peu, l'<emphasis>identifiant</emphasis> 
   6.338          que vous utilisez pour désigner un <emphasis>changeset</emphasis> spécifique 
   6.339          a une grande importance. Rappelez vous que le champ changeset affiché par la
   6.340 -        commande <command role="hg-cmd">hg log</command> identifie un changeset à la fois avec
   6.341 -        un numéro de révision et une séquence hexadécimale.</para>
   6.342 +        commande <command role="hg-cmd">hg log</command> identifie un changeset à
   6.343 +        la fois avec un numéro de révision et une séquence hexadécimale.</para>
   6.344  
   6.345        <itemizedlist>
   6.346          <listitem><para id="x_27">Le numéro de révision est <emphasis>seulement 
   6.347 @@ -271,22 +276,21 @@
   6.348          pourra toujours être associé au changeset exact de <emphasis>chaque</emphasis> 
   6.349          copie de votre dépôt.</para></listitem></itemizedlist>
   6.350  
   6.351 -     <para id="x_29">La distinction est importante. Si vous envoyez un email 
   6.352 -       à quelqu'un en parlant de la <quote>révision 33</quote>, il est très 
   6.353 -       probable que sa révision 33 <emphasis>ne sera pas la même</emphasis> 
   6.354 -       que la votre. La raison de ceci est que le numéro de révision dépend 
   6.355 -       de l'ordre dans lequel les modifications sont arrivées dans le dépôt, 
   6.356 -       et il n'y a aucune garantie que les mêmes changements soient arrivés 
   6.357 -       dans le même ordre dans différents dépôts. Trois modifications
   6.358 -       <literal>a,b,c</literal> peuvent aisément apparaitre dans un dépôt 
   6.359 -       comme <literal>0,1,2</literal>, et dans un autre comme <literal>0,2,1
   6.360 -       </literal>.</para>
   6.361 -
   6.362 -    <para id="x_2a">Mercurial utilise les numéros de révision uniquement comme des raccourcis
   6.363 -      pratiques. Si vous devez discuter d'un \textit{changeset} avec quelqu'un,
   6.364 -      ou identifer un \textit{changeset} pour une quelquonque %%%TODO: our : "pour" ou "ou"
   6.365 -      raison (par exemple, un rapport de \textit{bug}), utilisez la séquence
   6.366 -      hexadécimale.</para>
   6.367 +      <para id="x_29">La distinction est importante. Si vous envoyez un email 
   6.368 +         à quelqu'un en parlant de la <quote>révision 33</quote>, il est très 
   6.369 +         probable que sa révision 33 <emphasis>ne sera pas la même</emphasis> 
   6.370 +         que la votre. La raison de ceci est que le numéro de révision dépend 
   6.371 +         de l'ordre dans lequel les modifications sont arrivées dans le dépôt, 
   6.372 +         et il n'y a aucune garantie que les mêmes changements soient arrivés 
   6.373 +         dans le même ordre dans différents dépôts. Trois modifications
   6.374 +         <literal>a,b,c</literal> peuvent aisément apparaitre dans un dépôt 
   6.375 +         comme <literal>0,1,2</literal>, et dans un autre comme <literal>0,2,1
   6.376 +         </literal>.</para>
   6.377 +
   6.378 +      <para id="x_2a">Mercurial utilise les numéros de révision uniquement comme des raccourcis
   6.379 +        pratiques. Si vous devez discuter d'un \textit{changeset} avec quelqu'un,
   6.380 +        ou identifer un \textit{changeset} pour une quelconque raison (par exemple,
   6.381 +        un rapport de \textit{bug}), utilisez la séquence hexadécimale.</para>
   6.382  
   6.383      </sect2>
   6.384      <sect2>
   6.385 @@ -300,19 +304,17 @@
   6.386  
   6.387        &interaction.tour.log-r;
   6.388  
   6.389 -      <para id="x_2c">Si vous voulez voir l'historique de plusieurs 
   6.390 -      révisions sans avoir à les énumérer, vous pouvez utiliser la 
   6.391 -      <emphasis>intervalle de numérotation</emphasis> qui vous permet 
   6.392 -      d'exprimer l'idée <quote>je veux toutes les révisions entre $a$ 
   6.393 -      et $b$, inclus</quote>.
   6.394 -
   6.395 -     &interaction.tour.log.range;
   6.396 -
   6.397 -     <para id="x_2d">Mercurial respecte aussi l'ordre dans lequel 
   6.398 -     vous spécifiez les révisions, ainsi 
   6.399 -     <command role="hg-cmd">hg log -r 2:4</command> affichera
   6.400 -     <literal>2,3,4</literal> alors que <command role="hg-cmd">hg log -r 4:2</command> 
   6.401 -     affichera <literal>4,3,2</literal>.</para>
   6.402 +      <para id="x_2c">Si vous voulez voir l'historique de plusieurs révisions
   6.403 +        sans avoir à les énumérer, vous pouvez utiliser la <emphasis>intervalle
   6.404 +        de numérotation</emphasis> qui vous permet d'exprimer l'idée <quote>je
   6.405 +        veux toutes les révisions entre $a$ et $b$, inclus</quote></para>
   6.406 +
   6.407 +      &interaction.tour.log.range;
   6.408 +
   6.409 +      <para id="x_2d">Mercurial respecte aussi l'ordre dans lequel vous spécifiez
   6.410 +        les révisions, ainsi <command role="hg-cmd">hg log -r 2:4</command>
   6.411 +        affichera <literal>2,3,4</literal> alors que <command role="hg-cmd">hg
   6.412 +        log -r 4:2</command> affichera <literal>4,3,2</literal>.</para>
   6.413  
   6.414      </sect2>  
   6.415      <sect2>
   6.416 @@ -322,15 +324,12 @@
   6.417          est suffisant si vous savez déjà ce que vous cherchez. En 
   6.418          revanche, vous aurez probablement besoin de voir une description 
   6.419          complète du changement, ou une liste des fichiers modifiés si vous 
   6.420 -        cherchez à déterminer qu'un changeset est bien celui que vous <!--
   6.421 -     %%%TODO: les propositions sont mal construites : après un "si...." il
   6.422 -     faut une proposition sans "si... donc ici : "si ... recherchez", ben
   6.423 -      quoi?  -->
   6.424 +        cherchez à déterminer qu'un changeset est bien celui que vous
   6.425          recherchez. L'option \hgopt{-v} de la commande <command role="hg-cmd">hg 
   6.426          log</command> (ou <option role="hp-opt-global">--verbose</option>) vous 
   6.427          donne ces informations supplémentaires.</para>
   6.428  
   6.429 -      &interaction.tour.log-v; -->
   6.430 +      &interaction.tour.log-v;
   6.431  
   6.432        <para id="x_2f">Si vous voulez voir à la fois la description 
   6.433          et le contenu d'une modification, ajouter l'option <option 
   6.434 @@ -344,9 +343,8 @@
   6.435  
   6.436        &interaction.tour.log-vp;
   6.437  
   6.438 -      <para id="x_67e">L'option <option role="hg-opt-log">-p</option> option
   6.439 -       est incroyablement utile, il est donc important dans s'en 
   6.440 -       rappeller.</para>
   6.441 +      <para id="x_67e">L'option <option role="hg-opt-log">-p</option> est
   6.442 +        incroyablement utile, il est donc important dans s'en rappeller.</para>
   6.443  
   6.444      </sect2>
   6.445    </sect1>
   6.446 @@ -359,9 +357,8 @@
   6.447        utile pour la suite de notre parcours.</para>
   6.448  
   6.449      <para id="x_31">Mercurial utilise une approche directe et cohérente 
   6.450 -      pour interpréter <!--%%%TODO: une manière d'approche ?--> les 
   6.451 -      options que vous passez aux commandes. Il suit une convention commune 
   6.452 -      à la plupart des systèmes Unix et Linux modernes.</para>
   6.453 +      pour interpréter les options que vous passez aux commandes. Il suit une
   6.454 +      convention commune à la plupart des systèmes Unix et Linux modernes.</para>
   6.455  
   6.456      <itemizedlist>
   6.457        <listitem><para id="x_32">Chaque option a un nom complet. Par exemple, 
   6.458 @@ -401,13 +398,12 @@
   6.459      <note>
   6.460        <title>Option naming consistency</title>
   6.461        
   6.462 -      <para id="x_680">Presque toujours, les commandes de Mercurial utilise
   6.463 +      <para id="x_680">Presque toujours, les commandes de Mercurial utilisent
   6.464        des noms d'options cohérentes pour référer à des concepts identiques.
   6.465        Par exemple, si une commande concerne les changesets, vous les
   6.466 -      identifierais toujours avec l'option <option
   6.467 -      role="hg-opt-log">-r</option>. Cette utilisation cohérente des noms
   6.468 -      d'options permet de mémoriser plus facilement quelles options accepte
   6.469 -      une commande.</para>
   6.470 +      identifierez toujours avec l'option <option role="hg-opt-log">-r</option>.
   6.471 +      Cette utilisation cohérente des noms d'options permet de mémoriser plus
   6.472 +      facilement quelles options accepte une commande.</para>
   6.473     </note>
   6.474  
   6.475  
   6.476 @@ -419,226 +415,229 @@
   6.477        commandes pour consulter l'historique de Mercurial, regardons 
   6.478        comment faire des modifications et les examiner.</para>
   6.479       
   6.480 -   <para id="x_39">La première chose que nous allons faire 
   6.481 -     c'est isoler notre expérience dans un dépôt à part. Nous 
   6.482 -     allons utiliser la commande <command role="hg-cmd">hg 
   6.483 -     clone</command>, mais nous n'avons pas besoin de faire une 
   6.484 -     copie de dépôt distant. Comme nous avons déjà une copie locale, 
   6.485 -     nous pouvons juste faire un clone de celle-ci à la place. C'est 
   6.486 -     beaucoup plus rapide que de faire une copie à travers le réseau, 
   6.487 -     et un dépôt cloné localement prend également moins d'espace 
   6.488 -     disque.<footnote></footnote>
   6.489 -       <para id="x_681">L'économie d'espace disque apparait clairement
   6.490 -       quand les dépôts source et destination sont sur le même système
   6.491 -       de fichier, où dans ce cas, Mercurial utilisera des liens physiques
   6.492 -       pour effectuer des partages copie-lors-des-écritures de ses 
   6.493 -       métadonnées internes. Si cette explication ne signifie rien pour
   6.494 -       vous, ne vous inquietez pas: tout ceci se passe de manière
   6.495 -       transparente et automatiquement, et vous n'avez pas du tout
   6.496 -       besoin de comprendre ceci.</para>
   6.497 -       </footnote>.</para>
   6.498 -   
   6.499 -   &interaction.tour.reclone;
   6.500 -
   6.501 -   <para id="x_3a">On notera au passage qu'il est souvent considéré 
   6.502 -     comme une bonne pratique de conserver une copie <quote>immaculée</quote> 
   6.503 -     du dépôt distant, à partir de laquelle vous pourrez faire des 
   6.504 -     copies locales temporaires pour créer des <quote>bacs à sable</quote> 
   6.505 -     pour chaque tâche sur laquelle vous souhaitez travailler. Ceci 
   6.506 -     vous permet de travailler sur plusieurs choses en parallèle, 
   6.507 -     chacune isolée les unes des autres en attendant que ces tâches 
   6.508 -     soient finies et que vous soyez prêt à les réintégrer. Parce 
   6.509 -     que les copies locales sont peu coûteuses, il est très rapide 
   6.510 -     de créer ou détruire des dépôts dès que vous en avez besoin.
   6.511 -   </para>
   6.512 -
   6.513 -   <para id="x_3b">Dans notre <filename class="directory">my-hello
   6.514 -     </filename> dépôts, nous avons un fichier <filename>hello.c
   6.515 -     </filename> qui contient le classique <quote>hello, world</quote>.
   6.516 -   </para>
   6.517 -   
   6.518 -   &interaction.tour.cat1;
   6.519 -
   6.520 -   <para id="x_682">Editons ce fichier pour qu'il affiche une autre
   6.521 -   ligne sur la sortie standard.</para>
   6.522 -
   6.523 -   &interaction.tour.cat2;
   6.524 -
   6.525 -   <para id="x_3c">La commande Mercurial <command role="hg-cmd">hg status
   6.526 -     </command> nous dira ce que Mercurial sait des fichiers du dépôts.
   6.527 -   </para>
   6.528 -
   6.529 -   &interaction.tour.status;
   6.530 -
   6.531 -   <para id="x_3d">La commande <command role="hg-cmd">hg status</command>
   6.532 -     n'affichera pas le contenu des fichiers, mais une ligne commençant
   6.533 -     par <quote><literal>M</literal></quote> pour <filename>hello.c
   6.534 -     </filename>. A moins que vous lui demandiez, la commande <command 
   6.535 -     role="hg-cmd">hg status</command> n'affichera aucune informations
   6.536 -     sur les fichiers que vous n'avez pas modifié.</para>
   6.537 -
   6.538 -   <para id="x_3d">Le <quote><literal>M</literal></quote> indique que
   6.539 -     Mercurial a remarqué que nous avons modifié le fichier 
   6.540 -     <filename>hello.c</filename>. Nous n'avons pas besoin
   6.541 -     <emphasis>d'informer</emphasis> Mercurial que nous allons modifier le
   6.542 -     fichier avant de commencer à le faire, ou que nous avions modifier le
   6.543 -     fichier avant de le faire, il est capable de découvrir ça tout seul.
   6.544 -   </para>
   6.545 -
   6.546 -   <para id="x_3f">C'est déjà pratique de savoir que nous avons modifié le
   6.547 -   fichier <filename>hello.c</filename>, mais nous préférerions savoir
   6.548 -   exactement <emphasis>ce que</emphasis> nous avons changé. Pour ceci, nous
   6.549 -   utilisons la commande <command role="hg-cmd">hg diff</command>.</para>
   6.550 -
   6.551 -   &interaction.tour.diff;
   6.552 -
   6.553 -   <tip>
   6.554 -     <title>Comprendre les patches</title>
   6.555 -   
   6.556 -     <para id="x_683">Penser à jeter un oeil au site <xref
   6.557 -     linkend="sec:mq:patch"/> si vous n'arrivez pas à lire la sortie
   6.558 -     ci-dessus.</para>
   6.559 -   </tip>
   6.560 - </sect1>
   6.561 - <sect1>
   6.562 -   <title>Enregister vos modifications dans une nouvelle révision</title>
   6.563 -   
   6.564 -   <para id="x_40">Nous pouvons modifier des fichiers, compiler et 
   6.565 -     tester nos modifications, et utiliser les commandes 
   6.566 -     <command role="hg-cmd">hg status</command> et <command role="hg-cmd">hg 
   6.567 -     diff</command> pour voir les modifications effectuées, jusqu'au 
   6.568 -     moment où nous serons assez satisfaits
   6.569 -     pour décider d'enregistrer notre travail dans un \textit{changeset}.
   6.570 -   </para>
   6.571 -
   6.572 -   <para id="x_41">La commande <command role="hg-cmd">hg commit</command> 
   6.573 -     vous laisse créer une nouvelle révision, nous désignerons généralement 
   6.574 -     cette opération par <quote>faire un commit</quote> ou <quote>committer
   6.575 -     </quote>.</para>
   6.576 -
   6.577 -   <sect2>
   6.578 -   <title>Définir le nom d'utilisateur</title>
   6.579 -
   6.580 -     <para id="x_42">Quand vous exécutez la commande <command role="hg-cmd">
   6.581 -       hg commit</command> pour la première fois, il n'est pas garanti
   6.582 -       qu'elle réussisse du premier coup. En effet, Mercurial enregistre
   6.583 -       votre nom et votre adresse avec chaque modification que vous effectuez, 
   6.584 -       de manière à ce que vous soyez capable (ou d'autres le soient) de 
   6.585 -       savoir qui a fait quelle modification. Mercurial essaye automatiquement 
   6.586 -       de découvrir un nom d'utilisateur qui ait un minimum de sens 
   6.587 -       pour effectuer l'opération de commit avec. Il va essayer chacune 
   6.588 -       des méthodes suivantes, dans l'ordre:</para>
   6.589 -     <orderedlist>
   6.590 -       <listitem><para id="x_43">Si vous spécifiez l'option <option 
   6.591 -         role="hg-opt-commit">-u</option> avec la commande
   6.592 -         <command role="hg-cmd">hg commit</command>, suivi d'un nom 
   6.593 -         d'utilisateur, ceci aura toujours la priorité sur les autres 
   6.594 -         méthodes ci dessous.</para></listitem>
   6.595 -       <listitem><para id="x_44">Si vous avez défini une variable d'environnement 
   6.596 -         <envar>HGUSER</envar>, c'est cette valeur qui est alors utilisée.</para></listitem>
   6.597 -      <listitem><para id="x_45">Si vous créez un fichier nommé 
   6.598 -        <filename role="special">.hgrc</filename> dans votre
   6.599 -        répertoire \textit{home}, avec une entrée <envar 
   6.600 -        role="rc-item-ui">username</envar>, c'est la valeur associée 
   6.601 -        qui sera utilisée. Pour voir à quoi ressemble le contenu de ce fichier 
   6.602 -        regardez la section <xref linkend="sec:tour-basic:username"/> 
   6.603 -        ci-dessous.</para></listitem>
   6.604 -      <listitem><para id="x_46">Si vous avez défini une variable 
   6.605 -        d'environnement <envar>EMAIL</envar> celle ci sera utilisée ensuite.</para></listitem>
   6.606 -      <listitem><para id="x_47">Enfin, Mercurial interrogera votre système pour 
   6.607 -        trouver votre nom d'utilisateur local ainsi que le nom de la machine hôte, 
   6.608 -        et il fabriquera un nom d'utilisateur à partir de ces données. Comme
   6.609 -        il arrive souvent que ce genre de noms soit totalement inutile, il vous
   6.610 -        préviendra en affichant un message d'avertissement.</para></listitem>
   6.611 -   </orderedlist>
   6.612 -
   6.613 -   <para id="x_48">Si tous ces mécanismes échouent, Mercurial n'exécutera pas
   6.614 -     la commande, affichant un message d'erreur. Dans ce cas, il ne vous 
   6.615 -     laissera pas effectuer de commit tant que vous n'aurez pas défini un nom
   6.616 -     d'utilisateur.</para>
   6.617 -
   6.618 -   <para id="x_49">Vous devriez penser à utiliser la variable d'environement 
   6.619 -     <envar>HGUSER</envar> et l'option <option role="hg-opt-commit">-u
   6.620 -     </option> comme moyen pour <emphasis>changer</emphasis> le nom d'
   6.621 -     utilisateur} par défaut. Pour une utilisation normale, la manière la 
   6.622 -     plus simple et robuste d'opérer est de créer un fichier 
   6.623 -     <filename role="special">.hgrc</filename>, voir ci-dessous pour 
   6.624 -     les détails à ce sujet.</para>
   6.625 -
   6.626 -   <sect3 id="sec:tour-basic:username">
   6.627 -     <title>Créer un fichier de configuration pour Mercurial</title>
   6.628 -
   6.629 -     <para id="x_4a">Pour définir un nom d'utilisateur, utilisez votre 
   6.630 -       éditeur de texte favori pour créer un fichier <filename 
   6.631 -       role="special">.hgrc</filename> dans votre répertoire home. 
   6.632 -       Mercurial va utiliser ce fichier pour retrouver votre 
   6.633 -       configuration personnelle. Le contenu initial devrait 
   6.634 -       ressembler à ceci:</para>
   6.635 -
   6.636 -     <tip>
   6.637 -       <title><quote>Home directory</quote> on Windows</title>
   6.638 +    <para id="x_39">La première chose que nous allons faire c'est isoler notre
   6.639 +      expérience dans un dépôt à part. Nous allons utiliser la commande <command
   6.640 +        role="hg-cmd">hg clone</command>, mais nous n'avons pas besoin de faire
   6.641 +      une copie de dépôt distant. Comme nous avons déjà une copie locale, nous
   6.642 +      pouvons juste faire un clone de celle-ci à la place. C'est beaucoup plus
   6.643 +      rapide que de faire une copie à travers le réseau, et un dépôt cloné
   6.644 +      localement prend également moins d'espace disque<footnote>
   6.645 +      <para id="x_681">L'économie d'espace disque apparait clairement quand les
   6.646 +        dépôts source et destination sont sur le même système de fichier, où, dans
   6.647 +        ce cas, Mercurial utilisera des liens physiques pour effectuer des partages
   6.648 +        copie-lors-des-écritures de ses métadonnées internes. Si cette explication
   6.649 +        ne signifie rien pour vous, ne vous inquietez pas : tout ceci se passe de
   6.650 +        manière transparente et automatiquement. Vous n'avez pas du tout besoin de
   6.651 +        comprendre ceci.</para></footnote>.</para>
   6.652 +  
   6.653 +    &interaction.tour.reclone;
   6.654 +
   6.655 +    <para id="x_3a">On notera au passage qu'il est souvent considéré comme
   6.656 +      une bonne pratique de conserver une copie <quote>immaculée</quote>
   6.657 +      du dépôt distant, à partir de laquelle vous pourrez faire des 
   6.658 +      copies locales temporaires pour créer des <quote>bacs à sable</quote> 
   6.659 +      pour chaque tâche sur laquelle vous souhaitez travailler. Ceci 
   6.660 +      vous permet de travailler sur plusieurs choses en parallèle, 
   6.661 +      chacune isolée les unes des autres en attendant que ces tâches 
   6.662 +      soient finies et que vous soyez prêt à les réintégrer. Parce 
   6.663 +      que les copies locales sont peu coûteuses, il est très rapide 
   6.664 +      de créer ou détruire des dépôts dès que vous n'en avez plus
   6.665 +      besoin.</para>
   6.666 +
   6.667 +    <para id="x_3b">Dans notre dépôt <filename
   6.668 +        class="directory">my-hello</filename>, nous avons un fichier
   6.669 +      <filename>hello.c</filename> qui contient le classique <quote>hello,
   6.670 +        world</quote>.</para>
   6.671 +   
   6.672 +    &interaction.tour.cat1;
   6.673 +
   6.674 +    <para id="x_682">Editons ce fichier pour qu'il affiche une autre ligne
   6.675 +      sur la sortie standard.</para>
   6.676 +    
   6.677 +    &interaction.tour.cat2;
   6.678 +
   6.679 +    <para id="x_3c">La commande Mercurial <command role="hg-cmd">hg
   6.680 +        status</command> nous dira ce que Mercurial sait des fichiers du
   6.681 +      dépôts.</para>
   6.682 +
   6.683 +    &interaction.tour.status;
   6.684 +
   6.685 +    <para id="x_3d">La commande <command role="hg-cmd">hg status</command>
   6.686 +      n'affichera pas le contenu des fichiers, mais une ligne commençant par
   6.687 +      <quote><literal>M</literal></quote> pour <filename>hello.c</filename>.
   6.688 +      A moins que vous lui demandiez, la commande <command role="hg-cmd">hg
   6.689 +        status</command> n'affichera aucune information sur les fichiers que
   6.690 +      vous n'avez pas modifiés.</para>
   6.691 + 
   6.692 +    <para id="x_3d">Le <quote><literal>M</literal></quote> indique que
   6.693 +      Mercurial a remarqué que nous avons modifié le fichier
   6.694 +      <filename>hello.c</filename>. Nous n'avons pas besoin
   6.695 +      <emphasis>d'informer</emphasis> Mercurial que nous allons modifier un
   6.696 +      fichier avant de commencer à le faire, ou que nous avons modifié un
   6.697 +      fichier après avoir commencé à le faire, il est capable de découvrir ça
   6.698 +      tout seul. </para>
   6.699 +
   6.700 +    <para id="x_3f">C'est déjà pratique de savoir que nous avons modifié le
   6.701 +      fichier <filename>hello.c</filename>, mais nous préférerions savoir
   6.702 +      exactement <emphasis>ce que</emphasis> nous avons changé. Pour ceci, nous
   6.703 +      utilisons la commande <command role="hg-cmd">hg diff</command>.</para>
   6.704 +
   6.705 +    &interaction.tour.diff;
   6.706 +
   6.707 +    <tip>
   6.708 +      <title>Comprendre les patches</title>
   6.709 +   
   6.710 +      <para id="x_683">Penser à jeter un oeil à <xref
   6.711 +          linkend="sec:mq:patch"/> si vous n'arrivez pas à lire la sortie
   6.712 +        ci-dessus.</para>
   6.713 +    </tip>
   6.714 +  </sect1>
   6.715 +  <sect1>
   6.716 +    <title>Enregister vos modifications dans une nouvelle révision</title>
   6.717 +   
   6.718 +    <para id="x_40">Nous pouvons modifier des fichiers, compiler et tester
   6.719 +      nos modifications, et utiliser les commandes <command role="hg-cmd">hg
   6.720 +        status</command> et <command role="hg-cmd">hg diff</command> pour
   6.721 +      voir les modifications effectuées, jusqu'à ce que nous soyons assez
   6.722 +      satisfaits pour décider d'enregistrer notre travail dans un
   6.723 +      \textit{changeset}.</para>
   6.724 +
   6.725 +    <para id="x_41">La commande <command role="hg-cmd">hg commit</command>
   6.726 +      vous laisse créer une nouvelle révision, nous désignerons généralement
   6.727 +      cette opération par <quote>faire un commit</quote> ou
   6.728 +      <quote>committer</quote>.</para>
   6.729 +
   6.730 +    <sect2>
   6.731 +    <title>Définir le nom d'utilisateur</title>
   6.732 +
   6.733 +      <para id="x_42">Quand vous exécutez la commande <command
   6.734 +          role="hg-cmd">hg commit</command> pour la première fois, il n'est
   6.735 +        pas garanti qu'elle réussisse du premier coup. En effet, Mercurial
   6.736 +        enregistre votre nom et votre adresse avec chaque modification que
   6.737 +        vous effectuez, de manière à ce que vous soyez capable (ou d'autres
   6.738 +        le soient) de savoir qui a fait quelle modification. Mercurial essaye
   6.739 +        automatiquement de découvrir un nom d'utilisateur qui ait un minimum
   6.740 +        de sens pour effectuer l'opération de commit avec. Il va essayer
   6.741 +        chacune des méthodes suivantes, dans l'ordre :</para>
   6.742 +
   6.743 +      <orderedlist>
   6.744 +        <listitem><para id="x_43">Si vous spécifiez l'option <option
   6.745 +              role="hg-opt-commit">-u</option> avec la commande <command
   6.746 +              role="hg-cmd">hg commit</command>, suivi d'un nom
   6.747 +            d'utilisateur, ceci aura toujours la priorité sur les autres
   6.748 +            méthodes ci dessous.</para></listitem>
   6.749 +        <listitem><para id="x_44">Si vous avez défini une variable
   6.750 +            d'environnement <envar>HGUSER</envar>, c'est cette valeur qui est
   6.751 +            alors utilisée.</para></listitem>
   6.752 +        <listitem><para id="x_45">Si vous créez un fichier nommé <filename
   6.753 +              role="special">.hgrc</filename> dans votre répertoire
   6.754 +            \textit{home}, avec une entrée <envar
   6.755 +              role="rc-item-ui">username</envar>, c'est la valeur associée
   6.756 +            qui sera utilisée. Pour voir à quoi ressemble le contenu de ce
   6.757 +            fichier regardez la section <xref
   6.758 +              linkend="sec:tour-basic:username"/>
   6.759 +            ci-dessous.</para></listitem>
   6.760 +        <listitem><para id="x_46">Si vous avez défini une variable
   6.761 +            d'environnement <envar>EMAIL</envar> celle ci sera utilisée
   6.762 +            ensuite.</para></listitem>
   6.763 +        <listitem><para id="x_47">Enfin, Mercurial interrogera votre système
   6.764 +            pour trouver votre nom d'utilisateur local ainsi que le nom de la
   6.765 +            machine hôte, et il fabriquera un nom d'utilisateur à partir de
   6.766 +            ces données. Comme il arrive souvent que ce genre de noms soit
   6.767 +            totalement inutile, il vous préviendra en affichant un message
   6.768 +            d'avertissement.</para></listitem>
   6.769 +      </orderedlist>
   6.770 +   
   6.771 +      <para id="x_48">Si tous ces mécanismes échouent, Mercurial n'exécutera
   6.772 +        pas la commande, affichant un message d'erreur. Dans ce cas, il ne
   6.773 +        vous laissera pas effectuer de commit tant que vous n'aurez pas
   6.774 +        défini un nom d'utilisateur.</para>
   6.775 +   
   6.776 +      <para id="x_49">Vous devriez penser à utiliser la variable
   6.777 +        d'environement <envar>HGUSER</envar> et l'option <option
   6.778 +          role="hg-opt-commit">-u</option> comme moyen pour
   6.779 +        <emphasis>changer</emphasis> le nom d'utilisateur par défaut. Pour
   6.780 +        une utilisation normale, la manière la plus simple et robuste
   6.781 +        d'opérer est de créer un fichier <filename
   6.782 +          role="special">.hgrc</filename>, voir ci-dessous pour  les détails
   6.783 +        à ce sujet.</para>
   6.784 +
   6.785 +      <sect3 id="sec:tour-basic:username">
   6.786 +        <title>Créer un fichier de configuration pour Mercurial</title>
   6.787 +
   6.788 +        <para id="x_4a">Pour définir un nom d'utilisateur, utilisez votre 
   6.789 +          éditeur de texte favori pour créer un fichier <filename 
   6.790 +            role="special">.hgrc</filename> dans votre répertoire home. 
   6.791 +          Mercurial va utiliser ce fichier pour retrouver votre 
   6.792 +          configuration personnelle. Le contenu initial devrait
   6.793 +          ressembler à ceci :</para>
   6.794 +   
   6.795 +        <tip>
   6.796 +          <title><quote>Home directory</quote> sous Windows</title>
   6.797 +   
   6.798 +          <para id="x_716">Quand on parle de répertoire home, sur une version
   6.799 +            anglaise d'une installation de Windows, il s'agira habituellement
   6.800 +            d'un répertoire nommée comme votre nom dans <filename>C:\Documents 
   6.801 +              and Settings</filename>. Vous pouvez trouver de quelle répertoire
   6.802 +            il s'agit en lançant une fenêtre d'interpréteur de commande et en
   6.803 +            exécutant la commande suivante :</para>
   6.804            
   6.805 -       <para id="x_716">Quand on parle de répertoire home, sur une version
   6.806 -         anglaise d'une installation de Windows, il s'agira habituellement
   6.807 -         d'un répertoire nommée comme votre nom dans <filename>C:\Documents 
   6.808 -         and Settings</filename>. Vous pouvez trouver de quelle répertoire
   6.809 -         il s'agit en lançant une fenêtre d'interpréteur de commande et en
   6.810 -         exécutant la commande suivante:</para>
   6.811 -        <screen><prompt>C:\</prompt> <userinput>echo %UserProfile</userinput></screen>
   6.812 -     </tip>
   6.813 - 
   6.814 -     <programlisting># This is a Mercurial configuration file.
   6.815 +          <screen><prompt>C:\</prompt> <userinput>echo
   6.816 +              %UserProfile</userinput></screen>
   6.817 +        </tip>
   6.818 +   
   6.819 +        <programlisting># This is a Mercurial configuration file.
   6.820  [ui]
   6.821  username = Firstname Lastname &lt;email.address@domain.net&gt;</programlisting>
   6.822  
   6.823 -     <para id="x_4b">La ligne avec <literal>[ui]</literal> commence une
   6.824 -       <emphasis>section</emphasis> du fichier de configuration, ainsi la ligne
   6.825 -       <quote><literal>username = ...</literal></quote> signifie <quote>
   6.826 -       définir la valeur de l'élément <literal>username</literal> dans la
   6.827 -       section <literal>ui</literal></quote>. Une section continue jusqu'à ce
   6.828 -       qu'une nouvelle commence, ou que la fin du fichier soit atteinte.
   6.829 -       Mercurial ignore les lignes vides et traite tout texte situé à la suite
   6.830 -       d'un <quote><literal>#</literal></quote> jusqu'à la fin de la ligne
   6.831 -       comme un commentaire.</para>
   6.832 +        <para id="x_4b">La ligne avec <literal>[ui]</literal> commence une
   6.833 +          <emphasis>section</emphasis> du fichier de configuration, ainsi la ligne
   6.834 +          <quote><literal>username = ...</literal></quote> signifie <quote>
   6.835 +            définir la valeur de l'élément <literal>username</literal> dans la
   6.836 +            section <literal>ui</literal></quote>. Une section continue jusqu'à ce
   6.837 +          qu'une nouvelle commence, ou que la fin du fichier soit atteinte.
   6.838 +          Mercurial ignore les lignes vides et traite tout texte situé à la suite
   6.839 +          d'un <quote><literal>#</literal></quote> jusqu'à la fin de la ligne
   6.840 +          comme un commentaire.</para>
   6.841  
   6.842        </sect3>
   6.843        <sect3>
   6.844          <title>Choisir un nom d'utilisateur</title>
   6.845 -
   6.846 -       <para id="x_4c">Vous pouvez utiliser n'importe quelle valeur 
   6.847 -         pour votre <literal>username</literal>, car cette information 
   6.848 -         est destinée à d'autres personnes et non à être interprétée 
   6.849 -         par Mercurial. La convention que la plupart des personnes
   6.850 -         suivent est d'utiliser leurs noms suivies de leurs adresses emails,
   6.851 -         comme montrée ci-dessus:</para>
   6.852 -      <note>
   6.853 -        <para id="x_4d">Le mécanisme interne du serveur web intégré à Mercurial,
   6.854 -          masque les adresses emails, pour rendre plus difficile leurs
   6.855 -          récupérations par les outils utilisés par les spammmers.
   6.856 -          Ceci réduit la probabilité que de recevoir encore plus de
   6.857 -          spam si vous vous publiez un dépôt sur internet.</para>
   6.858 -      </note>
   6.859 -    </sect3>
   6.860 -  </sect2>
   6.861 -  <sect2>
   6.862 -    <title>Rédiger un message de \textit{commit}</title>
   6.863 -
   6.864 -    <para id="x_4e">Lorsqu'on effectue une opération de commit, Mercurial
   6.865 -      lance automatiquement un éditeur de texte pour permettre de saisir
   6.866 -      un message qui décrira les modifications effectuées dans cette
   6.867 -      révision. Ce message est nommé le <emphasis>message de commit</emphasis>. 
   6.868 -      Ce sera un enregistrement pour tout lecteur expliquant le pourquoi 
   6.869 -      et le comment de vos modifications, et il sera affiché par la 
   6.870 -      commande <command role="hg-cmd">hg log</command>.</para>
   6.871 -
   6.872 -     &interaction.tour.commit; 
   6.873 -
   6.874 -    <para id="x_4f">L'éditeur que la commande <command role="hg-cmd">hg 
   6.875 -    commit</command> déclenche ne contiendra qu'une ligne vide suivi 
   6.876 -    d'un certain nombre de lignes commençant par <quote><literal>HG:
   6.877 -    </literal></quote>.</para>
   6.878 -
   6.879 -    <programlisting>
   6.880 + 
   6.881 +        <para id="x_4c">Vous pouvez utiliser n'importe quelle valeur 
   6.882 +          pour votre <literal>username</literal>, car cette information 
   6.883 +          est destinée à d'autres personnes et non à être interprétée 
   6.884 +          par Mercurial. La convention que la plupart des personnes
   6.885 +          suivent est d'utiliser leurs noms suivies de leurs adresses emails,
   6.886 +          comme montré ci-dessus :</para>
   6.887 +        <note>
   6.888 +          <para id="x_4d">Le mécanisme interne du serveur web intégré à Mercurial,
   6.889 +            masque les adresses emails, pour rendre plus difficile leurs
   6.890 +            récupérations par les outils utilisés par les spammmers.
   6.891 +            Ceci réduit la probabilité que de recevoir encore plus de
   6.892 +            spam si vous vous publiez un dépôt sur internet.</para>
   6.893 +        </note>
   6.894 +      </sect3>
   6.895 +    </sect2>
   6.896 +    <sect2>
   6.897 +      <title>Rédiger un message de \textit{commit}</title>
   6.898 +  
   6.899 +      <para id="x_4e">Lorsqu'on effectue une opération de commit, Mercurial
   6.900 +        lance automatiquement un éditeur de texte pour permettre de saisir
   6.901 +        un message qui décrira les modifications effectuées dans cette
   6.902 +        révision. Ce message est nommé le <emphasis>message de commit</emphasis>. 
   6.903 +        Ce sera un enregistrement pour tout lecteur expliquant le pourquoi 
   6.904 +        et le comment de vos modifications, et il sera affiché par la 
   6.905 +        commande <command role="hg-cmd">hg log</command>.</para>
   6.906 + 
   6.907 +      &interaction.tour.commit; 
   6.908 +  
   6.909 +      <para id="x_4f">L'éditeur que la commande <command role="hg-cmd">hg 
   6.910 +          commit</command> déclenche ne contiendra qu'une ligne vide suivi 
   6.911 +        d'un certain nombre de lignes commençant par <quote><literal>HG:
   6.912 +        </literal></quote>.</para>
   6.913 +    
   6.914 +        <programlisting>
   6.915      This is where I type my commit comment.
   6.916      
   6.917      HG: Enter commit message.  Lines beginning with 'HG:' are removed.
   6.918 @@ -648,87 +647,90 @@
   6.919      HG: changed hello.c</programlisting>
   6.920  
   6.921  
   6.922 -    <para id="x_50">Mercurial ignore les lignes qui commencent 
   6.923 -      avec <quote><literal>HG:</literal></quote>, il ne les 
   6.924 -      utilise que pour nous indiquer quels fichiers modifiés il se
   6.925 -      prépare à \textit{commiter}. Modifier ou effacer ces lignes n'a
   6.926 -      aucune conséquence sur l'opération de commit.
   6.927 -   </para>
   6.928 -
   6.929 -  </sect2>
   6.930 -  <sect2>
   6.931 -    <title>Rédiger un message \textit{approprié}</title>
   6.932 -
   6.933 -    <para id="x_51">Comme <command role="hg-cmd">hg log</command> n'affiche
   6.934 -      que la première ligne du message de commit par défaut, il est souvent
   6.935 -      considéré comme une bonne pratique de rédiger des messages de commit
   6.936 -      qui tiennent sur une seule ligne. Voilà un exemple concret de message 
   6.937 -      de commit qui <emphasis>ne suit pas</emphasis> cette directive, et qui a donc
   6.938 -      un résumé peu lisible.</para>
   6.939 -
   6.940 -    <programlisting>
   6.941 +      <para id="x_50">Mercurial ignore les lignes qui commencent 
   6.942 +        avec <quote><literal>HG:</literal></quote>, il ne les 
   6.943 +        utilise que pour nous indiquer quels fichiers modifiés il se
   6.944 +        prépare à \textit{commiter}. Modifier ou effacer ces lignes n'a
   6.945 +        aucune conséquence sur l'opération de commit.
   6.946 +      </para>
   6.947 +
   6.948 +    </sect2>
   6.949 +    <sect2>
   6.950 +      <title>Rédiger un message \textit{approprié}</title>
   6.951 +  
   6.952 +      <para id="x_51">Comme <command role="hg-cmd">hg log</command> n'affiche
   6.953 +        que la première ligne du message de commit par défaut, il est souvent
   6.954 +        considéré comme une bonne pratique de rédiger des messages de commit
   6.955 +        qui tiennent sur une seule ligne. Voilà un exemple concret de message 
   6.956 +        de commit qui <emphasis>ne suit pas</emphasis> cette directive, et
   6.957 +        qui a donc un résumé peu lisible.</para>
   6.958 +
   6.959 +      <programlisting>
   6.960  changeset:   73:584af0e231be
   6.961  user:        Censored Person &lt;censored.person@example.org&gt;
   6.962  date:        Tue Sep 26 21:37:07 2006 -0700
   6.963  summary:     include buildmeister/commondefs.   Add an exports and install
   6.964 -    </programlisting>
   6.965 -
   6.966 -    <para id="x_52">A ce sujet, il faut noter qu'il n'existe pas de règle 
   6.967 -      absolue dans ce domaine. Mercurial lui-même n'interprète pas les 
   6.968 -      contenus des messages de commit, ainsi votre projet est libre de 
   6.969 -      concevoir différentes politiques de mise en page des messages.</para>
   6.970 -    <para id="x_53">Ma préférence personnelle va au message court, mais 
   6.971 -    informatif, qui offre des précisions supplémentaires par rapport à ce 
   6.972 -    que pourrait m'apprendre une commande <command role="hg-cmd">hg log 
   6.973 -    --patch</command>.</para>
   6.974 -    <para id="x_55">Si vous exécutez la commande <command role="hg-cmd">hg
   6.975 -     commit</command> sans aucun argument, elle enregistre tout les 
   6.976 -     changements qui ont été fait, et qui sont indiqué par les commandes
   6.977 -     <command role="hg-cmd">hg status</command> et  <command 
   6.978 -     role="hg-cmd">hg diff</command>.</para>
   6.979 -   <note>
   6.980 -     <title>Une surprise pour les utilisateurs habitués à Subversion</title>
   6.981 -
   6.982 -     <para id="x_717">Comme n'importe quel autre commande de Mercurial, si
   6.983 -     vous soumettez pas de manière explicite les noms des fichiers à
   6.984 -     committer à la commande <command role="hg-cmd">hg commit</command>, elle
   6.985 -     va travailler sur l'ensemble du répertoire de travail. Soyez conscient
   6.986 -     de ceci si vous venez du monde Subversion ou CVS, car vous pourriez
   6.987 -     attendre qu'elle opère uniquement le répertoire courant et ses sous
   6.988 -     répertoires.</para>
   6.989 -   </note>
   6.990 -  </sect2>
   6.991 -  <sect2>
   6.992 -    <title>Annuler un \textit{commit}</title>
   6.993 +      </programlisting>
   6.994 +  
   6.995 +      <para id="x_52">A ce sujet, il faut noter qu'il n'existe pas de règle 
   6.996 +        absolue dans ce domaine. Mercurial lui-même n'interprète pas les 
   6.997 +        contenus des messages de commit, ainsi votre projet est libre de 
   6.998 +        concevoir différentes politiques de mise en page des messages.</para>
   6.999 +      
  6.1000 +      <para id="x_53">Ma préférence personnelle va au message court, mais 
  6.1001 +        informatif, qui offre des précisions supplémentaires par rapport à ce 
  6.1002 +        que pourrait m'apprendre une commande <command role="hg-cmd">hg log 
  6.1003 +          --patch</command>.</para>
  6.1004 +      
  6.1005 +      <para id="x_55">Si vous exécutez la commande <command role="hg-cmd">hg
  6.1006 +          commit</command> sans aucun argument, elle enregistre tous les 
  6.1007 +        changements qui ont été fait, et qui sont indiqué par les commandes
  6.1008 +        <command role="hg-cmd">hg status</command> et  <command 
  6.1009 +          role="hg-cmd">hg diff</command>.</para>
  6.1010 +      
  6.1011 +      <note>
  6.1012 +        <title>Une surprise pour les utilisateurs habitués à Subversion</title>
  6.1013 +   
  6.1014 +        <para id="x_717">Comme n'importe quel autre commande de Mercurial, si
  6.1015 +          vous soumettez pas de manière explicite les noms des fichiers à
  6.1016 +          committer à la commande <command role="hg-cmd">hg commit</command>, elle
  6.1017 +          va travailler sur l'ensemble du répertoire de travail. Soyez conscient
  6.1018 +          de ceci si vous venez du monde Subversion ou CVS, car vous pourriez
  6.1019 +          attendre qu'elle opère uniquement le répertoire courant et ses sous
  6.1020 +          répertoires.</para>
  6.1021 +      </note>
  6.1022 +    </sect2>
  6.1023 +    <sect2>
  6.1024 +      <title>Annuler un \textit{commit}</title>
  6.1025  
  6.1026        <para id="x_54">Si, en rédigeant le message, vous décidez que 
  6.1027          finalement vous ne voulez pas effectuer ce commit, il suffit 
  6.1028          de quitter simplement l'éditeur sans sauver. Ceci n'aura aucune 
  6.1029          conséquence sur le dépôt ou les fichiers du répertoire de 
  6.1030          travail.</para>
  6.1031 -  </sect2>
  6.1032 -
  6.1033 -  <sect2>
  6.1034 -  <sect2>
  6.1035 -    <title>Admirer votre travail</title>
  6.1036 -
  6.1037 -    <para id="x_56">Une fois que votre \textit{commit} est terminé, vous pouvez utiliser
  6.1038 -      la commande <command role="hg-cmd">hg tip</command> pour afficher le \textit{changeset} que nous
  6.1039 -      venons de créer. Cette commande produit une sortie à l'écran qui est
  6.1040 -      identique à celle du <command role="hg-cmd">hg log</command>, mais qui n'affiche que la dernière
  6.1041 -      révision du dépôt.</para>
  6.1042 -
  6.1043 -     &interaction.tour.tip; 
  6.1044 -
  6.1045 -    <para id="x_57">On fait couramment référence à la dernière révision 
  6.1046 -      du dépôt comme étant la <emphasis>révision tip</emphasis>, ou plus
  6.1047 -      simplement le <emphasis>tip</emphasis>.</para>
  6.1048 -
  6.1049 -    <para id="x_684">Au passage, la commande <command role="hg-cmd">hg
  6.1050 -        tip</command> accepte la plupart des mêmes options que 
  6.1051 -        <command role="hg-cmd">hg log</command>, ainsi <option
  6.1052 -        role="hg-opt-global">-v</option> ci dessus inplique <quote>soit
  6.1053 -        verbeux</quote>, <option role="hg-opt-tip">-p</option>
  6.1054 +    </sect2>
  6.1055 +  
  6.1056 +    <sect2>
  6.1057 +      <title>Admirer votre travail</title>
  6.1058 +  
  6.1059 +      <para id="x_56">Une fois que votre \textit{commit} est terminé, vous
  6.1060 +        pouvez utiliser la commande <command role="hg-cmd">hg tip</command>
  6.1061 +        pour afficher le \textit{changeset} que vous venez de créer. Cette
  6.1062 +        commande produit  une sortie à l'écran qui est identique à celle du
  6.1063 +        <command role="hg-cmd">hg log</command>, mais qui n'affiche que la
  6.1064 +        dernière révision du dépôt.</para>
  6.1065 + 
  6.1066 +      &interaction.tour.tip; 
  6.1067 +  
  6.1068 +      <para id="x_57">On fait couramment référence à la dernière révision 
  6.1069 +        du dépôt comme étant la <emphasis>révision tip</emphasis>, ou plus
  6.1070 +        simplement le <emphasis>tip</emphasis>.</para>
  6.1071 +  
  6.1072 +      <para id="x_684">Au passage, la commande <command role="hg-cmd">hg
  6.1073 +          tip</command> accepte la plupart des options qu'accepte 
  6.1074 +        <command role="hg-cmd">hg log</command>. Ainsi <option
  6.1075 +          role="hg-opt-global">-v</option> ci dessus implique <quote>soit
  6.1076 +          verbeux</quote>, <option role="hg-opt-tip">-p</option>
  6.1077          veux dire <quote>affiche le patch</quote>. L'utilisation de l'option
  6.1078          <option role="hg-opt-tip">-p</option> pour afficher un patch est un
  6.1079          autre exemple de la cohérence des commandes évoquée plus tôt.</para>
  6.1080 @@ -739,267 +741,272 @@
  6.1081      <title>Partager ses modifications</title>
  6.1082  
  6.1083      <para id="x_58">Nous avons mentionné plus haut que les dépôts 
  6.1084 -    de Mercurial sont autosuffisants. Ce qui signifie que la nouvelle
  6.1085 -    révision que vous venez de créer n'existe seulement dans votre 
  6.1086 -    répertoire <filename class="directory">my-hello</filename>. Étudions 
  6.1087 -    comment propager cette modification dans d'autres dépôts.</para>
  6.1088 +      de Mercurial sont autosuffisants. Ce qui signifie que la nouvelle
  6.1089 +      révision que vous venez de créer existe seulement dans votre 
  6.1090 +      répertoire <filename class="directory">my-hello</filename>. Étudions 
  6.1091 +      comment propager cette modification dans d'autres dépôts.</para>
  6.1092  
  6.1093      <sect2 id="sec:tour:pull">
  6.1094        <title>Récupérer les modifications d'autres dépôts</title>
  6.1095  
  6.1096        <para id="x_5a">Pour commencer, construisons un clone de notre dépôt 
  6.1097 -      <filename class="directory">hello</filename> qui ne contiendra pas 
  6.1098 -      le changement que nous venons d'effectuer. Nous l'appellerons notre 
  6.1099 -      dépôt temporaire <filename class="directory">hello-pull</filename>.</para>
  6.1100 -
  6.1101 -     &interaction.tour.clone-pull;
  6.1102 -
  6.1103 -     <para id="x_5a">Nous allons utiliser la commande <command
  6.1104 -       role="hg-cmd">hg pull</command> pour envoyer les modifications depuis
  6.1105 -       <filename class="directory">my-hello</filename> dans <filename 
  6.1106 -       class="directory">hello-pull</filename>. Néanmoins, récupérer
  6.1107 -       aveuglement des modifications depuis un dépôt a quelque chose d'un peu 
  6.1108 -       effrayant. Mercurial propose donc une commande <command
  6.1109 -       role="hg-cmd">hg incoming</command> qui permet de savoir quelles modifications
  6.1110 -       la commande <command role="hg-cmd">hg pull</command> <emphasis>pourrait</emphasis> 
  6.1111 -       entraîner dans notre dépôt, et ceci sans effectuer réellement de modification 
  6.1112 -       dessus.</para>
  6.1113 +        <filename class="directory">hello</filename> qui ne contiendra pas 
  6.1114 +        le changement que nous venons d'effectuer. Nous l'appellerons notre 
  6.1115 +        dépôt temporaire <filename
  6.1116 +          class="directory">hello-pull</filename>.</para>
  6.1117 + 
  6.1118 +      &interaction.tour.clone-pull;
  6.1119 + 
  6.1120 +      <para id="x_5a">Nous allons utiliser la commande <command
  6.1121 +          role="hg-cmd">hg pull</command> pour envoyer les modifications
  6.1122 +        depuis <filename class="directory">my-hello</filename> dans <filename
  6.1123 +          class="directory">hello-pull</filename>. Néanmoins, récupérer
  6.1124 +        aveuglement des modifications depuis un dépôt a quelque chose d'un
  6.1125 +        peu effrayant. Mercurial propose donc une commande <command
  6.1126 +          role="hg-cmd">hg incoming</command> qui permet de savoir quelles
  6.1127 +        modifications la commande <command role="hg-cmd">hg pull</command>
  6.1128 +        <emphasis>pourrait</emphasis> entraîner dans notre dépôt, et ceci
  6.1129 +        sans effectuer réellement de modification dessus.</para>
  6.1130  
  6.1131        &interaction.tour.incoming; 
  6.1132 -
  6.1133 -    <para id="x_5c">Apporter les modifications rapatriées dans 
  6.1134 -      un dépôt se résume donc à exécuter la commande <command 
  6.1135 -      role="hg-cmd">hg pull</command>, et préciser depuis quel dépôt
  6.1136 -      effectuer le <command role="hg-cmd">hg pull</command>.</para>
  6.1137 -
  6.1138 -     &interaction.tour.pull;
  6.1139 -
  6.1140 -    <para id="x_5d">Comme vous le voyez avec une sortie avant et après de la
  6.1141 -    commande <command role="hg-cmd">hg tip</command>, nous avons réussi à
  6.1142 -    récupérer aisément les modifications dans notre dépôt. Il reste néanmoins
  6.1143 -    quelque chose à faire avant de placer ces modifications dans l'espace de
  6.1144 -    travail.</para>
  6.1145 -   
  6.1146 -   <tip>
  6.1147 -     <title>Récupérer des changements précis</title>
  6.1148 -
  6.1149 -     <para id="x_5b">Il est possible à cause du délai entre l'exécution de la
  6.1150 -       commande <command role="hg-cmd">hg incoming</command> et l'exécution de
  6.1151 -       la commande <command role="hg-cmd">hg pull</command>, que vous ne
  6.1152 -       puissiez pas voir toutes les modifications que vous rapporterez d'un
  6.1153 -       autre dépôt. Suppossons que vous récupériez les modifications d'un dépôt
  6.1154 -       situé quelque part sur le réeau. Alors que vous regardez le résultat de
  6.1155 -       la commande <command role="hg-cmd">hg incoming</command>, et avant que
  6.1156 -       vous ne décidiez de récupérer ces modifications, quelqu'un peut ajouter
  6.1157 -       de nouvelles révisions dans le dépôt distant. Ce qui signigie que vous
  6.1158 -       récupérer plus de révision que ce que vous aviez regarder en utilisant
  6.1159 -       la commande <command role="hg-cmd">hg incoming</command>.</para>
  6.1160 -     <para id="x_718">Si vous voulez seulement récupérer ce que vous aviez
  6.1161 -       vérifier à l'aide de la commande <command role="hg-cmd">hg
  6.1162 -       incoming</command>, ou que pour d'autres raisons vous souhaitiez ne
  6.1163 -       récupérer qu'un sous ensemble des révisions supplémentaires
  6.1164 -       disponibles, indiquant simplement les modifications que vous souhaitez
  6.1165 -       récupérer par leurs ID de révision, soit <command>hg pull
  6.1166 -       -r7e95bb</command>. </para>
  6.1167 -    </tip>
  6.1168 -  </sect2>
  6.1169 -  <sect2>
  6.1170 -    <title>Mise à jour de l'espace de travail</title>
  6.1171 -
  6.1172 -    <para id="x_5e">Nous a:vons jusqu'à maintenant grossièrement définie la
  6.1173 -      relation entre un dépôt et un espace de travail. La commande <command
  6.1174 -      role="hg-cmd">hg pull</command> que nous avons exécutée dans la section 
  6.1175 -      <xref linkend="sec:tour:pull"/> a apporté des modifications, que nous
  6.1176 -      avons vérifiées, dans notre dépôt, mais il n'y a aucune trace de ces
  6.1177 -      modifications dans notre espace de travail. En effet, <command
  6.1178 -      role="hg-cmd">hg pull</command> ne touche pas (par défaut) à l'espace
  6.1179 -      de travail. C'est la commande <command role="hg-cmd">hg update</command>
  6.1180 -      qui s'en charge.</para>
  6.1181 -
  6.1182 -     &interaction.tour.update;
  6.1183 -
  6.1184 -    <para id="x_5f">Il peut sembler un peu étrange que la commande <command
  6.1185 -      role="hg-cmd">hg pull</command> ne mette pas à jour l'espace de travail
  6.1186 -      automatiquement. Il y a en fait une très bonne raison à cela : vous
  6.1187 -      pouvez utilisez la commande <command role="hg-cmd">hg update</command>
  6.1188 -      pour mettre à jour votre espace de travail à l'état dans lequel il était 
  6.1189 -      à <emphasis>n'importe quelle révision</emphasis> de l'historique du dépôt. 
  6.1190 -      Si vous aviez un espace de travail contenant une ancienne
  6.1191 -      révision&emdash;pour chercher l'origine d'un bug, par exemple&emdash;et
  6.1192 -      que vous effectuiez un <command role="hg-cmd">hg pull</command> qui
  6.1193 -      mettrait à jour automatiquement votre espace de travail, vous ne seriez
  6.1194 -      probablement pas très satisfait.
  6.1195 -    </para>
  6.1196 -
  6.1197 -    <para id="x_60">Néanmoins, comme les opérations de pull sont très souvent
  6.1198 -      suivies d'un update, Mercurial vous permet de combiner les
  6.1199 -      deux aisément en passant l'option <option role="hg-opt-pull">-u</option> 
  6.1200 -      à la commande <command role="hg-cmd">hg pull</command>.</para>
  6.1201 -
  6.1202 -    <para id="x_61">Si vous étudiez de nouveau la sortie de la commande <command
  6.1203 -      role="hg-cmd">hg pull</command> dans la section <xref
  6.1204 -      linkend="sec:tour:pull"/> quand nous l'avons exécutée sans l'option
  6.1205 -      <option role="hg-opt-pull">-u</option>, vous pouvez constater qu'elle a
  6.1206 -      affiché un rappel assez utile : vous devez encore effectuer une
  6.1207 -      opération pour mettre à jour votre espace de travail.</para>
  6.1208 -
  6.1209 -    <para id="x_62">Pour découvrir sur quelle révision de l'espace de 
  6.1210 -      travail on se trouve, utilisez la commande <command role="hg-cmd">hg
  6.1211 -      parents</command>.</para>
  6.1212 -
  6.1213 -     &interaction.tour.parents;
  6.1214 -
  6.1215 -   <para id="x_63">Si vous regardez de nouveau le dessin <xref
  6.1216 -     linkend="fig:tour-basic:history"/>, vous verrez les flèches reliant
  6.1217 -     entre eux les révisions. Le nœud d'où la flèche
  6.1218 -     <emphasis>part</emphasis> est dans chaque cas un parent,
  6.1219 -     et le nœud où la flèche <emphasis>arrive</emphasis> est un enfant.</para>
  6.1220 -
  6.1221 -   <para id="x_64">Pour mettre à jour l'espace de travail d'une révision particulière,
  6.1222 -     indiquez un numéro de révision ou un \textit{changeset ID} à la commande
  6.1223 -     <command role="hg-cmd">hg update</command>.</para>
  6.1224 -
  6.1225 -    &interaction.tour.older;
  6.1226 -
  6.1227 -   <para id="x_65">Si vous ne précisez pas de manière explicite de numéro 
  6.1228 -     de révision la commande <command role="hg-cmd">hg update</command>
  6.1229 -     mettra à jour votre espace de travail avec
  6.1230 -     le contenu de la révsion \textit{tip}, comme montré dans l'exemple ci
  6.1231 -     dessus lors du second appel à <command role="hg-cmd">hg update</command>.</para>
  6.1232 -  </sect2>
  6.1233 -
  6.1234 -  <sect2>
  6.1235 -    <title>Transférer les modifications à un autre dépôt</title>
  6.1236 -
  6.1237 -    <para id="x_66">Mercurial vous laisse transférer les modifications 
  6.1238 -      à un autre dépôt, depuis votre dépôt actuel. Comme dans l'exemple 
  6.1239 -      du <command role="hg-cmd">hg pull</command> ci-dessus, nous allons 
  6.1240 -      créer un dépôt temporaire vers lequel transférer nos modifications.
  6.1241 -
  6.1242 -     &interaction.tour.clone-push;
  6.1243 -
  6.1244 -    <para id="x_67">La commande <command role="hg-cmd">hg outgoing</command>
  6.1245 -      nous indique quels changements nous allons transférer vers l'autre
  6.1246 -      serveur ?</para>
  6.1247 -
  6.1248 -     &interaction.tour.outgoing;
  6.1249 -
  6.1250 -    <para id="x_68">Et la commande <command role="hg-cmd">hg push</command> 
  6.1251 -      effectue réellement le transfert.</para>
  6.1252 -
  6.1253 -     &interaction.tour.push;
  6.1254 -
  6.1255 -    <para id="x_69">Comme avec <command role="hg-cmd">hg pull</command>, la
  6.1256 -      commande <command role="hg-cmd">hg push</command> ne met pas à jour
  6.1257 -      le répertoire de travail du dépôt dans lequel il transfère les
  6.1258 -      modifications. À l'inverse de <command role="hg-cmd">hg pull</command>, 
  6.1259 -      <command role="hg-cmd">hg push</command> ne fournit pas d'option 
  6.1260 -      <literal>-u</literal> pour forcer la mise à jour de l'espace de
  6.1261 -      travail cible. Cette asymétrie est délibéré : le dépot vers lequel nous
  6.1262 -      transférons peut très bien être un serveur distant et partagé par
  6.1263 -      plusieurs personnes. Si nous devions mettre à jour son répertoire de
  6.1264 -      travail alors que quelqu'un d'autre travail dessus, nous risquerions 
  6.1265 -      de perturber son travail.</para>
  6.1266 -
  6.1267 -    <para id="x_6a">Qu'est ce qui se passe lorsque vous essayez de récupérer
  6.1268 -      ou de transférer vos modifications et que le dépôt cible a déjà reçu
  6.1269 -      ces modifications ? Rien de bien excitant.</para>
  6.1270 -
  6.1271 -     &interaction.tour.push.nothing;
  6.1272 -
  6.1273 -  </sect2>
  6.1274 -
  6.1275 -  <sect2>
  6.1276 -    <title>Emplacements par défaut</title>
  6.1277 -          
  6.1278 -    <para id="x_719">Quand nous faisons un clone d'un dépôt, Mercurial
  6.1279 -      enregistre l'emplacement du dépôt d'origine dans le fichier
  6.1280 -      <filename>.hg/hgrc</filename> de notre nouveau dépôt. Si nous ne
  6.1281 -      fournissons pas d'emplacement à la commande <command>hg pull</command>
  6.1282 -      ou à la commande <command>hg push</command>, ces commandes utiliseront
  6.1283 -      alors ces emplacements comme valeur par défaut. Les commandes
  6.1284 -      <command>hg incoming</command> et <command>hg outgoing</command> feront
  6.1285 -      de même.</para>
  6.1286 -
  6.1287 -    <para id="x_71a">Si vous regardez le fichier
  6.1288 -      <filename>.hg/hgrc</filename>, vous constaterez que son contenu ressemble
  6.1289 -      à ce qui suit.</para>
  6.1290 -
  6.1291 -    <programlisting>[paths]
  6.1292 +  
  6.1293 +      <para id="x_5c">Apporter les modifications rapatriées dans un dépôt se
  6.1294 +        résume donc à exécuter la commande <command role="hg-cmd">hg
  6.1295 +          pull</command>, et préciser depuis quel dépôt effectuer le <command
  6.1296 +          role="hg-cmd">hg pull</command>.</para>
  6.1297 +      
  6.1298 +      &interaction.tour.pull;
  6.1299 +  
  6.1300 +      <para id="x_5d">Comme vous le voyez avec une sortie avant et après de la
  6.1301 +        commande <command role="hg-cmd">hg tip</command>, nous avons réussi à
  6.1302 +        récupérer aisément les modifications dans notre dépôt. Il reste néanmoins
  6.1303 +        quelque chose à faire avant de placer ces modifications dans l'espace de
  6.1304 +        travail.</para>
  6.1305 +   
  6.1306 +      <tip>
  6.1307 +        <title>Récupérer des changements précis</title>
  6.1308 +   
  6.1309 +        <para id="x_5b">Il est possible à cause du délai entre l'exécution de la
  6.1310 +          commande <command role="hg-cmd">hg incoming</command> et l'exécution de
  6.1311 +          la commande <command role="hg-cmd">hg pull</command>, que vous ne
  6.1312 +          puissiez pas voir toutes les modifications que vous rapporterez d'un
  6.1313 +          autre dépôt. Supposons que vous récupériez les modifications d'un dépôt
  6.1314 +          situé quelque part sur le réseau. Alors que vous regardez le résultat de
  6.1315 +          la commande <command role="hg-cmd">hg incoming</command>, et avant que
  6.1316 +          vous ne décidiez de récupérer ces modifications, quelqu'un peut ajouter
  6.1317 +          de nouvelles révisions dans le dépôt distant. Ce qui signifie que vous
  6.1318 +          récupérez plus de révision que ce que vous aviez regardées en utilisant
  6.1319 +          la commande <command role="hg-cmd">hg incoming</command>.</para>
  6.1320 +
  6.1321 +        <para id="x_718">Si vous voulez seulement récupérer ce que vous aviez
  6.1322 +          vérifier à l'aide de la commande <command role="hg-cmd">hg
  6.1323 +            incoming</command>, ou que pour d'autres raisons vous souhaitiez ne
  6.1324 +          récupérer qu'un sous ensemble des révisions supplémentaires
  6.1325 +          disponibles, indiquant simplement les modifications que vous souhaitez
  6.1326 +          récupérer par leurs ID de révision, soit <command>hg pull
  6.1327 +            -r7e95bb</command>. </para>
  6.1328 +      </tip>
  6.1329 +  
  6.1330 +    </sect2>
  6.1331 +    <sect2>
  6.1332 +      <title>Mise à jour de l'espace de travail</title>
  6.1333 +  
  6.1334 +      <para id="x_5e">Nous avons jusqu'à maintenant grossièrement défini la
  6.1335 +        relation entre un dépôt et un espace de travail. La commande <command
  6.1336 +          role="hg-cmd">hg pull</command> que nous avons exécutée dans la section 
  6.1337 +        <xref linkend="sec:tour:pull"/> a apporté des modifications, que nous
  6.1338 +        avons vérifiées, dans notre dépôt, mais il n'y a aucune trace de ces
  6.1339 +        modifications dans notre espace de travail. En effet, <command
  6.1340 +          role="hg-cmd">hg pull</command> ne touche pas (par défaut) à l'espace
  6.1341 +        de travail. C'est la commande <command role="hg-cmd">hg update</command>
  6.1342 +        qui s'en charge.</para>
  6.1343 + 
  6.1344 +      &interaction.tour.update;
  6.1345 +  
  6.1346 +      <para id="x_5f">Il peut sembler un peu étrange que la commande <command
  6.1347 +          role="hg-cmd">hg pull</command> ne mette pas à jour l'espace de travail
  6.1348 +        automatiquement. Il y a en fait une très bonne raison à cela : vous
  6.1349 +        pouvez utilisez la commande <command role="hg-cmd">hg update</command>
  6.1350 +        pour mettre à jour votre espace de travail à l'état dans lequel il était 
  6.1351 +        à <emphasis>n'importe quelle révision</emphasis> de l'historique du dépôt. 
  6.1352 +        Si vous aviez un espace de travail contenant une ancienne
  6.1353 +        révision&emdash;pour chercher l'origine d'un bug, par exemple&emdash;et
  6.1354 +        que vous effectuiez un <command role="hg-cmd">hg pull</command> qui
  6.1355 +        mettrait à jour automatiquement votre espace de travail, vous ne seriez
  6.1356 +        probablement pas très satisfait.</para>
  6.1357 +  
  6.1358 +      <para id="x_60">Néanmoins, comme les opérations de pull sont très souvent
  6.1359 +        suivies d'un update, Mercurial vous permet de combiner les
  6.1360 +        deux aisément en passant l'option <option role="hg-opt-pull">-u</option> 
  6.1361 +        à la commande <command role="hg-cmd">hg pull</command>.</para>
  6.1362 +  
  6.1363 +      <para id="x_61">Si vous étudiez de nouveau la sortie de la commande <command
  6.1364 +          role="hg-cmd">hg pull</command> dans la section <xref
  6.1365 +          linkend="sec:tour:pull"/> quand nous l'avons exécutée sans l'option
  6.1366 +        <option role="hg-opt-pull">-u</option>, vous pouvez constater qu'elle a
  6.1367 +        affiché un rappel assez utile : vous devez encore effectuer une
  6.1368 +        opération pour mettre à jour votre espace de travail.</para>
  6.1369 +
  6.1370 +      <para id="x_62">Pour découvrir sur quelle révision de l'espace de 
  6.1371 +        travail on se trouve, utilisez la commande <command role="hg-cmd">hg
  6.1372 +          parents</command>.</para>
  6.1373 + 
  6.1374 +      &interaction.tour.parents;
  6.1375 +   
  6.1376 +      <para id="x_63">Si vous regardez de nouveau le dessin <xref
  6.1377 +          linkend="fig:tour-basic:history"/>, vous verrez les flèches reliant
  6.1378 +        entre elles les révisions. Le nœud d'où la flèche
  6.1379 +        <emphasis>part</emphasis> est dans chaque cas un parent,
  6.1380 +        et le nœud où la flèche <emphasis>arrive</emphasis> est un
  6.1381 +        enfant.</para>
  6.1382 +
  6.1383 +      <para id="x_64">Pour mettre à jour l'espace de travail d'une révision
  6.1384 +        particulière, indiquez un numéro de révision ou un \textit{changeset
  6.1385 +        ID} à la commande <command role="hg-cmd">hg update</command>.</para>
  6.1386 +  
  6.1387 +      &interaction.tour.older;
  6.1388 +   
  6.1389 +      <para id="x_65">Si vous ne précisez pas de manière explicite de numéro 
  6.1390 +        de révision la commande <command role="hg-cmd">hg update</command>
  6.1391 +        mettra à jour votre espace de travail avec le contenu de la révison
  6.1392 +        \textit{tip}, comme montré dans l'exemple ci dessus lors du second
  6.1393 +        appel à <command role="hg-cmd">hg update</command>.</para>
  6.1394 +    
  6.1395 +    </sect2>
  6.1396 +    <sect2>
  6.1397 +      <title>Transférer les modifications vers un autre dépôt</title>
  6.1398 +  
  6.1399 +      <para id="x_66">Mercurial vous laisse transférer les modifications vers
  6.1400 +        un autre dépôt, depuis votre dépôt actuel. Comme dans l'exemple du
  6.1401 +        <command role="hg-cmd">hg pull</command> ci-dessus, nous allons créer
  6.1402 +        un dépôt temporaire vers lequel transférer nos modifications.</para>
  6.1403 +        
  6.1404 +      &interaction.tour.clone-push;
  6.1405 +  
  6.1406 +      <para id="x_67">La commande <command role="hg-cmd">hg outgoing</command>
  6.1407 +        nous indique quels changements nous allons transférer vers l'autre
  6.1408 +        serveur.</para>
  6.1409 + 
  6.1410 +      &interaction.tour.outgoing;
  6.1411 +  
  6.1412 +      <para id="x_68">Et la commande <command role="hg-cmd">hg push</command> 
  6.1413 +        effectue réellement le transfert.</para>
  6.1414 + 
  6.1415 +      &interaction.tour.push;
  6.1416 +  
  6.1417 +      <para id="x_69">Comme avec <command role="hg-cmd">hg pull</command>, la
  6.1418 +        commande <command role="hg-cmd">hg push</command> ne met pas à jour
  6.1419 +        le répertoire de travail du dépôt dans lequel il transfère les
  6.1420 +        modifications. À l'inverse de <command role="hg-cmd">hg
  6.1421 +          pull</command>, <command role="hg-cmd">hg push</command> ne fournit
  6.1422 +        pas d'option <literal>-u</literal> pour forcer la mise à jour de
  6.1423 +        l'espace de travail cible. Cette asymétrie est délibéré : le dépot
  6.1424 +        vers lequel nous transférons peut très bien être un serveur distant
  6.1425 +        et partagé par plusieurs personnes. Si nous devions mettre à jour son
  6.1426 +        répertoire de travail alors que quelqu'un d'autre travaille dessus,
  6.1427 +        nous risquerions de perturber son travail.</para>
  6.1428 +  
  6.1429 +      <para id="x_6a">Qu'est ce qui se passe lorsque vous essayez de récupérer
  6.1430 +        ou de transférer vos modifications et que le dépôt cible a déjà reçu
  6.1431 +        ces modifications ? Rien de bien excitant.</para>
  6.1432 + 
  6.1433 +      &interaction.tour.push.nothing;
  6.1434 +  
  6.1435 +    </sect2>
  6.1436 +  
  6.1437 +    <sect2>
  6.1438 +      <title>Emplacements par défaut</title>
  6.1439 +
  6.1440 +      <para id="x_719">Quand nous faisons un clone d'un dépôt, Mercurial
  6.1441 +        enregistre l'emplacement du dépôt d'origine dans le fichier
  6.1442 +        <filename>.hg/hgrc</filename> de notre nouveau dépôt. Si nous ne
  6.1443 +        fournissons pas d'emplacement à la commande <command>hg
  6.1444 +          pull</command> ou à la commande <command>hg push</command>, ces
  6.1445 +        commandes utiliseront alors cet emplacement comme valeur par défaut.
  6.1446 +        Les commandes <command>hg incoming</command> et <command>hg
  6.1447 +          outgoing</command> feront de même.</para>
  6.1448 +  
  6.1449 +      <para id="x_71a">Si vous regardez le fichier
  6.1450 +        <filename>.hg/hgrc</filename>, vous constaterez que son contenu
  6.1451 +        ressemble à ce qui suit.</para>
  6.1452 +  
  6.1453 +      <programlisting>[paths]
  6.1454  default = http://www.selenic.com/repo/hg</programlisting>
  6.1455        
  6.1456 -    <para id="x_71b">Il est possible&emdash;et souvent
  6.1457 -      pratique&emdash;d'avoir un emplacement par défaut pour la commande
  6.1458 -      <command>hg push</command> et la commande <command>hg outgoing</command>
  6.1459 -      différent de celui des commandes <command>hg pull</command> et des
  6.1460 -      <command>hg incoming</command>. C'est faisable en ajoutant une entrée
  6.1461 -      <literal>default-push</literal> à la section <literal>[paths]</literal>
  6.1462 -      du <filename>.hg/hgrc</filename>, comme suit.</para>
  6.1463 -    
  6.1464 -    <programlisting>[paths]
  6.1465 +      <para id="x_71b">Il est possible&emdash;et souvent
  6.1466 +        pratique&emdash;d'avoir un emplacement par défaut pour les commandes
  6.1467 +        <command>hg push</command> et <command>hg outgoing</command>
  6.1468 +        différent de celui des commandes <command>hg pull</command> et
  6.1469 +        <command>hg incoming</command>. C'est faisable en ajoutant une entrée
  6.1470 +        <literal>default-push</literal> à la section
  6.1471 +        <literal>[paths]</literal> du <filename>.hg/hgrc</filename>, comme
  6.1472 +        suit.</para>
  6.1473 +   
  6.1474 +      <programlisting>[paths]
  6.1475  default = http://www.selenic.com/repo/hg
  6.1476  default-push = http://hg.example.com/hg</programlisting>
  6.1477 -  </sect2>
  6.1478 -
  6.1479 -  <sect2>
  6.1480 -    <title>Partager ses modifications à travers le réseau</title>
  6.1481 -
  6.1482 -    <para id="x_6b">Les commandes que nous avons étudiées dans les sections
  6.1483 -      précédentes ne sont pas limitées aux dépôt locaux. Chacune fonctionne 
  6.1484 -      de la même manière à travers une connexion réseau, il suffit de lui 
  6.1485 -      passer une URL à la place d'un chemin de fichier local.</para>
  6.1486 -
  6.1487 -     &interaction.tour.outgoing.net;
  6.1488 -
  6.1489 -    <para id="x_6c">Dans cet exemple, nous allons voir quels changements 
  6.1490 -      nous pourrions transférer vers le dépôt distant, mais le dépôt est, 
  6.1491 -      de manière tout à fait compréhensible, pas configuré pour accepter 
  6.1492 -      des modifications d'utilisateurs anonymes.</para>
  6.1493 -
  6.1494 -     &interaction.tour.push.net; 
  6.1495 -    </sect2>
  6.1496 +
  6.1497 +    </sect2>
  6.1498 +    <sect2>
  6.1499 +      <title>Partager ses modifications à travers le réseau</title>
  6.1500 +  
  6.1501 +      <para id="x_6b">Les commandes que nous avons étudiées dans les sections
  6.1502 +        précédentes ne sont pas limitées aux dépôts locaux. Chacune fonctionne 
  6.1503 +        de la même manière à travers une connexion réseau, il suffit de lui 
  6.1504 +        passer une URL à la place d'un chemin de fichier local.</para>
  6.1505 + 
  6.1506 +      &interaction.tour.outgoing.net;
  6.1507 +  
  6.1508 +      <para id="x_6c">Dans cet exemple, nous allons voir quels changements 
  6.1509 +        nous pourrions transférer vers le dépôt distant, mais le dépôt est, 
  6.1510 +        de manière tout à fait compréhensible, pas configuré pour accepter 
  6.1511 +        des modifications d'utilisateurs anonymes.</para>
  6.1512 + 
  6.1513 +      &interaction.tour.push.net; 
  6.1514 +    
  6.1515 +    </sect2>
  6.1516 +
  6.1517    </sect1>
  6.1518  
  6.1519    <sect1>
  6.1520 -    <title>Commencer un nouveau projet</title>w
  6.1521 -    
  6.1522 -      <para id="x_71c">Il est tout aussi aisé de commencer un nouveau projet
  6.1523 -        que de travailler sur un qui existe déjà. La commande
  6.1524 -        <command>hg init</command> créer un nouveau dépôt Mercurial,
  6.1525 -        vide.</para>
  6.1526 -      
  6.1527 -       &interaction.ch01-new.init;
  6.1528 -                        
  6.1529 -      <para id="x_71d">Ceci créer simplement un répertoire nommée
  6.1530 -        <filename>myproject</filename> dans le répertoire courant.</para>
  6.1531 -
  6.1532 -       &interaction.ch01-new.ls;
  6.1533 -
  6.1534 -      <para id="x_71e">Nous pouvons dire que <filename>myproject</filename>
  6.1535 -        est un dépôt Mercurial car il contient un répertoire
  6.1536 -        <filename>.hg</filename>.</para>
  6.1537 -
  6.1538 -       &interaction.ch01-new.ls2;
  6.1539 -      
  6.1540 -      <para id="x_71f">Si vous voulons ajouter quelques fichiers préexistants
  6.1541 -        dans ce dépôt, il suffit de les recopier dans le répertoire de travail,
  6.1542 -        et demander à Mercurial de commencer les suivre en utilisant la
  6.1543 -        commande <command>hg add</command>.</para>
  6.1544 -
  6.1545 -      &interaction.ch01-new.add;
  6.1546 -
  6.1547 -      <para id="x_720">Une fois que nous sommes satisfait de notre projet,
  6.1548 -        nous pouvons commencer à ajouter nos révisions.</para>
  6.1549 -
  6.1550 -       &interaction.ch01-new.commit;
  6.1551 -
  6.1552 -      <para id="x_721">Il ne prend que quelques instants pour commencer à
  6.1553 +    <title>Commencer un nouveau projet</title>
  6.1554 +
  6.1555 +    <para id="x_71c">Il est tout aussi aisé de commencer un nouveau projet
  6.1556 +      que de travailler sur un qui existe déjà. La commande <command>hg
  6.1557 +        init</command> crée un nouveau dépôt Mercurial vide.</para>
  6.1558 +
  6.1559 +    &interaction.ch01-new.init;
  6.1560 +
  6.1561 +    <para id="x_71d">Ceci crée simplement un répertoire nommé
  6.1562 +      <filename>myproject</filename> dans le répertoire courant.</para>
  6.1563 +
  6.1564 +    &interaction.ch01-new.ls;
  6.1565 +
  6.1566 +    <para id="x_71e">Nous pouvons dire que <filename>myproject</filename> est
  6.1567 +      un dépôt Mercurial car il contient un répertoire
  6.1568 +      <filename>.hg</filename>.</para>
  6.1569 +
  6.1570 +    &interaction.ch01-new.ls2;
  6.1571 +
  6.1572 +    <para id="x_71f">Si vous voulons ajouter quelques fichiers préexistants
  6.1573 +      dans ce dépôt, il suffit de les recopier dans le répertoire de travail,
  6.1574 +      et demander à Mercurial de commencer à les suivre en utilisant la
  6.1575 +      commande <command>hg add</command>.</para>
  6.1576 +
  6.1577 +    &interaction.ch01-new.add;
  6.1578 +
  6.1579 +    <para id="x_720">Une fois que nous sommes satisfaits de notre projet,
  6.1580 +      nous pouvons commencer à ajouter nos révisions.</para>
  6.1581 +
  6.1582 +    &interaction.ch01-new.commit;
  6.1583 +
  6.1584 +    <para id="x_721">Il ne prend que quelques instants pour commencer à
  6.1585        utiliser Mercurial sur un nouveau projet, ce qui fait aussi de ses
  6.1586        points forts. Travailler avec une gestion de révision devient très
  6.1587        facile, nous pouvons même l'utiliser pour les plus petits projets où
  6.1588        nous aurions probablement jamais penser utiliser un outils aussi
  6.1589        complexe.</para>
  6.1590 -   </sect1>
  6.1591 +  </sect1>
  6.1592  </chapter>
  6.1593  
  6.1594  <!--

     7.1 --- a/fr/ch04-concepts.xml	Sat Sep 12 17:58:26 2009 +0200
     7.2 +++ b/fr/ch04-concepts.xml	Sat Sep 12 17:58:56 2009 +0200
     7.3 @@ -1,710 +1,771 @@
     7.4  <!-- vim: set filetype=docbkxml shiftwidth=2 autoindent expandtab tw=77 : -->
     7.5  
     7.6 -<chapter>
     7.7 -<title>Behind the scenes</title>
     7.8 -<para>\label{chap:concepts}</para>
     7.9 -
    7.10 -<para>Unlike many revision control systems, the concepts upon which
    7.11 -Mercurial is built are simple enough that it's easy to understand how
    7.12 -the software really works.  Knowing this certainly isn't necessary,
    7.13 -but I find it useful to have a <quote>mental model</quote> of what's going on.</para>
    7.14 -
    7.15 -<para>This understanding gives me confidence that Mercurial has been
    7.16 -carefully designed to be both <emphasis>safe</emphasis> and <emphasis>efficient</emphasis>.  And
    7.17 -just as importantly, if it's easy for me to retain a good idea of what
    7.18 -the software is doing when I perform a revision control task, I'm less
    7.19 -likely to be surprised by its behaviour.</para>
    7.20 -
    7.21 -<para>In this chapter, we'll initially cover the core concepts behind
    7.22 -Mercurial's design, then continue to discuss some of the interesting
    7.23 -details of its implementation.</para>
    7.24 -
    7.25 -<sect1>
    7.26 -<title>Mercurial's historical record</title>
    7.27 -
    7.28 -<sect2>
    7.29 -<title>Tracking the history of a single file</title>
    7.30 -
    7.31 -<para>When Mercurial tracks modifications to a file, it stores the history
    7.32 -of that file in a metadata object called a <emphasis>filelog</emphasis>.  Each entry
    7.33 -in the filelog contains enough information to reconstruct one revision
    7.34 -of the file that is being tracked.  Filelogs are stored as files in
    7.35 -the <filename role="special" class="directory">.hg/store/data</filename> directory.  A filelog contains two kinds
    7.36 -of information: revision data, and an index to help Mercurial to find
    7.37 -a revision efficiently.</para>
    7.38 -
    7.39 -<para>A file that is large, or has a lot of history, has its filelog stored
    7.40 -in separate data (<quote><literal>.d</literal></quote> suffix) and index (<quote><literal>.i</literal></quote>
    7.41 -suffix) files.  For small files without much history, the revision
    7.42 -data and index are combined in a single <quote><literal>.i</literal></quote> file.  The
    7.43 -correspondence between a file in the working directory and the filelog
    7.44 -that tracks its history in the repository is illustrated in
    7.45 -figure <xref linkend="fig:concepts:filelog"/>.</para>
    7.46 -
    7.47 -<informalfigure>
    7.48 -
    7.49 -<para>  <mediaobject><imageobject><imagedata fileref="filelog"/></imageobject><textobject><phrase>XXX add text</phrase></textobject></mediaobject>
    7.50 -  \caption{Relationships between files in working directory and
    7.51 -    filelogs in repository}
    7.52 -  \label{fig:concepts:filelog}</para>
    7.53 -</informalfigure>
    7.54 -
    7.55 -</sect2>
    7.56 -<sect2>
    7.57 -<title>Managing tracked files</title>
    7.58 -
    7.59 -<para>Mercurial uses a structure called a <emphasis>manifest</emphasis> to collect
    7.60 -together information about the files that it tracks.  Each entry in
    7.61 -the manifest contains information about the files present in a single
    7.62 -changeset.  An entry records which files are present in the changeset,
    7.63 -the revision of each file, and a few other pieces of file metadata.</para>
    7.64 -
    7.65 -</sect2>
    7.66 -<sect2>
    7.67 -<title>Recording changeset information</title>
    7.68 -
    7.69 -<para>The <emphasis>changelog</emphasis> contains information about each changeset.  Each
    7.70 -revision records who committed a change, the changeset comment, other
    7.71 -pieces of changeset-related information, and the revision of the
    7.72 -manifest to use.
    7.73 -</para>
    7.74 -
    7.75 -</sect2>
    7.76 -<sect2>
    7.77 -<title>Relationships between revisions</title>
    7.78 -
    7.79 -<para>Within a changelog, a manifest, or a filelog, each revision stores a
    7.80 -pointer to its immediate parent (or to its two parents, if it's a
    7.81 -merge revision).  As I mentioned above, there are also relationships
    7.82 -between revisions <emphasis>across</emphasis> these structures, and they are
    7.83 -hierarchical in nature.
    7.84 -</para>
    7.85 -
    7.86 -<para>For every changeset in a repository, there is exactly one revision
    7.87 -stored in the changelog.  Each revision of the changelog contains a
    7.88 -pointer to a single revision of the manifest.  A revision of the
    7.89 -manifest stores a pointer to a single revision of each filelog tracked
    7.90 -when that changeset was created.  These relationships are illustrated
    7.91 -in figure <xref linkend="fig:concepts:metadata"/>.
    7.92 -</para>
    7.93 -
    7.94 -<informalfigure>
    7.95 -
    7.96 -<para>  <mediaobject><imageobject><imagedata fileref="metadata"/></imageobject><textobject><phrase>XXX add text</phrase></textobject></mediaobject>
    7.97 -  <caption><para>Metadata relationships</para></caption>
    7.98 -  \label{fig:concepts:metadata}
    7.99 -</para>
   7.100 -</informalfigure>
   7.101 -
   7.102 -<para>As the illustration shows, there is <emphasis>not</emphasis> a <quote>one to one</quote>
   7.103 -relationship between revisions in the changelog, manifest, or filelog.
   7.104 -If the manifest hasn't changed between two changesets, the changelog
   7.105 -entries for those changesets will point to the same revision of the
   7.106 -manifest.  If a file that Mercurial tracks hasn't changed between two
   7.107 -changesets, the entry for that file in the two revisions of the
   7.108 -manifest will point to the same revision of its filelog.
   7.109 -</para>
   7.110 -
   7.111 -</sect2>
   7.112 -</sect1>
   7.113 -<sect1>
   7.114 -<title>Safe, efficient storage</title>
   7.115 -
   7.116 -<para>The underpinnings of changelogs, manifests, and filelogs are provided
   7.117 -by a single structure called the <emphasis>revlog</emphasis>.
   7.118 -</para>
   7.119 -
   7.120 -<sect2>
   7.121 -<title>Efficient storage</title>
   7.122 -
   7.123 -<para>The revlog provides efficient storage of revisions using a
   7.124 -<emphasis>delta</emphasis> mechanism.  Instead of storing a complete copy of a file
   7.125 -for each revision, it stores the changes needed to transform an older
   7.126 -revision into the new revision.  For many kinds of file data, these
   7.127 -deltas are typically a fraction of a percent of the size of a full
   7.128 -copy of a file.
   7.129 -</para>
   7.130 -
   7.131 -<para>Some obsolete revision control systems can only work with deltas of
   7.132 -text files.  They must either store binary files as complete snapshots
   7.133 -or encoded into a text representation, both of which are wasteful
   7.134 -approaches.  Mercurial can efficiently handle deltas of files with
   7.135 -arbitrary binary contents; it doesn't need to treat text as special.
   7.136 -</para>
   7.137 -
   7.138 -</sect2>
   7.139 -<sect2>
   7.140 -<title>Safe operation</title>
   7.141 -<para>\label{sec:concepts:txn}
   7.142 -</para>
   7.143 -
   7.144 -<para>Mercurial only ever <emphasis>appends</emphasis> data to the end of a revlog file.
   7.145 -It never modifies a section of a file after it has written it.  This
   7.146 -is both more robust and efficient than schemes that need to modify or
   7.147 -rewrite data.
   7.148 -</para>
   7.149 -
   7.150 -<para>In addition, Mercurial treats every write as part of a
   7.151 -<emphasis>transaction</emphasis> that can span a number of files.  A transaction is
   7.152 -<emphasis>atomic</emphasis>: either the entire transaction succeeds and its effects
   7.153 -are all visible to readers in one go, or the whole thing is undone.
   7.154 -This guarantee of atomicity means that if you're running two copies of
   7.155 -Mercurial, where one is reading data and one is writing it, the reader
   7.156 -will never see a partially written result that might confuse it.
   7.157 -</para>
   7.158 -
   7.159 -<para>The fact that Mercurial only appends to files makes it easier to
   7.160 -provide this transactional guarantee.  The easier it is to do stuff
   7.161 -like this, the more confident you should be that it's done correctly.
   7.162 -</para>
   7.163 -
   7.164 -</sect2>
   7.165 -<sect2>
   7.166 -<title>Fast retrieval</title>
   7.167 -
   7.168 -<para>Mercurial cleverly avoids a pitfall common to all earlier
   7.169 -revision control systems: the problem of <emphasis>inefficient retrieval</emphasis>.
   7.170 -Most revision control systems store the contents of a revision as an
   7.171 -incremental series of modifications against a <quote>snapshot</quote>.  To
   7.172 -reconstruct a specific revision, you must first read the snapshot, and
   7.173 -then every one of the revisions between the snapshot and your target
   7.174 -revision.  The more history that a file accumulates, the more
   7.175 -revisions you must read, hence the longer it takes to reconstruct a
   7.176 -particular revision.
   7.177 -</para>
   7.178 -
   7.179 -<informalfigure>
   7.180 -
   7.181 -<para>  <mediaobject><imageobject><imagedata fileref="snapshot"/></imageobject><textobject><phrase>XXX add text</phrase></textobject></mediaobject>
   7.182 -  <caption><para>Snapshot of a revlog, with incremental deltas</para></caption>
   7.183 -  \label{fig:concepts:snapshot}
   7.184 -</para>
   7.185 -</informalfigure>
   7.186 -
   7.187 -<para>The innovation that Mercurial applies to this problem is simple but
   7.188 -effective.  Once the cumulative amount of delta information stored
   7.189 -since the last snapshot exceeds a fixed threshold, it stores a new
   7.190 -snapshot (compressed, of course), instead of another delta.  This
   7.191 -makes it possible to reconstruct <emphasis>any</emphasis> revision of a file
   7.192 -quickly.  This approach works so well that it has since been copied by
   7.193 -several other revision control systems.
   7.194 -</para>
   7.195 -
   7.196 -<para>Figure <xref linkend="fig:concepts:snapshot"/> illustrates the idea.  In an entry
   7.197 -in a revlog's index file, Mercurial stores the range of entries from
   7.198 -the data file that it must read to reconstruct a particular revision.
   7.199 -</para>
   7.200 -
   7.201 -<sect3>
   7.202 -<title>Aside: the influence of video compression</title>
   7.203 -
   7.204 -<para>If you're familiar with video compression or have ever watched a TV
   7.205 -feed through a digital cable or satellite service, you may know that
   7.206 -most video compression schemes store each frame of video as a delta
   7.207 -against its predecessor frame.  In addition, these schemes use
   7.208 -<quote>lossy</quote> compression techniques to increase the compression ratio, so
   7.209 -visual errors accumulate over the course of a number of inter-frame
   7.210 -deltas.
   7.211 -</para>
   7.212 -
   7.213 -<para>Because it's possible for a video stream to <quote>drop out</quote> occasionally
   7.214 -due to signal glitches, and to limit the accumulation of artefacts
   7.215 -introduced by the lossy compression process, video encoders
   7.216 -periodically insert a complete frame (called a <quote>key frame</quote>) into the
   7.217 -video stream; the next delta is generated against that frame.  This
   7.218 -means that if the video signal gets interrupted, it will resume once
   7.219 -the next key frame is received.  Also, the accumulation of encoding
   7.220 -errors restarts anew with each key frame.
   7.221 -</para>
   7.222 -
   7.223 -</sect3>
   7.224 -</sect2>
   7.225 -<sect2>
   7.226 -<title>Identification and strong integrity</title>
   7.227 -
   7.228 -<para>Along with delta or snapshot information, a revlog entry contains a
   7.229 -cryptographic hash of the data that it represents.  This makes it
   7.230 -difficult to forge the contents of a revision, and easy to detect
   7.231 -accidental corruption.
   7.232 -</para>
   7.233 -
   7.234 -<para>Hashes provide more than a mere check against corruption; they are
   7.235 -used as the identifiers for revisions.  The changeset identification
   7.236 -hashes that you see as an end user are from revisions of the
   7.237 -changelog.  Although filelogs and the manifest also use hashes,
   7.238 -Mercurial only uses these behind the scenes.
   7.239 -</para>
   7.240 -
   7.241 -<para>Mercurial verifies that hashes are correct when it retrieves file
   7.242 -revisions and when it pulls changes from another repository.  If it
   7.243 -encounters an integrity problem, it will complain and stop whatever
   7.244 -it's doing.
   7.245 -</para>
   7.246 -
   7.247 -<para>In addition to the effect it has on retrieval efficiency, Mercurial's
   7.248 -use of periodic snapshots makes it more robust against partial data
   7.249 -corruption.  If a revlog becomes partly corrupted due to a hardware
   7.250 -error or system bug, it's often possible to reconstruct some or most
   7.251 -revisions from the uncorrupted sections of the revlog, both before and
   7.252 -after the corrupted section.  This would not be possible with a
   7.253 -delta-only storage model.
   7.254 -</para>
   7.255 -
   7.256 -<para>\section{Revision history, branching,
   7.257 -  and merging}
   7.258 -</para>
   7.259 -
   7.260 -<para>Every entry in a Mercurial revlog knows the identity of its immediate
   7.261 -ancestor revision, usually referred to as its <emphasis>parent</emphasis>.  In fact,
   7.262 -a revision contains room for not one parent, but two.  Mercurial uses
   7.263 -a special hash, called the <quote>null ID</quote>, to represent the idea <quote>there
   7.264 -is no parent here</quote>.  This hash is simply a string of zeroes.
   7.265 -</para>
   7.266 -
   7.267 -<para>In figure <xref linkend="fig:concepts:revlog"/>, you can see an example of the
   7.268 -conceptual structure of a revlog.  Filelogs, manifests, and changelogs
   7.269 -all have this same structure; they differ only in the kind of data
   7.270 -stored in each delta or snapshot.
   7.271 -</para>
   7.272 -
   7.273 -<para>The first revision in a revlog (at the bottom of the image) has the
   7.274 -null ID in both of its parent slots.  For a <quote>normal</quote> revision, its
   7.275 -first parent slot contains the ID of its parent revision, and its
   7.276 -second contains the null ID, indicating that the revision has only one
   7.277 -real parent.  Any two revisions that have the same parent ID are
   7.278 -branches.  A revision that represents a merge between branches has two
   7.279 -normal revision IDs in its parent slots.
   7.280 -</para>
   7.281 -
   7.282 -<informalfigure>
   7.283 -
   7.284 -<para>  <mediaobject><imageobject><imagedata fileref="revlog"/></imageobject><textobject><phrase>XXX add text</phrase></textobject></mediaobject>
   7.285 -  \caption{}
   7.286 -  \label{fig:concepts:revlog}
   7.287 -</para>
   7.288 -</informalfigure>
   7.289 -
   7.290 -</sect2>
   7.291 -</sect1>
   7.292 -<sect1>
   7.293 -<title>The working directory</title>
   7.294 -
   7.295 -<para>In the working directory, Mercurial stores a snapshot of the files
   7.296 -from the repository as of a particular changeset.
   7.297 -</para>
   7.298 -
   7.299 -<para>The working directory <quote>knows</quote> which changeset it contains.  When you
   7.300 -update the working directory to contain a particular changeset,
   7.301 -Mercurial looks up the appropriate revision of the manifest to find
   7.302 -out which files it was tracking at the time that changeset was
   7.303 -committed, and which revision of each file was then current.  It then
   7.304 -recreates a copy of each of those files, with the same contents it had
   7.305 -when the changeset was committed.
   7.306 -</para>
   7.307 -
   7.308 -<para>The <emphasis>dirstate</emphasis> contains Mercurial's knowledge of the working
   7.309 -directory.  This details which changeset the working directory is
   7.310 -updated to, and all of the files that Mercurial is tracking in the
   7.311 -working directory.
   7.312 -</para>
   7.313 -
   7.314 -<para>Just as a revision of a revlog has room for two parents, so that it
   7.315 -can represent either a normal revision (with one parent) or a merge of
   7.316 -two earlier revisions, the dirstate has slots for two parents.  When
   7.317 -you use the <command role="hg-cmd">hg update</command> command, the changeset that you update to
   7.318 -is stored in the <quote>first parent</quote> slot, and the null ID in the second.
   7.319 -When you <command role="hg-cmd">hg merge</command> with another changeset, the first parent
   7.320 -remains unchanged, and the second parent is filled in with the
   7.321 -changeset you're merging with.  The <command role="hg-cmd">hg parents</command> command tells you
   7.322 -what the parents of the dirstate are.
   7.323 -</para>
   7.324 -
   7.325 -<sect2>
   7.326 -<title>What happens when you commit</title>
   7.327 -
   7.328 -<para>The dirstate stores parent information for more than just book-keeping
   7.329 -purposes.  Mercurial uses the parents of the dirstate as \emph{the
   7.330 -  parents of a new changeset} when you perform a commit.
   7.331 -</para>
   7.332 -
   7.333 -<informalfigure>
   7.334 -
   7.335 -<para>  <mediaobject><imageobject><imagedata fileref="wdir"/></imageobject><textobject><phrase>XXX add text</phrase></textobject></mediaobject>
   7.336 -  <caption><para>The working directory can have two parents</para></caption>
   7.337 -  \label{fig:concepts:wdir}
   7.338 -</para>
   7.339 -</informalfigure>
   7.340 -
   7.341 -<para>Figure <xref linkend="fig:concepts:wdir"/> shows the normal state of the working
   7.342 -directory, where it has a single changeset as parent.  That changeset
   7.343 -is the <emphasis>tip</emphasis>, the newest changeset in the repository that has no
   7.344 -children.
   7.345 -</para>
   7.346 -
   7.347 -<informalfigure>
   7.348 -
   7.349 -<para>  <mediaobject><imageobject><imagedata fileref="wdir-after-commit"/></imageobject><textobject><phrase>XXX add text</phrase></textobject></mediaobject>
   7.350 -  <caption><para>The working directory gains new parents after a commit</para></caption>
   7.351 -  \label{fig:concepts:wdir-after-commit}
   7.352 -</para>
   7.353 -</informalfigure>
   7.354 -
   7.355 -<para>It's useful to think of the working directory as <quote>the changeset I'm
   7.356 -about to commit</quote>.  Any files that you tell Mercurial that you've
   7.357 -added, removed, renamed, or copied will be reflected in that
   7.358 -changeset, as will modifications to any files that Mercurial is
   7.359 -already tracking; the new changeset will have the parents of the
   7.360 -working directory as its parents.
   7.361 -</para>
   7.362 -
   7.363 -<para>After a commit, Mercurial will update the parents of the working
   7.364 -directory, so that the first parent is the ID of the new changeset,
   7.365 -and the second is the null ID.  This is shown in
   7.366 -figure <xref linkend="fig:concepts:wdir-after-commit"/>.  Mercurial doesn't touch
   7.367 -any of the files in the working directory when you commit; it just
   7.368 -modifies the dirstate to note its new parents.
   7.369 -</para>
   7.370 -
   7.371 -</sect2>
   7.372 -<sect2>
   7.373 -<title>Creating a new head</title>
   7.374 -
   7.375 -<para>It's perfectly normal to update the working directory to a changeset
   7.376 -other than the current tip.  For example, you might want to know what
   7.377 -your project looked like last Tuesday, or you could be looking through
   7.378 -changesets to see which one introduced a bug.  In cases like this, the
   7.379 -natural thing to do is update the working directory to the changeset
   7.380 -you're interested in, and then examine the files in the working
   7.381 -directory directly to see their contents as they were when you
   7.382 -committed that changeset.  The effect of this is shown in
   7.383 -figure <xref linkend="fig:concepts:wdir-pre-branch"/>.
   7.384 -</para>
   7.385 -
   7.386 -<informalfigure>
   7.387 -
   7.388 -<para>  <mediaobject><imageobject><imagedata fileref="wdir-pre-branch"/></imageobject><textobject><phrase>XXX add text</phrase></textobject></mediaobject>
   7.389 -  <caption><para>The working directory, updated to an older changeset</para></caption>
   7.390 -  \label{fig:concepts:wdir-pre-branch}
   7.391 -</para>
   7.392 -</informalfigure>
   7.393 -
   7.394 -<para>Having updated the working directory to an older changeset, what
   7.395 -happens if you make some changes, and then commit?  Mercurial behaves
   7.396 -in the same way as I outlined above.  The parents of the working
   7.397 -directory become the parents of the new changeset.  This new changeset
   7.398 -has no children, so it becomes the new tip.  And the repository now
   7.399 -contains two changesets that have no children; we call these
   7.400 -<emphasis>heads</emphasis>.  You can see the structure that this creates in
   7.401 -figure <xref linkend="fig:concepts:wdir-branch"/>.
   7.402 -</para>
   7.403 -
   7.404 -<informalfigure>
   7.405 -
   7.406 -<para>  <mediaobject><imageobject><imagedata fileref="wdir-branch"/></imageobject><textobject><phrase>XXX add text</phrase></textobject></mediaobject>
   7.407 -  <caption><para>After a commit made while synced to an older changeset</para></caption>
   7.408 -  \label{fig:concepts:wdir-branch}
   7.409 -</para>
   7.410 -</informalfigure>
   7.411 -
   7.412 -<note>
   7.413 -<para>  If you're new to Mercurial, you should keep in mind a common
   7.414 -  <quote>error</quote>, which is to use the <command role="hg-cmd">hg pull</command> command without any
   7.415 -  options.  By default, the <command role="hg-cmd">hg pull</command> command <emphasis>does not</emphasis>
   7.416 -  update the working directory, so you'll bring new changesets into
   7.417 -  your repository, but the working directory will stay synced at the
   7.418 -  same changeset as before the pull.  If you make some changes and
   7.419 -  commit afterwards, you'll thus create a new head, because your
   7.420 -  working directory isn't synced to whatever the current tip is.
   7.421 -</para>
   7.422 -
   7.423 -<para>  I put the word <quote>error</quote> in quotes because all that you need to do
   7.424 -  to rectify this situation is <command role="hg-cmd">hg merge</command>, then <command role="hg-cmd">hg commit</command>.  In
   7.425 -  other words, this almost never has negative consequences; it just
   7.426 -  surprises people.  I'll discuss other ways to avoid this behaviour,
   7.427 -  and why Mercurial behaves in this initially surprising way, later
   7.428 -  on.
   7.429 -</para>
   7.430 -</note>
   7.431 -
   7.432 -</sect2>
   7.433 -<sect2>
   7.434 -<title>Merging heads</title>
   7.435 -
   7.436 -<para>When you run the <command role="hg-cmd">hg merge</command> command, Mercurial leaves the first
   7.437 -parent of the working directory unchanged, and sets the second parent
   7.438 -to the changeset you're merging with, as shown in
   7.439 -figure <xref linkend="fig:concepts:wdir-merge"/>.
   7.440 -</para>
   7.441 -
   7.442 -<informalfigure>
   7.443 -
   7.444 -<para>  <mediaobject><imageobject><imagedata fileref="wdir-merge"/></imageobject><textobject><phrase>XXX add text</phrase></textobject></mediaobject>
   7.445 -  <caption><para>Merging two heads</para></caption>
   7.446 -  \label{fig:concepts:wdir-merge}
   7.447 -</para>
   7.448 -</informalfigure>
   7.449 -
   7.450 -<para>Mercurial also has to modify the working directory, to merge the files
   7.451 -managed in the two changesets.  Simplified a little, the merging
   7.452 -process goes like this, for every file in the manifests of both
   7.453 -changesets.
   7.454 -</para>
   7.455 -<itemizedlist>
   7.456 -<listitem><para>If neither changeset has modified a file, do nothing with that
   7.457 -  file.
   7.458 -</para>
   7.459 -</listitem>
   7.460 -<listitem><para>If one changeset has modified a file, and the other hasn't,
   7.461 -  create the modified copy of the file in the working directory.
   7.462 -</para>
   7.463 -</listitem>
   7.464 -<listitem><para>If one changeset has removed a file, and the other hasn't (or
   7.465 -  has also deleted it), delete the file from the working directory.
   7.466 -</para>
   7.467 -</listitem>
   7.468 -<listitem><para>If one changeset has removed a file, but the other has modified
   7.469 -  the file, ask the user what to do: keep the modified file, or remove
   7.470 -  it?
   7.471 -</para>
   7.472 -</listitem>
   7.473 -<listitem><para>If both changesets have modified a file, invoke an external
   7.474 -  merge program to choose the new contents for the merged file.  This
   7.475 -  may require input from the user.
   7.476 -</para>
   7.477 -</listitem>
   7.478 -<listitem><para>If one changeset has modified a file, and the other has renamed
   7.479 -  or copied the file, make sure that the changes follow the new name
   7.480 -  of the file.
   7.481 -</para>
   7.482 -</listitem></itemizedlist>
   7.483 -<para>There are more details&emdash;merging has plenty of corner cases&emdash;but
   7.484 -these are the most common choices that are involved in a merge.  As
   7.485 -you can see, most cases are completely automatic, and indeed most
   7.486 -merges finish automatically, without requiring your input to resolve
   7.487 -any conflicts.
   7.488 -</para>
   7.489 -
   7.490 -<para>When you're thinking about what happens when you commit after a merge,
   7.491 -once again the working directory is <quote>the changeset I'm about to
   7.492 -commit</quote>.  After the <command role="hg-cmd">hg merge</command> command completes, the working
   7.493 -directory has two parents; these will become the parents of the new
   7.494 -changeset.
   7.495 -</para>
   7.496 -
   7.497 -<para>Mercurial lets you perform multiple merges, but you must commit the
   7.498 -results of each individual merge as you go.  This is necessary because
   7.499 -Mercurial only tracks two parents for both revisions and the working
   7.500 -directory.  While it would be technically possible to merge multiple
   7.501 -changesets at once, the prospect of user confusion and making a
   7.502 -terrible mess of a merge immediately becomes overwhelming.
   7.503 -</para>
   7.504 -
   7.505 -</sect2>
   7.506 -</sect1>
   7.507 -<sect1>
   7.508 -<title>Other interesting design features</title>
   7.509 -
   7.510 -<para>In the sections above, I've tried to highlight some of the most
   7.511 -important aspects of Mercurial's design, to illustrate that it pays
   7.512 -careful attention to reliability and performance.  However, the
   7.513 -attention to detail doesn't stop there.  There are a number of other
   7.514 -aspects of Mercurial's construction that I personally find
   7.515 -interesting.  I'll detail a few of them here, separate from the <quote>big
   7.516 -ticket</quote> items above, so that if you're interested, you can gain a
   7.517 -better idea of the amount of thinking that goes into a well-designed
   7.518 -system.
   7.519 -</para>
   7.520 -
   7.521 -<sect2>
   7.522 -<title>Clever compression</title>
   7.523 -
   7.524 -<para>When appropriate, Mercurial will store both snapshots and deltas in
   7.525 -compressed form.  It does this by always <emphasis>trying to</emphasis> compress a
   7.526 -snapshot or delta, but only storing the compressed version if it's
   7.527 -smaller than the uncompressed version.
   7.528 -</para>
   7.529 -
   7.530 -<para>This means that Mercurial does <quote>the right thing</quote> when storing a file
   7.531 -whose native form is compressed, such as a <literal>zip</literal> archive or a
   7.532 -JPEG image.  When these types of files are compressed a second time,
   7.533 -the resulting file is usually bigger than the once-compressed form,
   7.534 -and so Mercurial will store the plain <literal>zip</literal> or JPEG.
   7.535 -</para>
   7.536 -
   7.537 -<para>Deltas between revisions of a compressed file are usually larger than
   7.538 -snapshots of the file, and Mercurial again does <quote>the right thing</quote> in
   7.539 -these cases.  It finds that such a delta exceeds the threshold at
   7.540 -which it should store a complete snapshot of the file, so it stores
   7.541 -the snapshot, again saving space compared to a naive delta-only
   7.542 -approach.
   7.543 -</para>
   7.544 -
   7.545 -<sect3>
   7.546 -<title>Network recompression</title>
   7.547 -
   7.548 -<para>When storing revisions on disk, Mercurial uses the <quote>deflate</quote>
   7.549 -compression algorithm (the same one used by the popular <literal>zip</literal>
   7.550 -archive format), which balances good speed with a respectable
   7.551 -compression ratio.  However, when transmitting revision data over a
   7.552 -network connection, Mercurial uncompresses the compressed revision
   7.553 -data.
   7.554 -</para>
   7.555 -
   7.556 -<para>If the connection is over HTTP, Mercurial recompresses the entire
   7.557 -stream of data using a compression algorithm that gives a better
   7.558 -compression ratio (the Burrows-Wheeler algorithm from the widely used
   7.559 -<literal>bzip2</literal> compression package).  This combination of algorithm
   7.560 -and compression of the entire stream (instead of a revision at a time)
   7.561 -substantially reduces the number of bytes to be transferred, yielding
   7.562 -better network performance over almost all kinds of network.
   7.563 -</para>
   7.564 -
   7.565 -<para>(If the connection is over <command>ssh</command>, Mercurial <emphasis>doesn't</emphasis>
   7.566 -recompress the stream, because <command>ssh</command> can already do this
   7.567 -itself.)
   7.568 -</para>
   7.569 -
   7.570 -</sect3>
   7.571 -</sect2>
   7.572 -<sect2>
   7.573 -<title>Read/write ordering and atomicity</title>
   7.574 -
   7.575 -<para>Appending to files isn't the whole story when it comes to guaranteeing
   7.576 -that a reader won't see a partial write.  If you recall
   7.577 -figure <xref linkend="fig:concepts:metadata"/>, revisions in the changelog point to
   7.578 -revisions in the manifest, and revisions in the manifest point to
   7.579 -revisions in filelogs.  This hierarchy is deliberate.
   7.580 -</para>
   7.581 -
   7.582 -<para>A writer starts a transaction by writing filelog and manifest data,
   7.583 -and doesn't write any changelog data until those are finished.  A
   7.584 -reader starts by reading changelog data, then manifest data, followed
   7.585 -by filelog data.
   7.586 -</para>
   7.587 -
   7.588 -<para>Since the writer has always finished writing filelog and manifest data
   7.589 -before it writes to the changelog, a reader will never read a pointer
   7.590 -to a partially written manifest revision from the changelog, and it will
   7.591 -never read a pointer to a partially written filelog revision from the
   7.592 -manifest.
   7.593 -</para>
   7.594 -
   7.595 -</sect2>
   7.596 -<sect2>
   7.597 -<title>Concurrent access</title>
   7.598 -
   7.599 -<para>The read/write ordering and atomicity guarantees mean that Mercurial
   7.600 -never needs to <emphasis>lock</emphasis> a repository when it's reading data, even
   7.601 -if the repository is being written to while the read is occurring.
   7.602 -This has a big effect on scalability; you can have an arbitrary number
   7.603 -of Mercurial processes safely reading data from a repository safely
   7.604 -all at once, no matter whether it's being written to or not.
   7.605 -</para>
   7.606 -
   7.607 -<para>The lockless nature of reading means that if you're sharing a
   7.608 -repository on a multi-user system, you don't need to grant other local
   7.609 -users permission to <emphasis>write</emphasis> to your repository in order for them
   7.610 -to be able to clone it or pull changes from it; they only need
   7.611 -<emphasis>read</emphasis> permission.  (This is <emphasis>not</emphasis> a common feature among
   7.612 -revision control systems, so don't take it for granted!  Most require
   7.613 -readers to be able to lock a repository to access it safely, and this
   7.614 -requires write permission on at least one directory, which of course
   7.615 -makes for all kinds of nasty and annoying security and administrative
   7.616 -problems.)
   7.617 -</para>
   7.618 -
   7.619 -<para>Mercurial uses locks to ensure that only one process can write to a
   7.620 -repository at a time (the locking mechanism is safe even over
   7.621 -filesystems that are notoriously hostile to locking, such as NFS).  If
   7.622 -a repository is locked, a writer will wait for a while to retry if the
   7.623 -repository becomes unlocked, but if the repository remains locked for
   7.624 -too long, the process attempting to write will time out after a while.
   7.625 -This means that your daily automated scripts won't get stuck forever
   7.626 -and pile up if a system crashes unnoticed, for example.  (Yes, the
   7.627 -timeout is configurable, from zero to infinity.)
   7.628 -</para>
   7.629 -
   7.630 -<sect3>
   7.631 -<title>Safe dirstate access</title>
   7.632 -
   7.633 -<para>As with revision data, Mercurial doesn't take a lock to read the
   7.634 -dirstate file; it does acquire a lock to write it.  To avoid the
   7.635 -possibility of reading a partially written copy of the dirstate file,
   7.636 -Mercurial writes to a file with a unique name in the same directory as
   7.637 -the dirstate file, then renames the temporary file atomically to
   7.638 -<filename>dirstate</filename>.  The file named <filename>dirstate</filename> is thus
   7.639 -guaranteed to be complete, not partially written.
   7.640 -</para>
   7.641 -
   7.642 -</sect3>
   7.643 -</sect2>
   7.644 -<sect2>
   7.645 -<title>Avoiding seeks</title>
   7.646 -
   7.647 -<para>Critical to Mercurial's performance is the avoidance of seeks of the
   7.648 -disk head, since any seek is far more expensive than even a
   7.649 -comparatively large read operation.
   7.650 -</para>
   7.651 -
   7.652 -<para>This is why, for example, the dirstate is stored in a single file.  If
   7.653 -there were a dirstate file per directory that Mercurial tracked, the
   7.654 -disk would seek once per directory.  Instead, Mercurial reads the
   7.655 -entire single dirstate file in one step.
   7.656 -</para>
   7.657 -
   7.658 -<para>Mercurial also uses a <quote>copy on write</quote> scheme when cloning a
   7.659 -repository on local storage.  Instead of copying every revlog file
   7.660 -from the old repository into the new repository, it makes a <quote>hard
   7.661 -link</quote>, which is a shorthand way to say <quote>these two names point to the
   7.662 -same file</quote>.  When Mercurial is about to write to one of a revlog's
   7.663 -files, it checks to see if the number of names pointing at the file is
   7.664 -greater than one.  If it is, more than one repository is using the
   7.665 -file, so Mercurial makes a new copy of the file that is private to
   7.666 -this repository.
   7.667 -</para>
   7.668 -
   7.669 -<para>A few revision control developers have pointed out that this idea of
   7.670 -making a complete private copy of a file is not very efficient in its
   7.671 -use of storage.  While this is true, storage is cheap, and this method
   7.672 -gives the highest performance while deferring most book-keeping to the
   7.673 -operating system.  An alternative scheme would most likely reduce
   7.674 -performance and increase the complexity of the software, each of which
   7.675 -is much more important to the <quote>feel</quote> of day-to-day use.
   7.676 -</para>
   7.677 -
   7.678 -</sect2>
   7.679 -<sect2>
   7.680 -<title>Other contents of the dirstate</title>
   7.681 -
   7.682 -<para>Because Mercurial doesn't force you to tell it when you're modifying a
   7.683 -file, it uses the dirstate to store some extra information so it can
   7.684 -determine efficiently whether you have modified a file.  For each file
   7.685 -in the working directory, it stores the time that it last modified the
   7.686 -file itself, and the size of the file at that time.
   7.687 -</para>
   7.688 -
   7.689 -<para>When you explicitly <command role="hg-cmd">hg add</command>, <command role="hg-cmd">hg remove</command>, <command role="hg-cmd">hg rename</command> or
   7.690 -<command role="hg-cmd">hg copy</command> files, Mercurial updates the dirstate so that it knows
   7.691 -what to do with those files when you commit.
   7.692 -</para>
   7.693 -
   7.694 -<para>When Mercurial is checking the states of files in the working
   7.695 -directory, it first checks a file's modification time.  If that has
   7.696 -not changed, the file must not have been modified.  If the file's size
   7.697 -has changed, the file must have been modified.  If the modification
   7.698 -time has changed, but the size has not, only then does Mercurial need
   7.699 -to read the actual contents of the file to see if they've changed.
   7.700 -Storing these few extra pieces of information dramatically reduces the
   7.701 -amount of data that Mercurial needs to read, which yields large
   7.702 -performance improvements compared to other revision control systems.
   7.703 -</para>
   7.704 -
   7.705 -</sect2>
   7.706 -</sect1>
   7.707 +<chapter id="chap:concepts">
   7.708 +  <?dbhtml filename="behind-the-scenes.html"?>
   7.709 +  <title>Derrière le décor</title>
   7.710 +  
   7.711 +  <para id="x_2e8">À la différence de beaucoup d'outils de gestion de versions,
   7.712 +    les concepts sur lesquels se base Mercurial sont assez simples pour
   7.713 +    qu'il soit facile de comprendre comment le logiciel fonctionne.
   7.714 +    Bien que leur connaissance ne soit pas nécéssaire, je trouve utile
   7.715 +    d'avoir un <quote>modèle mental</quote> de ce qui se passe.</para>
   7.716 +
   7.717 +  <para id="x_2e9">En effet, cette compréhension m'apporte la confiance que
   7.718 +    Mercurial a été développé avec soin pour être à la fois
   7.719 +    <emphasis>sûr</emphasis> et <emphasis>efficace</emphasis>. De surcroît,
   7.720 +    si il m'est facile de garder en tête ce que le logiciel fait lorsque
   7.721 +    j'accompli des tâches de révision, j'aurai moins de risques d'être
   7.722 +    surpris par son comportement.</para>
   7.723 +
   7.724 +  <para id="x_2ea">Dans ce chapitre, nous décrirons tout d'abord les concepts
   7.725 +    essentiels de l'architecture de Mercurial, pour ensuite discuter quelques
   7.726 +    uns des détails intéressants de son implémentation.</para>
   7.727 +
   7.728 +  <sect1>
   7.729 +    <title>Conservation de l'historique sous Mercurial</title>
   7.730 +    <sect2>
   7.731 +      <title>Suivi de l'historique pour un seul fichier</title>
   7.732 +      
   7.733 +      <para id="x_2eb">Lorsque Mercurial effectue un suivi des modifications
   7.734 +        faites à un fichier, il conserve l'historique pour ce fichier dans un
   7.735 +        <emphasis>filelog</emphasis> sous forme de métadonnées. Chaque entrée
   7.736 +        dans le filelog contient assez d'informations pour reconstituer une
   7.737 +        révision du fichier correspondant. Les filelogs sont des fichiers
   7.738 +        stockés dans le répertoire  <filename role="special"
   7.739 +          class="directory">.hg/store/data</filename>. Un filelog contient
   7.740 +        des informations de deux types: les données de révision, et un index
   7.741 +        pour permettre à Mercurial une recherche efficace d'une révision
   7.742 +        donnée.</para>
   7.743 +
   7.744 +      <para id="x_2ec">Lorsqu'un fichier devient trop gros ou a un long
   7.745 +        historique, son filelog se voit stocker dans un fichier de données
   7.746 +        (avec un suffixe <quote><literal>.d</literal></quote>) et un fichier
   7.747 +        index (avec un suffixe<quote><literal>.i</literal></quote>)
   7.748 +        distincts. La relation entre un fichier dans le répertoire de travail
   7.749 +        et le  filelog couvrant le suivi de son historique dans le dépôt est
   7.750 +        illustré à la figure <xref linkend="fig:concepts:filelog"/>.</para>
   7.751 +
   7.752 +      <figure id="fig:concepts:filelog">
   7.753 +        <title>Relations entre les fichiers dans le répertoire de travail et
   7.754 +        leurs filelogs dans le dépôt</title> 
   7.755 +        <mediaobject> <imageobject><imagedata
   7.756 +              fileref="figs/filelog.png"/></imageobject>
   7.757 +          <textobject><phrase>XXX add text</phrase></textobject>
   7.758 +        </mediaobject> </figure>
   7.759 +
   7.760 +    </sect2>
   7.761 +    <sect2>
   7.762 +      <title>Gestion des fichiers suivis</title>
   7.763 +      
   7.764 +      <para id="x_2ee">Mercurial a recours à une structure nommée
   7.765 +        <emphasis>manifest</emphasis> pour rassembler les informations sur
   7.766 +        les fichiers dont il gère le suivi. Chaque entrée dans ce manifest
   7.767 +        contient des informations sur les fichiers présents dans une révision
   7.768 +        donnée. Une entrée store la liste des fichiers faisant partie de la
   7.769 +        révision, la version de chaque fichier, et quelques autres
   7.770 +        métadonnées sur ces fichiers.</para>
   7.771 +
   7.772 +    </sect2>
   7.773 +    <sect2>
   7.774 +      <title>Recording changeset information</title>
   7.775 +
   7.776 +      <para id="x_2ef">The <emphasis>changelog</emphasis> contains
   7.777 +        information about each changeset.  Each revision records who
   7.778 +        committed a change, the changeset comment, other pieces of
   7.779 +        changeset-related information, and the revision of the manifest to
   7.780 +        use.</para>
   7.781 +
   7.782 +    </sect2>
   7.783 +    <sect2>
   7.784 +      <title>Relationships between revisions</title>
   7.785 +
   7.786 +      <para id="x_2f0">Within a changelog, a manifest, or a filelog, each
   7.787 +	revision stores a pointer to its immediate parent (or to its
   7.788 +	two parents, if it's a merge revision).  As I mentioned above,
   7.789 +	there are also relationships between revisions
   7.790 +	<emphasis>across</emphasis> these structures, and they are
   7.791 +	hierarchical in nature.</para>
   7.792 +
   7.793 +      <para id="x_2f1">For every changeset in a repository, there is exactly one
   7.794 +	revision stored in the changelog.  Each revision of the
   7.795 +	changelog contains a pointer to a single revision of the
   7.796 +	manifest.  A revision of the manifest stores a pointer to a
   7.797 +	single revision of each filelog tracked when that changeset
   7.798 +	was created.  These relationships are illustrated in
   7.799 +	<xref linkend="fig:concepts:metadata"/>.</para>
   7.800 +
   7.801 +      <figure id="fig:concepts:metadata">
   7.802 +	<title>Metadata relationships</title>
   7.803 +	<mediaobject>
   7.804 +	  <imageobject><imagedata fileref="figs/metadata.png"/></imageobject>
   7.805 +	  <textobject><phrase>XXX add text</phrase></textobject>
   7.806 +	</mediaobject>
   7.807 +      </figure>
   7.808 +
   7.809 +      <para id="x_2f3">As the illustration shows, there is
   7.810 +	<emphasis>not</emphasis> a <quote>one to one</quote>
   7.811 +	relationship between revisions in the changelog, manifest, or
   7.812 +	filelog. If a file that
   7.813 +	Mercurial tracks hasn't changed between two changesets, the
   7.814 +	entry for that file in the two revisions of the manifest will
   7.815 +	point to the same revision of its filelog<footnote>
   7.816 +	  <para id="x_725">It is possible (though unusual) for the manifest to
   7.817 +	    remain the same between two changesets, in which case the
   7.818 +	    changelog entries for those changesets will point to the
   7.819 +	    same revision of the manifest.</para>
   7.820 +	</footnote>.</para>
   7.821 +
   7.822 +    </sect2>
   7.823 +  </sect1>
   7.824 +  <sect1>
   7.825 +    <title>Safe, efficient storage</title>
   7.826 +
   7.827 +    <para id="x_2f4">The underpinnings of changelogs, manifests, and filelogs are
   7.828 +      provided by a single structure called the
   7.829 +      <emphasis>revlog</emphasis>.</para>
   7.830 +
   7.831 +    <sect2>
   7.832 +      <title>Efficient storage</title>
   7.833 +
   7.834 +      <para id="x_2f5">The revlog provides efficient storage of revisions using a
   7.835 +	<emphasis>delta</emphasis> mechanism.  Instead of storing a
   7.836 +	complete copy of a file for each revision, it stores the
   7.837 +	changes needed to transform an older revision into the new
   7.838 +	revision.  For many kinds of file data, these deltas are
   7.839 +	typically a fraction of a percent of the size of a full copy
   7.840 +	of a file.</para>
   7.841 +
   7.842 +      <para id="x_2f6">Some obsolete revision control systems can only work with
   7.843 +	deltas of text files.  They must either store binary files as
   7.844 +	complete snapshots or encoded into a text representation, both
   7.845 +	of which are wasteful approaches.  Mercurial can efficiently
   7.846 +	handle deltas of files with arbitrary binary contents; it
   7.847 +	doesn't need to treat text as special.</para>
   7.848 +
   7.849 +    </sect2>
   7.850 +    <sect2 id="sec:concepts:txn">
   7.851 +      <title>Safe operation</title>
   7.852 +
   7.853 +      <para id="x_2f7">Mercurial only ever <emphasis>appends</emphasis> data to
   7.854 +	the end of a revlog file. It never modifies a section of a
   7.855 +	file after it has written it.  This is both more robust and
   7.856 +	efficient than schemes that need to modify or rewrite
   7.857 +	data.</para>
   7.858 +
   7.859 +      <para id="x_2f8">In addition, Mercurial treats every write as part of a
   7.860 +	<emphasis>transaction</emphasis> that can span a number of
   7.861 +	files.  A transaction is <emphasis>atomic</emphasis>: either
   7.862 +	the entire transaction succeeds and its effects are all
   7.863 +	visible to readers in one go, or the whole thing is undone.
   7.864 +	This guarantee of atomicity means that if you're running two
   7.865 +	copies of Mercurial, where one is reading data and one is
   7.866 +	writing it, the reader will never see a partially written
   7.867 +	result that might confuse it.</para>
   7.868 +
   7.869 +      <para id="x_2f9">The fact that Mercurial only appends to files makes it
   7.870 +	easier to provide this transactional guarantee.  The easier it
   7.871 +	is to do stuff like this, the more confident you should be
   7.872 +	that it's done correctly.</para>
   7.873 +
   7.874 +    </sect2>
   7.875 +    <sect2>
   7.876 +      <title>Fast retrieval</title>
   7.877 +
   7.878 +      <para id="x_2fa">Mercurial cleverly avoids a pitfall common to
   7.879 +	all earlier revision control systems: the problem of
   7.880 +	<emphasis>inefficient retrieval</emphasis>. Most revision
   7.881 +	control systems store the contents of a revision as an
   7.882 +	incremental series of modifications against a
   7.883 +	<quote>snapshot</quote>.  (Some base the snapshot on the
   7.884 +	oldest revision, others on the newest.)  To reconstruct a
   7.885 +	specific revision, you must first read the snapshot, and then
   7.886 +	every one of the revisions between the snapshot and your
   7.887 +	target revision.  The more history that a file accumulates,
   7.888 +	the more revisions you must read, hence the longer it takes to
   7.889 +	reconstruct a particular revision.</para>
   7.890 +
   7.891 +      <figure id="fig:concepts:snapshot">
   7.892 +	<title>Snapshot of a revlog, with incremental deltas</title>
   7.893 +	<mediaobject>
   7.894 +	  <imageobject><imagedata fileref="figs/snapshot.png"/></imageobject>
   7.895 +	  <textobject><phrase>XXX add text</phrase></textobject>
   7.896 +	</mediaobject>
   7.897 +      </figure>
   7.898 +
   7.899 +      <para id="x_2fc">The innovation that Mercurial applies to this problem is
   7.900 +	simple but effective.  Once the cumulative amount of delta
   7.901 +	information stored since the last snapshot exceeds a fixed
   7.902 +	threshold, it stores a new snapshot (compressed, of course),
   7.903 +	instead of another delta.  This makes it possible to
   7.904 +	reconstruct <emphasis>any</emphasis> revision of a file
   7.905 +	quickly.  This approach works so well that it has since been
   7.906 +	copied by several other revision control systems.</para>
   7.907 +
   7.908 +      <para id="x_2fd"><xref linkend="fig:concepts:snapshot"/> illustrates
   7.909 +	the idea.  In an entry in a revlog's index file, Mercurial
   7.910 +	stores the range of entries from the data file that it must
   7.911 +	read to reconstruct a particular revision.</para>
   7.912 +
   7.913 +      <sect3>
   7.914 +	<title>Aside: the influence of video compression</title>
   7.915 +
   7.916 +	<para id="x_2fe">If you're familiar with video compression or
   7.917 +	  have ever watched a TV feed through a digital cable or
   7.918 +	  satellite service, you may know that most video compression
   7.919 +	  schemes store each frame of video as a delta against its
   7.920 +	  predecessor frame.</para>
   7.921 +
   7.922 +	<para id="x_2ff">Mercurial borrows this idea to make it
   7.923 +	  possible to reconstruct a revision from a snapshot and a
   7.924 +	  small number of deltas.</para>
   7.925 +
   7.926 +      </sect3>
   7.927 +    </sect2>
   7.928 +    <sect2>
   7.929 +      <title>Identification and strong integrity</title>
   7.930 +
   7.931 +      <para id="x_300">Along with delta or snapshot information, a revlog entry
   7.932 +	contains a cryptographic hash of the data that it represents.
   7.933 +	This makes it difficult to forge the contents of a revision,
   7.934 +	and easy to detect accidental corruption.</para>
   7.935 +
   7.936 +      <para id="x_301">Hashes provide more than a mere check against corruption;
   7.937 +	they are used as the identifiers for revisions.  The changeset
   7.938 +	identification hashes that you see as an end user are from
   7.939 +	revisions of the changelog.  Although filelogs and the
   7.940 +	manifest also use hashes, Mercurial only uses these behind the
   7.941 +	scenes.</para>
   7.942 +
   7.943 +      <para id="x_302">Mercurial verifies that hashes are correct when it
   7.944 +	retrieves file revisions and when it pulls changes from
   7.945 +	another repository.  If it encounters an integrity problem, it
   7.946 +	will complain and stop whatever it's doing.</para>
   7.947 +
   7.948 +      <para id="x_303">In addition to the effect it has on retrieval efficiency,
   7.949 +	Mercurial's use of periodic snapshots makes it more robust
   7.950 +	against partial data corruption.  If a revlog becomes partly
   7.951 +	corrupted due to a hardware error or system bug, it's often
   7.952 +	possible to reconstruct some or most revisions from the
   7.953 +	uncorrupted sections of the revlog, both before and after the
   7.954 +	corrupted section.  This would not be possible with a
   7.955 +	delta-only storage model.</para>
   7.956 +    </sect2>
   7.957 +  </sect1>
   7.958 +
   7.959 +  <sect1>
   7.960 +    <title>Revision history, branching, and merging</title>
   7.961 +
   7.962 +    <para id="x_304">Every entry in a Mercurial revlog knows the identity of its
   7.963 +      immediate ancestor revision, usually referred to as its
   7.964 +      <emphasis>parent</emphasis>.  In fact, a revision contains room
   7.965 +      for not one parent, but two.  Mercurial uses a special hash,
   7.966 +      called the <quote>null ID</quote>, to represent the idea
   7.967 +      <quote>there is no parent here</quote>.  This hash is simply a
   7.968 +      string of zeroes.</para>
   7.969 +
   7.970 +    <para id="x_305">In <xref linkend="fig:concepts:revlog"/>, you can see
   7.971 +      an example of the conceptual structure of a revlog.  Filelogs,
   7.972 +      manifests, and changelogs all have this same structure; they
   7.973 +      differ only in the kind of data stored in each delta or
   7.974 +      snapshot.</para>
   7.975 +
   7.976 +    <para id="x_306">The first revision in a revlog (at the bottom of the image)
   7.977 +      has the null ID in both of its parent slots.  For a
   7.978 +      <quote>normal</quote> revision, its first parent slot contains
   7.979 +      the ID of its parent revision, and its second contains the null
   7.980 +      ID, indicating that the revision has only one real parent.  Any
   7.981 +      two revisions that have the same parent ID are branches.  A
   7.982 +      revision that represents a merge between branches has two normal
   7.983 +      revision IDs in its parent slots.</para>
   7.984 +
   7.985 +    <figure id="fig:concepts:revlog">
   7.986 +      <title>The conceptual structure of a revlog</title>
   7.987 +      <mediaobject>
   7.988 +	<imageobject><imagedata fileref="figs/revlog.png"/></imageobject>
   7.989 +	<textobject><phrase>XXX add text</phrase></textobject>
   7.990 +      </mediaobject>
   7.991 +    </figure>
   7.992 +
   7.993 +  </sect1>
   7.994 +  <sect1>
   7.995 +    <title>The working directory</title>
   7.996 +
   7.997 +    <para id="x_307">In the working directory, Mercurial stores a snapshot of the
   7.998 +      files from the repository as of a particular changeset.</para>
   7.999 +
  7.1000 +    <para id="x_308">The working directory <quote>knows</quote> which changeset
  7.1001 +      it contains.  When you update the working directory to contain a
  7.1002 +      particular changeset, Mercurial looks up the appropriate
  7.1003 +      revision of the manifest to find out which files it was tracking
  7.1004 +      at the time that changeset was committed, and which revision of
  7.1005 +      each file was then current.  It then recreates a copy of each of
  7.1006 +      those files, with the same contents it had when the changeset
  7.1007 +      was committed.</para>
  7.1008 +
  7.1009 +    <para id="x_309">The <emphasis>dirstate</emphasis> is a special
  7.1010 +      structure that contains Mercurial's knowledge of the working
  7.1011 +      directory.  It is maintained as a file named
  7.1012 +      <filename>.hg/dirstate</filename> inside a repository.  The
  7.1013 +      dirstate details which changeset the working directory is
  7.1014 +      updated to, and all of the files that Mercurial is tracking in
  7.1015 +      the working directory. It also lets Mercurial quickly notice
  7.1016 +      changed files, by recording their checkout times and
  7.1017 +      sizes.</para>
  7.1018 +
  7.1019 +    <para id="x_30a">Just as a revision of a revlog has room for two parents, so
  7.1020 +      that it can represent either a normal revision (with one parent)
  7.1021 +      or a merge of two earlier revisions, the dirstate has slots for
  7.1022 +      two parents.  When you use the <command role="hg-cmd">hg
  7.1023 +	update</command> command, the changeset that you update to is
  7.1024 +      stored in the <quote>first parent</quote> slot, and the null ID
  7.1025 +      in the second. When you <command role="hg-cmd">hg
  7.1026 +	merge</command> with another changeset, the first parent
  7.1027 +      remains unchanged, and the second parent is filled in with the
  7.1028 +      changeset you're merging with.  The <command role="hg-cmd">hg
  7.1029 +	parents</command> command tells you what the parents of the
  7.1030 +      dirstate are.</para>
  7.1031 +
  7.1032 +    <sect2>
  7.1033 +      <title>What happens when you commit</title>
  7.1034 +
  7.1035 +      <para id="x_30b">The dirstate stores parent information for more than just
  7.1036 +	book-keeping purposes.  Mercurial uses the parents of the
  7.1037 +	dirstate as <emphasis>the parents of a new
  7.1038 +	  changeset</emphasis> when you perform a commit.</para>
  7.1039 +
  7.1040 +      <figure id="fig:concepts:wdir">
  7.1041 +	<title>The working directory can have two parents</title>
  7.1042 +	<mediaobject>
  7.1043 +	  <imageobject><imagedata fileref="figs/wdir.png"/></imageobject>
  7.1044 +	  <textobject><phrase>XXX add text</phrase></textobject>
  7.1045 +	</mediaobject>
  7.1046 +      </figure>
  7.1047 +
  7.1048 +      <para id="x_30d"><xref linkend="fig:concepts:wdir"/> shows the
  7.1049 +	normal state of the working directory, where it has a single
  7.1050 +	changeset as parent.  That changeset is the
  7.1051 +	<emphasis>tip</emphasis>, the newest changeset in the
  7.1052 +	repository that has no children.</para>
  7.1053 +
  7.1054 +      <figure id="fig:concepts:wdir-after-commit">
  7.1055 +	<title>The working directory gains new parents after a
  7.1056 +	  commit</title>
  7.1057 +	<mediaobject>
  7.1058 +	  <imageobject><imagedata fileref="figs/wdir-after-commit.png"/></imageobject>
  7.1059 +	  <textobject><phrase>XXX add text</phrase></textobject>
  7.1060 +	</mediaobject>
  7.1061 +      </figure>
  7.1062 +
  7.1063 +      <para id="x_30f">It's useful to think of the working directory as
  7.1064 +	<quote>the changeset I'm about to commit</quote>.  Any files
  7.1065 +	that you tell Mercurial that you've added, removed, renamed,
  7.1066 +	or copied will be reflected in that changeset, as will
  7.1067 +	modifications to any files that Mercurial is already tracking;
  7.1068 +	the new changeset will have the parents of the working
  7.1069 +	directory as its parents.</para>
  7.1070 +
  7.1071 +      <para id="x_310">After a commit, Mercurial will update the
  7.1072 +	parents of the working directory, so that the first parent is
  7.1073 +	the ID of the new changeset, and the second is the null ID.
  7.1074 +	This is shown in <xref
  7.1075 +	  linkend="fig:concepts:wdir-after-commit"/>. Mercurial
  7.1076 +	doesn't touch any of the files in the working directory when
  7.1077 +	you commit; it just modifies the dirstate to note its new
  7.1078 +	parents.</para>
  7.1079 +
  7.1080 +    </sect2>
  7.1081 +    <sect2>
  7.1082 +      <title>Creating a new head</title>
  7.1083 +
  7.1084 +      <para id="x_311">It's perfectly normal to update the working directory to a
  7.1085 +	changeset other than the current tip.  For example, you might
  7.1086 +	want to know what your project looked like last Tuesday, or
  7.1087 +	you could be looking through changesets to see which one
  7.1088 +	introduced a bug.  In cases like this, the natural thing to do
  7.1089 +	is update the working directory to the changeset you're
  7.1090 +	interested in, and then examine the files in the working
  7.1091 +	directory directly to see their contents as they were when you
  7.1092 +	committed that changeset.  The effect of this is shown in
  7.1093 +	<xref linkend="fig:concepts:wdir-pre-branch"/>.</para>
  7.1094 +
  7.1095 +      <figure id="fig:concepts:wdir-pre-branch">
  7.1096 +	<title>The working directory, updated to an older
  7.1097 +	  changeset</title>
  7.1098 +	<mediaobject>
  7.1099 +	  <imageobject><imagedata fileref="figs/wdir-pre-branch.png"/></imageobject>
  7.1100 +	  <textobject><phrase>XXX add text</phrase></textobject>
  7.1101 +	</mediaobject>
  7.1102 +      </figure>
  7.1103 +
  7.1104 +      <para id="x_313">Having updated the working directory to an
  7.1105 +	older changeset, what happens if you make some changes, and
  7.1106 +	then commit?  Mercurial behaves in the same way as I outlined
  7.1107 +	above.  The parents of the working directory become the
  7.1108 +	parents of the new changeset.  This new changeset has no
  7.1109 +	children, so it becomes the new tip.  And the repository now
  7.1110 +	contains two changesets that have no children; we call these
  7.1111 +	<emphasis>heads</emphasis>.  You can see the structure that
  7.1112 +	this creates in <xref
  7.1113 +	  linkend="fig:concepts:wdir-branch"/>.</para>
  7.1114 +
  7.1115 +      <figure id="fig:concepts:wdir-branch">
  7.1116 +	<title>After a commit made while synced to an older
  7.1117 +	  changeset</title>
  7.1118 +	<mediaobject>
  7.1119 +	  <imageobject><imagedata fileref="figs/wdir-branch.png"/></imageobject>
  7.1120 +	  <textobject><phrase>XXX add text</phrase></textobject>
  7.1121 +	</mediaobject>
  7.1122 +      </figure>
  7.1123 +
  7.1124 +      <note>
  7.1125 +	<para id="x_315">If you're new to Mercurial, you should keep
  7.1126 +	  in mind a common <quote>error</quote>, which is to use the
  7.1127 +	  <command role="hg-cmd">hg pull</command> command without any
  7.1128 +	  options.  By default, the <command role="hg-cmd">hg
  7.1129 +	    pull</command> command <emphasis>does not</emphasis>
  7.1130 +	  update the working directory, so you'll bring new changesets
  7.1131 +	  into your repository, but the working directory will stay
  7.1132 +	  synced at the same changeset as before the pull.  If you
  7.1133 +	  make some changes and commit afterwards, you'll thus create
  7.1134 +	  a new head, because your working directory isn't synced to
  7.1135 +	  whatever the current tip is.  To combine the operation of a
  7.1136 +	  pull, followed by an update, run <command>hg pull
  7.1137 +	    -u</command>.</para>
  7.1138 +
  7.1139 +	<para id="x_316">I put the word <quote>error</quote> in quotes
  7.1140 +	  because all that you need to do to rectify the situation
  7.1141 +	  where you created a new head by accident is
  7.1142 +	  <command role="hg-cmd">hg merge</command>, then <command
  7.1143 +	    role="hg-cmd">hg commit</command>.  In other words, this
  7.1144 +	  almost never has negative consequences; it's just something
  7.1145 +	  of a surprise for newcomers.  I'll discuss other ways to
  7.1146 +	  avoid this behavior, and why Mercurial behaves in this
  7.1147 +	  initially surprising way, later on.</para>
  7.1148 +      </note>
  7.1149 +
  7.1150 +    </sect2>
  7.1151 +    <sect2>
  7.1152 +      <title>Merging changes</title>
  7.1153 +
  7.1154 +      <para id="x_317">When you run the <command role="hg-cmd">hg
  7.1155 +	  merge</command> command, Mercurial leaves the first parent
  7.1156 +	of the working directory unchanged, and sets the second parent
  7.1157 +	to the changeset you're merging with, as shown in <xref
  7.1158 +	  linkend="fig:concepts:wdir-merge"/>.</para>
  7.1159 +
  7.1160 +      <figure id="fig:concepts:wdir-merge">
  7.1161 +	<title>Merging two heads</title>
  7.1162 +	<mediaobject>
  7.1163 +	  <imageobject>
  7.1164 +	    <imagedata fileref="figs/wdir-merge.png"/>
  7.1165 +	  </imageobject>
  7.1166 +	  <textobject><phrase>XXX add text</phrase></textobject>
  7.1167 +	</mediaobject>
  7.1168 +      </figure>
  7.1169 +
  7.1170 +      <para id="x_319">Mercurial also has to modify the working directory, to
  7.1171 +	merge the files managed in the two changesets.  Simplified a
  7.1172 +	little, the merging process goes like this, for every file in
  7.1173 +	the manifests of both changesets.</para>
  7.1174 +      <itemizedlist>
  7.1175 +	<listitem><para id="x_31a">If neither changeset has modified a file, do
  7.1176 +	    nothing with that file.</para>
  7.1177 +	</listitem>
  7.1178 +	<listitem><para id="x_31b">If one changeset has modified a file, and the
  7.1179 +	    other hasn't, create the modified copy of the file in the
  7.1180 +	    working directory.</para>
  7.1181 +	</listitem>
  7.1182 +	<listitem><para id="x_31c">If one changeset has removed a file, and the
  7.1183 +	    other hasn't (or has also deleted it), delete the file
  7.1184 +	    from the working directory.</para>
  7.1185 +	</listitem>
  7.1186 +	<listitem><para id="x_31d">If one changeset has removed a file, but the
  7.1187 +	    other has modified the file, ask the user what to do: keep
  7.1188 +	    the modified file, or remove it?</para>
  7.1189 +	</listitem>
  7.1190 +	<listitem><para id="x_31e">If both changesets have modified a file,
  7.1191 +	    invoke an external merge program to choose the new
  7.1192 +	    contents for the merged file.  This may require input from
  7.1193 +	    the user.</para>
  7.1194 +	</listitem>
  7.1195 +	<listitem><para id="x_31f">If one changeset has modified a file, and the
  7.1196 +	    other has renamed or copied the file, make sure that the
  7.1197 +	    changes follow the new name of the file.</para>
  7.1198 +	</listitem></itemizedlist>
  7.1199 +      <para id="x_320">There are more details&emdash;merging has plenty of corner
  7.1200 +	cases&emdash;but these are the most common choices that are
  7.1201 +	involved in a merge.  As you can see, most cases are
  7.1202 +	completely automatic, and indeed most merges finish
  7.1203 +	automatically, without requiring your input to resolve any
  7.1204 +	conflicts.</para>
  7.1205 +
  7.1206 +      <para id="x_321">When you're thinking about what happens when you commit
  7.1207 +	after a merge, once again the working directory is <quote>the
  7.1208 +	  changeset I'm about to commit</quote>.  After the <command
  7.1209 +	  role="hg-cmd">hg merge</command> command completes, the
  7.1210 +	working directory has two parents; these will become the
  7.1211 +	parents of the new changeset.</para>
  7.1212 +
  7.1213 +      <para id="x_322">Mercurial lets you perform multiple merges, but
  7.1214 +	you must commit the results of each individual merge as you
  7.1215 +	go.  This is necessary because Mercurial only tracks two
  7.1216 +	parents for both revisions and the working directory.  While
  7.1217 +	it would be technically feasible to merge multiple changesets
  7.1218 +	at once, Mercurial avoids this for simplicity.  With multi-way
  7.1219 +	merges, the risks of user confusion, nasty conflict
  7.1220 +	resolution, and making a terrible mess of a merge would grow
  7.1221 +	intolerable.</para>
  7.1222 +
  7.1223 +    </sect2>
  7.1224 +
  7.1225 +    <sect2>
  7.1226 +      <title>Merging and renames</title>
  7.1227 +
  7.1228 +      <para id="x_69a">A surprising number of revision control systems pay little
  7.1229 +	or no attention to a file's <emphasis>name</emphasis> over
  7.1230 +	time.  For instance, it used to be common that if a file got
  7.1231 +	renamed on one side of a merge, the changes from the other
  7.1232 +	side would be silently dropped.</para>
  7.1233 +
  7.1234 +      <para id="x_69b">Mercurial records metadata when you tell it to perform a
  7.1235 +	rename or copy. It uses this metadata during a merge to do the
  7.1236 +	right thing in the case of a merge.  For instance, if I rename
  7.1237 +	a file, and you edit it without renaming it, when we merge our
  7.1238 +	work the file will be renamed and have your edits
  7.1239 +	applied.</para>
  7.1240 +    </sect2>
  7.1241 +  </sect1>
  7.1242 +
  7.1243 +  <sect1>
  7.1244 +    <title>Other interesting design features</title>
  7.1245 +
  7.1246 +    <para id="x_323">In the sections above, I've tried to highlight some of the
  7.1247 +      most important aspects of Mercurial's design, to illustrate that
  7.1248 +      it pays careful attention to reliability and performance.
  7.1249 +      However, the attention to detail doesn't stop there.  There are
  7.1250 +      a number of other aspects of Mercurial's construction that I
  7.1251 +      personally find interesting.  I'll detail a few of them here,
  7.1252 +      separate from the <quote>big ticket</quote> items above, so that
  7.1253 +      if you're interested, you can gain a better idea of the amount
  7.1254 +      of thinking that goes into a well-designed system.</para>
  7.1255 +
  7.1256 +    <sect2>
  7.1257 +      <title>Clever compression</title>
  7.1258 +
  7.1259 +      <para id="x_324">When appropriate, Mercurial will store both snapshots and
  7.1260 +	deltas in compressed form.  It does this by always
  7.1261 +	<emphasis>trying to</emphasis> compress a snapshot or delta,
  7.1262 +	but only storing the compressed version if it's smaller than
  7.1263 +	the uncompressed version.</para>
  7.1264 +
  7.1265 +      <para id="x_325">This means that Mercurial does <quote>the right
  7.1266 +	  thing</quote> when storing a file whose native form is
  7.1267 +	compressed, such as a <literal>zip</literal> archive or a JPEG
  7.1268 +	image.  When these types of files are compressed a second
  7.1269 +	time, the resulting file is usually bigger than the
  7.1270 +	once-compressed form, and so Mercurial will store the plain
  7.1271 +	<literal>zip</literal> or JPEG.</para>
  7.1272 +
  7.1273 +      <para id="x_326">Deltas between revisions of a compressed file are usually
  7.1274 +	larger than snapshots of the file, and Mercurial again does
  7.1275 +	<quote>the right thing</quote> in these cases.  It finds that
  7.1276 +	such a delta exceeds the threshold at which it should store a
  7.1277 +	complete snapshot of the file, so it stores the snapshot,
  7.1278 +	again saving space compared to a naive delta-only
  7.1279 +	approach.</para>
  7.1280 +
  7.1281 +      <sect3>
  7.1282 +	<title>Network recompression</title>
  7.1283 +
  7.1284 +	<para id="x_327">When storing revisions on disk, Mercurial uses the
  7.1285 +	  <quote>deflate</quote> compression algorithm (the same one
  7.1286 +	  used by the popular <literal>zip</literal> archive format),
  7.1287 +	  which balances good speed with a respectable compression
  7.1288 +	  ratio.  However, when transmitting revision data over a
  7.1289 +	  network connection, Mercurial uncompresses the compressed
  7.1290 +	  revision data.</para>
  7.1291 +
  7.1292 +	<para id="x_328">If the connection is over HTTP, Mercurial recompresses
  7.1293 +	  the entire stream of data using a compression algorithm that
  7.1294 +	  gives a better compression ratio (the Burrows-Wheeler
  7.1295 +	  algorithm from the widely used <literal>bzip2</literal>
  7.1296 +	  compression package).  This combination of algorithm and
  7.1297 +	  compression of the entire stream (instead of a revision at a
  7.1298 +	  time) substantially reduces the number of bytes to be
  7.1299 +	  transferred, yielding better network performance over most
  7.1300 +	  kinds of network.</para>
  7.1301 +
  7.1302 +	<para id="x_329">If the connection is over
  7.1303 +	  <command>ssh</command>, Mercurial
  7.1304 +	  <emphasis>doesn't</emphasis> recompress the stream, because
  7.1305 +	  <command>ssh</command> can already do this itself.  You can
  7.1306 +	  tell Mercurial to always use <command>ssh</command>'s
  7.1307 +	  compression feature by editing the
  7.1308 +	  <filename>.hgrc</filename> file in your home directory as
  7.1309 +	  follows.</para>
  7.1310 +
  7.1311 +	<programlisting>[ui]
  7.1312 +ssh = ssh -C</programlisting>
  7.1313 +
  7.1314 +      </sect3>
  7.1315 +    </sect2>
  7.1316 +    <sect2>
  7.1317 +      <title>Read/write ordering and atomicity</title>
  7.1318 +
  7.1319 +      <para id="x_32a">Appending to files isn't the whole story when
  7.1320 +	it comes to guaranteeing that a reader won't see a partial
  7.1321 +	write.  If you recall <xref linkend="fig:concepts:metadata"/>,
  7.1322 +	revisions in the changelog point to revisions in the manifest,
  7.1323 +	and revisions in the manifest point to revisions in filelogs.
  7.1324 +	This hierarchy is deliberate.</para>
  7.1325 +
  7.1326 +      <para id="x_32b">A writer starts a transaction by writing filelog and
  7.1327 +	manifest data, and doesn't write any changelog data until
  7.1328 +	those are finished.  A reader starts by reading changelog
  7.1329 +	data, then manifest data, followed by filelog data.</para>
  7.1330 +
  7.1331 +      <para id="x_32c">Since the writer has always finished writing filelog and
  7.1332 +	manifest data before it writes to the changelog, a reader will
  7.1333 +	never read a pointer to a partially written manifest revision
  7.1334 +	from the changelog, and it will never read a pointer to a
  7.1335 +	partially written filelog revision from the manifest.</para>
  7.1336 +
  7.1337 +    </sect2>
  7.1338 +    <sect2>
  7.1339 +      <title>Concurrent access</title>
  7.1340 +
  7.1341 +      <para id="x_32d">The read/write ordering and atomicity guarantees mean that
  7.1342 +	Mercurial never needs to <emphasis>lock</emphasis> a
  7.1343 +	repository when it's reading data, even if the repository is
  7.1344 +	being written to while the read is occurring. This has a big
  7.1345 +	effect on scalability; you can have an arbitrary number of
  7.1346 +	Mercurial processes safely reading data from a repository
  7.1347 +	all at once, no matter whether it's being written to or
  7.1348 +	not.</para>
  7.1349 +
  7.1350 +      <para id="x_32e">The lockless nature of reading means that if you're
  7.1351 +	sharing a repository on a multi-user system, you don't need to
  7.1352 +	grant other local users permission to
  7.1353 +	<emphasis>write</emphasis> to your repository in order for
  7.1354 +	them to be able to clone it or pull changes from it; they only
  7.1355 +	need <emphasis>read</emphasis> permission.  (This is
  7.1356 +	<emphasis>not</emphasis> a common feature among revision
  7.1357 +	control systems, so don't take it for granted!  Most require
  7.1358 +	readers to be able to lock a repository to access it safely,
  7.1359 +	and this requires write permission on at least one directory,
  7.1360 +	which of course makes for all kinds of nasty and annoying
  7.1361 +	security and administrative problems.)</para>
  7.1362 +
  7.1363 +      <para id="x_32f">Mercurial uses locks to ensure that only one process can
  7.1364 +	write to a repository at a time (the locking mechanism is safe
  7.1365 +	even over filesystems that are notoriously hostile to locking,
  7.1366 +	such as NFS).  If a repository is locked, a writer will wait
  7.1367 +	for a while to retry if the repository becomes unlocked, but
  7.1368 +	if the repository remains locked for too long, the process
  7.1369 +	attempting to write will time out after a while. This means
  7.1370 +	that your daily automated scripts won't get stuck forever and
  7.1371 +	pile up if a system crashes unnoticed, for example.  (Yes, the
  7.1372 +	timeout is configurable, from zero to infinity.)</para>
  7.1373 +
  7.1374 +      <sect3>
  7.1375 +	<title>Safe dirstate access</title>
  7.1376 +
  7.1377 +	<para id="x_330">As with revision data, Mercurial doesn't take a lock to
  7.1378 +	  read the dirstate file; it does acquire a lock to write it.
  7.1379 +	  To avoid the possibility of reading a partially written copy
  7.1380 +	  of the dirstate file, Mercurial writes to a file with a
  7.1381 +	  unique name in the same directory as the dirstate file, then
  7.1382 +	  renames the temporary file atomically to
  7.1383 +	  <filename>dirstate</filename>.  The file named
  7.1384 +	  <filename>dirstate</filename> is thus guaranteed to be
  7.1385 +	  complete, not partially written.</para>
  7.1386 +
  7.1387 +      </sect3>
  7.1388 +    </sect2>
  7.1389 +    <sect2>
  7.1390 +      <title>Avoiding seeks</title>
  7.1391 +
  7.1392 +      <para id="x_331">Critical to Mercurial's performance is the avoidance of
  7.1393 +	seeks of the disk head, since any seek is far more expensive
  7.1394 +	than even a comparatively large read operation.</para>
  7.1395 +
  7.1396 +      <para id="x_332">This is why, for example, the dirstate is stored in a
  7.1397 +	single file.  If there were a dirstate file per directory that
  7.1398 +	Mercurial tracked, the disk would seek once per directory.
  7.1399 +	Instead, Mercurial reads the entire single dirstate file in
  7.1400 +	one step.</para>
  7.1401 +
  7.1402 +      <para id="x_333">Mercurial also uses a <quote>copy on write</quote> scheme
  7.1403 +	when cloning a repository on local storage.  Instead of
  7.1404 +	copying every revlog file from the old repository into the new
  7.1405 +	repository, it makes a <quote>hard link</quote>, which is a
  7.1406 +	shorthand way to say <quote>these two names point to the same
  7.1407 +	  file</quote>.  When Mercurial is about to write to one of a
  7.1408 +	revlog's files, it checks to see if the number of names
  7.1409 +	pointing at the file is greater than one.  If it is, more than
  7.1410 +	one repository is using the file, so Mercurial makes a new
  7.1411 +	copy of the file that is private to this repository.</para>
  7.1412 +
  7.1413 +      <para id="x_334">A few revision control developers have pointed out that
  7.1414 +	this idea of making a complete private copy of a file is not
  7.1415 +	very efficient in its use of storage.  While this is true,
  7.1416 +	storage is cheap, and this method gives the highest
  7.1417 +	performance while deferring most book-keeping to the operating
  7.1418 +	system.  An alternative scheme would most likely reduce
  7.1419 +	performance and increase the complexity of the software, but
  7.1420 +	speed and simplicity are key to the <quote>feel</quote> of
  7.1421 +	day-to-day use.</para>
  7.1422 +
  7.1423 +    </sect2>
  7.1424 +    <sect2>
  7.1425 +      <title>Other contents of the dirstate</title>
  7.1426 +
  7.1427 +      <para id="x_335">Because Mercurial doesn't force you to tell it when you're
  7.1428 +	modifying a file, it uses the dirstate to store some extra
  7.1429 +	information so it can determine efficiently whether you have
  7.1430 +	modified a file.  For each file in the working directory, it
  7.1431 +	stores the time that it last modified the file itself, and the
  7.1432 +	size of the file at that time.</para>
  7.1433 +
  7.1434 +      <para id="x_336">When you explicitly <command role="hg-cmd">hg
  7.1435 +	  add</command>, <command role="hg-cmd">hg remove</command>,
  7.1436 +	<command role="hg-cmd">hg rename</command> or <command
  7.1437 +	  role="hg-cmd">hg copy</command> files, Mercurial updates the
  7.1438 +	dirstate so that it knows what to do with those files when you
  7.1439 +	commit.</para>
  7.1440 +
  7.1441 +      <para id="x_337">The dirstate helps Mercurial to efficiently
  7.1442 +	  check the status of files in a repository.</para>
  7.1443 +
  7.1444 +      <itemizedlist>
  7.1445 +	<listitem>
  7.1446 +	  <para id="x_726">When Mercurial checks the state of a file in the
  7.1447 +	    working directory, it first checks a file's modification
  7.1448 +	    time against the time in the dirstate that records when
  7.1449 +	    Mercurial last wrote the file. If the last modified time
  7.1450 +	    is the same as the time when Mercurial wrote the file, the
  7.1451 +	    file must not have been modified, so Mercurial does not
  7.1452 +	    need to check any further.</para>
  7.1453 +	</listitem>
  7.1454 +	<listitem>
  7.1455 +	  <para id="x_727">If the file's size has changed, the file must have
  7.1456 +	    been modified.  If the modification time has changed, but
  7.1457 +	    the size has not, only then does Mercurial need to
  7.1458 +	    actually read the contents of the file to see if it has
  7.1459 +	    changed.</para>
  7.1460 +	</listitem>
  7.1461 +      </itemizedlist>
  7.1462 +
  7.1463 +      <para id="x_728">Storing the modification time and size dramatically
  7.1464 +	reduces the number of read operations that Mercurial needs to
  7.1465 +	perform when we run commands like <command>hg status</command>.
  7.1466 +	This results in large performance improvements.</para>
  7.1467 +    </sect2>
  7.1468 +  </sect1>
  7.1469  </chapter>
  7.1470  
  7.1471  <!--
  7.1472  local variables: 
  7.1473  sgml-parent-document: ("00book.xml" "book" "chapter")
  7.1474  end:
  7.1475 --->
  7.1476 \ No newline at end of file
  7.1477 +-->