hgbook
changeset 984:cc81b4175833
some spelling mistakes corrected in fr/appA-svn.xml
author | Frédéric Bouquet <youshe.jaalon@gmail.com> |
---|---|
date | Wed Sep 09 15:12:25 2009 +0200 (2009-09-09) |
parents | 5e1e70fcdfdb |
children | ac738e7a6bf9 |
files | fr/appA-svn.xml |
line diff
1.1 --- a/fr/appA-svn.xml Tue Sep 08 23:42:42 2009 +0200 1.2 +++ b/fr/appA-svn.xml Wed Sep 09 15:12:25 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 arguments, 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>