Jean-Marie Clément avatar Jean-Marie Clément committed 58e0737

French translation: proof reading appA-svn.xml, part 2

Comments (0)

Files changed (1)

         quelle partie de son espace de nommage est en fait une branche, il
         traite la plupart des commandes comme des requêtes à exécuter sur le
         répertoire où vous vous situez, et ses sous répertoires. Par exemple,
-        si vous exécuter <command>svn log</command>, vous verrez l'historique 
-        de la partie de l'arboresence où vous vous situez, et non la
+        si vous exécutez <command>svn log</command>, vous verrez l'historique 
+        de la partie de l'arboresence où vous vous situez, et non de la
         hiérarchie entière.</para>
 
 	<para id="x_6fc">Les commandes de Mercurial ont un comportement
-        différents, appliquant toutes commandes à l'ensemble de l'arboresence
+        différent : toutes les commandes s'appliquent à l'ensemble de l'arboresence
         du dépôt. Exécutez la commande <command>hg log</command> et elle vous
-        donnera l'historique de l'ensemble de l'arboresence, quelque soit le
-        répertoire de cette dernière où vous vous situez à ce moment là. Si
-        vous souhaitez l'historique d'une répertoire ou seulement d'un
-        fichier, ajouter simplement le nom de celui-ci à la commande
-        <command>hg log src</command>.</para>
+        donnera l'historique de l'ensemble de l'arboresence, quel que soit le
+        sous-répertoire où vous vous situez. Si
+        vous souhaitez obtenir l'historique d'un répertoire ou seulement d'un
+        fichier, ajouter simplement le nom de celui-ci à la commande, par
+        exemple <command>hg log src</command>.</para>
 
 	<para id="x_6fd">De ma propre expérience, cette différence dans leur
-        comportement par défaut est probablement ce qui risque de vous
-        surprendre si vous basculez régulièrement d'un outil à l'autre.</para>
+        comportement par défaut est le plus probablement ce qui risque de vous
+        surprendre si vous passez régulièrement d'un outil à l'autre.</para>
       </sect3>
 
       <sect3>
 	<title>Opération multi utilisateur et sécurité</title>
 
 	<para id="x_6fe">Avec Subversion, il est normal (bien que légèrement
-        désapprouvée) que différentes personnes collaborent sur une seule
+        désapprouvé) que différentes personnes collaborent sur une seule
         branche. Si Alice et Bob travaillent ensemble, et Alice ajoute ses
         modications à leur branche partagée, Bob doit alors mettre à jour
-        la vue de la banche de son client avant d'ajouter lui même ses 
-        modifications. Puisqu'il n'a, à ce moment, aucun enregistrement
-        permanent des modifications qu'il a fait, il peut corrompre ou perdre
-        des modifications pendant et après sa mise à jour.</para>
+        sa vue de la branche avant de pouvoir appliquer un commit.
+        Puisqu'il n'a, à ce moment, pas effectué de commit
+        des modifications qu'il a faites, il se peut qu'il ne corrompe 
+        ou ne perde
+        ses modifications pendant ou après la mise à jour.</para>
 
 	<para id="x_6ff">Mercurial encourage, à l'inverse, un modèle 
-        "commit-puis-merge". Bob ajoute ses modifications de manière locale 
-        avant de récupérer les modifications d'Alice, ou d'envoyer les siennes 
-        au serveur qu'ils partagent. Si Alice envoye ses modifications avant
-        que Alice n'envoye les siennes, il ne pourra envoyer ses
-        modifications avant d'avoir récupérer les siennes. Si il fait une
-        erreur lors de la fusion, il peut toujours à sa version d'origine,
-        telle qu'elle a été enregistré.</para>
+        "commit-puis-merge". Avant de récupérer des modifications depuis le 
+        serveur, ou avant d'y envoyer les siennes, Bob enregistre ses 
+        modifications de manière locale en appliquant un commit. C'est à dire
+        que si Alice avait envoyé ses modifications sur le serveur avant
+        que Bob n'envoie les siennes, ce dernier ne pourra le faire
+        qu'après avoir récupéré et fusionné celles d'Alice avec les siennes. 
+        Si Bob fait alors une
+        erreur lors de la fusion, il pourra toujours restaurer sa version, pour
+        laquelle il avait appliqué le commit.</para>
           
 	<para id="x_700">Il est important de souligner qu'il s'agit de la
-        manière habituelle de travailler avec ses outils. Subversion propose
-        une manière plus sûr de travailler-dans-votre-propre-branche, mais il
-        est assez complexe pour que, en pratique, il ne soit jamais utiliser.
-        Mercurial propose un mode, un peu moyen sûr, mais permettant de
+        manière habituelle de travailler avec ces outils. Subversion propose
+        une manière plus sûre de "travailler-dans-votre-propre-branche", mais elle
+        est assez complexe pour que, en pratique, elle ne soit que rarement utilisé.
+        Mercurial propose de son côté un mode un peu moins sûr, permettant de
         récupérer des modifications par dessus des modifications non
