hgbook
changeset 980:c40dac4f63d8
merge with Jean Marie Clément
author | Romain PELISSE <belaran@gmail.com> |
---|---|
date | Fri Sep 04 18:55:53 2009 +0200 (2009-09-04) |
parents | 719b03ea27c8 64475a75365b |
children | 64393e8da2ff e6894aa7baf2 56953b292c8a |
files |
line diff
1.1 --- a/fr/appA-svn.xml Fri Sep 04 16:33:46 2009 +0200 1.2 +++ b/fr/appA-svn.xml Fri Sep 04 18:55:53 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>