1.1 --- a/fr/appA-svn.xml	Tue Sep 01 20:42:03 2009 +0200
     1.2 +++ b/fr/appA-svn.xml	Fri Sep 04 18:20:36 2009 +0200
     1.3 @@ -292,52 +292,55 @@
     1.4          quelle partie de son espace de nommage est en fait une branche, il
     1.5          traite la plupart des commandes comme des requêtes à exécuter sur le
     1.6          répertoire où vous vous situez, et ses sous répertoires. Par exemple,
     1.7 -        si vous exécuter <command>svn log</command>, vous verrez l'historique 
     1.8 -        de la partie de l'arboresence où vous vous situez, et non la
     1.9 +        si vous exécutez <command>svn log</command>, vous verrez l'historique 
    1.10 +        de la partie de l'arboresence où vous vous situez, et non de la
    1.11          hiérarchie entière.</para>
    1.12  
    1.13  	<para id="x_6fc">Les commandes de Mercurial ont un comportement
    1.14 -        différents, appliquant toutes commandes à l'ensemble de l'arboresence
    1.15 +        différent : toutes les commandes s'appliquent à l'ensemble de l'arboresence
    1.16          du dépôt. Exécutez la commande <command>hg log</command> et elle vous
    1.17 -        donnera l'historique de l'ensemble de l'arboresence, quelque soit le
    1.18 -        répertoire de cette dernière où vous vous situez à ce moment là. Si
    1.19 -        vous souhaitez l'historique d'une répertoire ou seulement d'un
    1.20 -        fichier, ajouter simplement le nom de celui-ci à la commande
    1.21 -        <command>hg log src</command>.</para>
    1.22 +        donnera l'historique de l'ensemble de l'arboresence, quel que soit le
    1.23 +        sous-répertoire où vous vous situez. Si
    1.24 +        vous souhaitez obtenir l'historique d'un répertoire ou seulement d'un
    1.25 +        fichier, ajouter simplement le nom de celui-ci à la commande, par
    1.26 +        exemple <command>hg log src</command>.</para>
    1.27  
    1.28  	<para id="x_6fd">De ma propre expérience, cette différence dans leur
    1.29 -        comportement par défaut est probablement ce qui risque de vous
    1.30 -        surprendre si vous basculez régulièrement d'un outil à l'autre.</para>
    1.31 +        comportement par défaut est le plus probablement ce qui risque de vous
    1.32 +        surprendre si vous passez régulièrement d'un outil à l'autre.</para>
    1.33        </sect3>
    1.34  
    1.35        <sect3>
    1.36  	<title>Opération multi utilisateur et sécurité</title>
    1.37  
    1.38  	<para id="x_6fe">Avec Subversion, il est normal (bien que légèrement
    1.39 -        désapprouvée) que différentes personnes collaborent sur une seule
    1.40 +        désapprouvé) que différentes personnes collaborent sur une seule
    1.41          branche. Si Alice et Bob travaillent ensemble, et Alice ajoute ses
    1.42          modications à leur branche partagée, Bob doit alors mettre à jour
    1.43 -        la vue de la banche de son client avant d'ajouter lui même ses 
    1.44 -        modifications. Puisqu'il n'a, à ce moment, aucun enregistrement
    1.45 -        permanent des modifications qu'il a fait, il peut corrompre ou perdre
    1.46 -        des modifications pendant et après sa mise à jour.</para>
    1.47 +        sa vue de la branche avant de pouvoir appliquer un commit.
    1.48 +        Puisqu'il n'a, à ce moment, pas effectué de commit
    1.49 +        des modifications qu'il a faites, il se peut qu'il ne corrompe 
    1.50 +        ou ne perde
    1.51 +        ses modifications pendant ou après la mise à jour.</para>
    1.52  
    1.53  	<para id="x_6ff">Mercurial encourage, à l'inverse, un modèle 
    1.54 -        "commit-puis-merge". Bob ajoute ses modifications de manière locale 
    1.55 -        avant de récupérer les modifications d'Alice, ou d'envoyer les siennes 
    1.56 -        au serveur qu'ils partagent. Si Alice envoye ses modifications avant
    1.57 -        que Alice n'envoye les siennes, il ne pourra envoyer ses
    1.58 -        modifications avant d'avoir récupérer les siennes. Si il fait une
    1.59 -        erreur lors de la fusion, il peut toujours à sa version d'origine,
    1.60 -        telle qu'elle a été enregistré.</para>
    1.61 +        "commit-puis-merge". Avant de récupérer des modifications depuis le 
    1.62 +        serveur, ou avant d'y envoyer les siennes, Bob enregistre ses 
    1.63 +        modifications de manière locale en appliquant un commit. C'est à dire
    1.64 +        que si Alice avait envoyé ses modifications sur le serveur avant
    1.65 +        que Bob n'envoie les siennes, ce dernier ne pourra le faire
    1.66 +        qu'après avoir récupéré et fusionné celles d'Alice avec les siennes. 
    1.67 +        Si Bob fait alors une
    1.68 +        erreur lors de la fusion, il pourra toujours restaurer sa version, pour
    1.69 +        laquelle il avait appliqué le commit.</para>
    1.70            
    1.71  	<para id="x_700">Il est important de souligner qu'il s'agit de la
    1.72 -        manière habituelle de travailler avec ses outils. Subversion propose
    1.73 -        une manière plus sûr de travailler-dans-votre-propre-branche, mais il
    1.74 -        est assez complexe pour que, en pratique, il ne soit jamais utiliser.
    1.75 -        Mercurial propose un mode, un peu moyen sûr, mais permettant de
    1.76 +        manière habituelle de travailler avec ces outils. Subversion propose
    1.77 +        une manière plus sûre de "travailler-dans-votre-propre-branche", mais elle
    1.78 +        est assez complexe pour que, en pratique, elle ne soit que rarement utilisé.
    1.79 +        Mercurial propose de son côté un mode un peu moins sûr, permettant de
    1.80          récupérer des modifications par dessus des modifications non
    1.81 -        commitées, mais c'est considéré comme assez inhabituel.</para> 
    1.82 +        commitées, qui reste toutefois très peu répandu.</para> 
    1.83        </sect3>
    1.84  
    1.85        <sect3>
    1.86 @@ -345,28 +348,29 @@
    1.87  
    1.88  	<para id="x_701">Une commande Subversion <command>svn
    1.89          commit</command> publie immédiatement les modifications sur le
    1.90 -        serveur, où ils peuvent être vu par n'importe qui doté du privilège
    1.91 +        serveur, où elles peuvent être vu par n'importe qui doté d'un privilège
    1.92          de lecture.</para>
    1.93  
    1.94 -	<para id="x_702">Avec Mercurial, les modifications sont toujours
    1.95 -        enregistrées localement, et doivent être par la suite transférer par
    1.96 +	<para id="x_702">Avec Mercurial, les modifications sont toujours d'abord
    1.97 +        enregistrées localement, et doivent être par la suite transférés par
    1.98          la commande <command>hg push</command>.</para>
    1.99  
   1.100 -	<para id="x_703">Chaque approche à ses avantages et ses désavantages.
   1.101 -        Le modèle Subversion implique que les modifications sont publiées, et
   1.102 -        donc disponible immédiatement. D'un autre coté, il implique aussi
   1.103 -        qu'un utilisateur doit avoir le droit d'écriture dans le dépôt pour
   1.104 -        permettre l'utiliser normalement, et ce privilège n'est pas concédé 
   1.105 -        facilement par les projets Open Source.</para>
   1.106 +	<para id="x_703">Chaque approche à ses avantages et ses inconvénients.
   1.107 +        Le modèle Subversion implique que les modifications soient publiées, et
   1.108 +        donc disponibles immédiatement. D'un autre coté, cela implique aussi
   1.109 +        que, pour pouvoir utiliser le logiciel normalement, un utilisateur doit 
   1.110 +        avoir les droits d'écriture dans le dépôt, et ce privilège n'est pas concédé 
   1.111 +        facilement par la plupart des projets Open Source.</para>
   1.112  
   1.113  	<para id="x_704">L'approche de Mercurial permet à quiquonque de faire
   1.114          un clone du dépôt et d'y ajouter ses modifications sans jamais avoir
   1.115          besoin de la permission de quiquonque, et l'on peut même publier ses
   1.116 -        modifications et continuer à participer comme on le désir. La
   1.117 -        distinction entre les commits et le transfert de ces derniers ouvre
   1.118 -        la possibilité néanmoins que quelqu'un oublie pendant une longue
   1.119 -        période de transférer ses modifications, ce qui dans certains cas
   1.120 -        rares, peut piéger ses collaborateurs.</para>
   1.121 +        modifications et continuer à participer comme on le désire. Toutefois, la
   1.122 +        distinction entre les commits et le transfert de ces derniers présente
   1.123 +        le risque que quelqu'un applique ses modifications par un commit local
   1.124 +        sur son portable et parte se promener pendant quelques jours en ayant
   1.125 +        oublié de les transférer, ce qui peut, dans certains rares cas,
   1.126 +        bloquer temporairement ses collaborateurs.</para>
   1.127        </sect3>
   1.128      </sect2>
   1.129  
   1.130 @@ -414,7 +418,7 @@
   1.131  	      <entry><command>hg commit</command>; <command>hg
   1.132  		  push</command></entry>
   1.133  	      <entry><command>hg push</command> publie les modifications
   1.134 -              après leur enregistrement.</entry>
   1.135 +              après un commit.</entry>
   1.136  	    </row>
   1.137  	    <row>
   1.138  	      <entry><command>svn copy</command></entry>
   1.139 @@ -456,12 +460,12 @@
   1.140  	    <row>
   1.141  	      <entry><command>svn info</command></entry>
   1.142  	      <entry><command>hg parents</command></entry>
   1.143 -	      <entry>Affiche quelle révision est extraite</entry>
   1.144 +	      <entry>Affiche la version sur la base de laquelle on travaille</entry>
   1.145  	    </row>
   1.146  	    <row>
   1.147  	      <entry><command>svn info</command></entry>
   1.148  	      <entry><command>hg showconfig
   1.149 -		  paths.parent</command></entry>
   1.150 +		  paths.default</command></entry>
   1.151  	      <entry>Affiche de quelle URL est extrait ce dépôt</entry>
   1.152  	    </row>
   1.153  	    <row>
   1.154 @@ -519,15 +523,14 @@
   1.155    <sect1>
   1.156      <title>Conseils utiles pour les débutants</title>
   1.157  
   1.158 -    <para id="x_705">Avec la plupart des gestionnaire de révisions, afficher
   1.159 +    <para id="x_705">Avec la plupart des gestionnaire de versions, afficher
   1.160      un diff associé à une révision peut être assez douloureux. Par exemple,
   1.161      avec Subversion, pour voir ce qui a été modifiée dans la révision 104654,
   1.162      vous devez saisir <command>svn diff -r104653:104654</command>. Mercurial
   1.163      élimine le besoin de saisir l'identifiant d'une révision deux fois dans
   1.164      ce cas classique. Pour un simple diff, <command>hg
   1.165 -    export<command></command>
   1.166 -    104654</command> suffit. Pour l'entrée du journal suivi du diff,
   1.167 -    <command>hg log -r104654</command>. </para>
   1.168 +    export 104654</command> suffit. Pour obtenir une entrée du journal suivie d'un diff,
   1.169 +    <command>hg log -r104654 -p</command>.</para>
   1.170  
   1.171      <para id="x_706">Quand vous exécutez la commande <command>hg status</command>
   1.172      sans aucun arguments, elle affiche l'état de l'ensemble de l'arboresence,
   1.173 @@ -538,7 +541,7 @@
   1.174      status</command>, elle va afficher les chemins relatif depuis votre
   1.175      répertoire courant à la place. Ainsi, pour avoir un état sur l'ensemble
   1.176      de l'arboresence à l'aide  de <command>hg status</command>, avec des
   1.177 -    chemins relatifs à votre répertoire courant, et non le raçine du dépôt,
   1.178 +    chemins relatifs à votre répertoire courant, et non le racine du dépôt,
   1.179      ajoutez la sortie de <command>hg root</command> à la commande
   1.180      <command>hg status</command>. Vous pouvez le faire aisément sur un
   1.181      système Unix ainsi :</para>