-        commitées, mais c'est considéré comme assez inhabituel.</para> 
+        commitées, qui reste toutefois très peu répandu.</para> 
       </sect3>
 
       <sect3>
 
 	<para id="x_701">Une commande Subversion <command>svn
         commit</command> publie immédiatement les modifications sur le
-        serveur, où ils peuvent être vu par n'importe qui doté du privilège
+        serveur, où elles peuvent être vu par n'importe qui doté d'un privilège
         de lecture.</para>
 
-	<para id="x_702">Avec Mercurial, les modifications sont toujours
-        enregistrées localement, et doivent être par la suite transférer par
+	<para id="x_702">Avec Mercurial, les modifications sont toujours d'abord
+        enregistrées localement, et doivent être par la suite transférés par
         la commande <command>hg push</command>.</para>
 
-	<para id="x_703">Chaque approche à ses avantages et ses désavantages.
-        Le modèle Subversion implique que les modifications sont publiées, et
-        donc disponible immédiatement. D'un autre coté, il implique aussi
-        qu'un utilisateur doit avoir le droit d'écriture dans le dépôt pour
-        permettre l'utiliser normalement, et ce privilège n'est pas concédé 
-        facilement par les projets Open Source.</para>
+	<para id="x_703">Chaque approche à ses avantages et ses inconvénients.
+        Le modèle Subversion implique que les modifications soient publiées, et
+        donc disponibles immédiatement. D'un autre coté, cela implique aussi
+        que, pour pouvoir utiliser le logiciel normalement, un utilisateur doit 
+        avoir les droits d'écriture dans le dépôt, et ce privilège n'est pas concédé 
+        facilement par la plupart des projets Open Source.</para>
 
 	<para id="x_704">L'approche de Mercurial permet à quiquonque de faire
         un clone du dépôt et d'y ajouter ses modifications sans jamais avoir
         besoin de la permission de quiquonque, et l'on peut même publier ses
-        modifications et continuer à participer comme on le désir. La
-        distinction entre les commits et le transfert de ces derniers ouvre
-        la possibilité néanmoins que quelqu'un oublie pendant une longue
-        période de transférer ses modifications, ce qui dans certains cas
-        rares, peut piéger ses collaborateurs.</para>
+        modifications et continuer à participer comme on le désire. Toutefois, la
+        distinction entre les commits et le transfert de ces derniers présente
+        le risque que quelqu'un applique ses modifications par un commit local
+        sur son portable et parte se promener pendant quelques jours en ayant
+        oublié de les transférer, ce qui peut, dans certains rares cas,
+        bloquer temporairement ses collaborateurs.</para>
       </sect3>
     </sect2>
 
 	      <entry><command>hg commit</command>; <command>hg
 		  push</command></entry>
 	      <entry><command>hg push</command> publie les modifications
-              après leur enregistrement.</entry>
+              après un commit.</entry>
 	    </row>
 	    <row>
 	      <entry><command>svn copy</command></entry>
 	    <row>
 	      <entry><command>svn info</command></entry>
 	      <entry><command>hg parents</command></entry>
-	      <entry>Affiche quelle révision est extraite</entry>
+	      <entry>Affiche la version sur la base de laquelle on travaille</entry>
 	    </row>
 	    <row>
 	      <entry><command>svn info</command></entry>
 	      <entry><command>hg showconfig
-		  paths.parent</command></entry>
+		  paths.default</command></entry>
 	      <entry>Affiche de quelle URL est extrait ce dépôt</entry>
 	    </row>
 	    <row>
   <sect1>
     <title>Conseils utiles pour les débutants</title>
 
-    <para id="x_705">Avec la plupart des gestionnaire de révisions, afficher
+    <para id="x_705">Avec la plupart des gestionnaire de versions, afficher
     un diff associé à une révision peut être assez douloureux. Par exemple,
     avec Subversion, pour voir ce qui a été modifiée dans la révision 104654,
     vous devez saisir <command>svn diff -r104653:104654</command>. Mercurial
     élimine le besoin de saisir l'identifiant d'une révision deux fois dans
     ce cas classique. Pour un simple diff, <command>hg
-    export<command></command>
-    104654</command> suffit. Pour l'entrée du journal suivi du diff,
-    <command>hg log -r104654</command>. </para>
+    export 104654</command> suffit. Pour obtenir une entrée du journal suivie d'un diff,
+    <command>hg log -r104654 -p</command>.</para>
 
     <para id="x_706">Quand vous exécutez la commande <command>hg status</command>
     sans aucun arguments, elle affiche l'état de l'ensemble de l'arboresence,
     status</command>, elle va afficher les chemins relatif depuis votre
     répertoire courant à la place. Ainsi, pour avoir un état sur l'ensemble
     de l'arboresence à l'aide  de <command>hg status</command>, avec des
-    chemins relatifs à votre répertoire courant, et non le raçine du dépôt,
+    chemins relatifs à votre répertoire courant, et non le racine du dépôt,
     ajoutez la sortie de <command>hg root</command> à la commande
     <command>hg status</command>. Vous pouvez le faire aisément sur un
     système Unix ainsi :</para>
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.