[svnbook] r3694 committed - Improving French style :...
svnbook at googlecode.com
svnbook at googlecode.com
Sun Feb 14 03:24:41 CST 2010
Revision: 3694
Author: christophe.nanteuil
Date: Sun Feb 14 01:24:11 2010
Log: Improving French style :
- passage au présent si possible
- typographie
- Subtantifs pour les titres
http://code.google.com/p/svnbook/source/detail?r=3694
Modified:
/trunk/src/fr/README
/trunk/src/fr/book/ch01-fundamental-concepts.xml
/trunk/src/fr/book/ch03-advanced-topics.xml
=======================================
--- /trunk/src/fr/README Tue Jan 5 11:08:41 2010
+++ /trunk/src/fr/README Sun Feb 14 01:24:11 2010
@@ -49,6 +49,11 @@
http://jacques-andre.fr/faqtypo/lessons.pdf
+ Also :
+
+ Localisation des produits Sun, Guide stylistique pour le français
+ Révision F de juillet 2006
+ http://wikis.sun.com/downloads/attachments/58049199/FR_StyleGuide.pdf
V. VOCABULARY
=======================================
--- /trunk/src/fr/book/ch01-fundamental-concepts.xml Tue Jan 19 15:17:06
2010
+++ /trunk/src/fr/book/ch01-fundamental-concepts.xml Sun Feb 14 01:24:11
2010
@@ -5,7 +5,7 @@
connaissez rien à la gestion de versions, ce chapitre est à coup sûr
pour vous. Nous allons commencer par une présentation des notions
générales de la gestion de versions, puis étudier plus précisément
- les idées particulières qui se cachent derrière Subversion, et enfin
+ les idées particulières qui se cachent derrière Subversion et enfin
donner quelques exemples simples d'utilisation de Subversion.</para>
<para>Même si les exemples de ce chapitre mettent en scène des personnes
@@ -72,14 +72,14 @@
<para>La mission essentielle d'un logiciel de gestion de versions
est de permettre l'édition collaborative et le partage de données.
- Mais il existe différentes stratégies pour réaliser cela.
+ Mais il existe différentes stratégies pour arriver à cette fin.
Comprendre ces différentes stratégies est important pour
plusieurs raisons. Tout d'abord, cela vous aidera à comparer
et différencier les logiciels de gestion de versions existants,
au cas où vous rencontriez d'autres logiciels similaires à
Subversion. Ensuite, cela vous aidera également à utiliser plus
efficacement Subversion, puisque Subversion lui-même autorise
- différentes façons de travailler..</para>
+ différentes façons de travailler.</para>
<!-- ===============================================================
-->
<sect2 id="svn.basic.vsn-models.problem-sharing">
@@ -105,7 +105,7 @@
<emphasis>aucune </emphasis> des modifications effectuées par
Harry ne sera présente dans la nouvelle version du fichier de
Sally, car elle n'aura jamais vu les changements réalisés par
- Harry. De fait, le travail de Harry est perdu, ou du moins perdu
+ Harry. De fait, le travail de Harry est perdu ou, du moins, perdu
dans la version finale du fichier, et ceci probablement par
accident. Il s'agit précisément d'une situation que nous
voulons à tout prix éviter !</para>
@@ -132,7 +132,7 @@
modifier. Si Harry a verrouillé un fichier, alors Sally ne
pourra pas le verrouiller et ne pourra donc faire aucun
changement dessus. Tout ce qu'elle pourra faire sera de lire le
- fichier, et d'attendre que Harry ait fini ses changements et
+ fichier et d'attendre que Harry ait fini ses changements puis
libéré le verrou. Après que Harry ait libéré le fichier, Sally
pourra à son tour le verrouiller et l'éditer. La <xref
linkend="svn.basic.vsn-models.lock-unlock.dia-1"/> illustre
@@ -144,7 +144,7 @@
</figure>
<para>Le problème avec le modèle verrouiller-modifier-libérer
- est qu'il est relativement restrictif, et devient souvent un
+ est qu'il est relativement restrictif et devient souvent un
barrage pour les utilisateurs :</para>
<itemizedlist>
@@ -169,7 +169,7 @@
fichier texte et que Sally veut simplement éditer la fin
de ce même fichier ? Ces changements ne se chevauchent
pas du tout. Ils pourraient aisément éditer le fichier
- simultanément, et il n'y aurait pas beaucoup de dégâts,
+ simultanément et il n'y aurait pas beaucoup de dégâts,
en supposant que les changements soient correctement
fusionnés. Dans cette situation, il n'est pas nécessaire
de les forcer à éditer le fichier chacun à leur tour.</para>
@@ -189,7 +189,7 @@
qu'il ait d'une certaine manière instillé un faux sentiment
de sécurité. Il est facile pour Harry et Sally d'imaginer
qu'en verrouillant les fichiers, chacun commence une tâche
- isolée et sans danger, et donc que ce n'est pas la peine de
+ isolée, sans danger et donc que ce n'est pas la peine de
discuter à l'avance de leurs modifications incompatibles.
Verrouiller devient souvent un substitut à une réelle
communication.</para>
@@ -202,14 +202,14 @@
<sect2 id="svn.basic.vsn-models.copy-merge">
<title>Modèle copier-modifier-fusionner</title>
- <para>Subversion, CVS, et beaucoup d'autres logiciels de gestion
+ <para>Subversion, CVS et beaucoup d'autres logiciels de gestion
de versions utilisent le modèle
<firstterm>copier-modifier-fusionner</firstterm>
comme alternative au verrouillage. Dans ce modèle, chaque
utilisateur contacte le dépôt du projet via son client et
crée une copie de travail personnelle, une sorte de version
locale des fichiers et répertoires du dépôt. Les utilisateurs
- peuvent alors travailler simultanément et indépendamment les
+ peuvent alors travailler, simultanément et indépendamment les
uns des autres, et modifier leurs copies privées. Pour finir,
les copies privées sont fusionnées au sein d'une nouvelle
version finale. Le logiciel de gestion de versions fournit de
@@ -251,11 +251,11 @@
empiètent sur celles de Harry ? Que fait-on dans ce
cas-là ? Cette situation est appelée un
<firstterm>conflit</firstterm>
- et ce n'est en général pas un gros problème. Lorsque Harry
- demandera à son logiciel client de fusionner les changements
+ et ne constitue pas, en général, un gros problème. Lorsque Harry
+ demande à son logiciel client de fusionner les changements
les plus récents du dépôt dans sa copie de travail, sa copie
- du fichier sera en quelque sorte marquée comme étant dans un
- état de conflit : il aura la possibilité de voir les deux
+ du fichier est en quelque sorte marquée comme étant dans un
+ état de conflit : il a la possibilité de voir les deux
ensembles de changements entrant en conflit et de choisir
manuellement entre les deux. Notez bien qu'un logiciel ne
peut pas résoudre automatiquement les conflits ; seuls les
@@ -266,7 +266,7 @@
en toute sécurité dans le dépôt.</para>
<para>Le modèle copier-modifier-fusionner peut sembler un peu
- chaotique, mais en pratique, il fonctionne de façon très
+ chaotique mais, en pratique, il fonctionne de façon très
fluide. Les utilisateurs peuvent travailler en parallèle, sans
jamais devoir s'attendre les uns les autres. Lorsqu'ils
travaillent sur les mêmes fichiers, il s'avère que la plupart
@@ -279,7 +279,7 @@
communication entre les utilisateurs. Lorsque les utilisateurs
communiquent mal, les conflits syntaxiques et sémantiques
augmentent. Aucun système ne peut forcer les utilisateurs à
- communiquer parfaitement, et aucun système ne peut détecter
+ communiquer parfaitement et aucun système ne peut détecter
les conflits sémantiques. Il n'y a donc aucun intérêt à se
laisser endormir par un faux sentiment de sécurité selon
lequel un système de verrouillage permettrait d'éviter les
@@ -287,7 +287,7 @@
productivité plus qu'aucun autre facteur.</para>
<sidebar id="svn.basic.vsn-models.copy-merge.sb-1">
- <title>Quand verrouiller est nécessaire</title>
+ <title>Le verrouillage est parfois nécessaire</title>
<para>Même si le modèle verrouiller-modifier-libérer est en
général considéré comme pénalisant pour la collaboration, il
@@ -309,7 +309,7 @@
<para>Bien que Subversion soit avant tout un système
copier-modifier-fusionner, il reconnaît toutefois la
nécessité du verrouillage pour certains fichiers et fournit
- donc un mécanisme pour cela. Cette fonctionnalité sera
+ donc un mécanisme pour cela. Cette fonctionnalité est
traitée plus tard dans ce livre, dans <xref
linkend="svn.advanced.locking"/>.</para>
@@ -328,14 +328,14 @@
<title>Subversion en action</title>
<para>Il est temps de passer de l'abstrait au concret. Dans cette
- section, nous allons vous montrer des exemples réels
+ section, nous vous montrons des exemples réels
d'utilisation de Subversion.</para>
<!-- ===============================================================
-->
<sect2 id="svn.advanced.reposurls">
<title>URL des dépôts Subversion</title>
- <para>Tout au long de ce livre, Subversion va utiliser des URL
+ <para>Tout au long de ce livre, Subversion utilise des URL
pour identifier des fichiers et des répertoires suivis en
version au sein de dépôts Subversion. Pour la plupart, ces URL
utilisent la syntaxe standard, permettant de spécifier les
@@ -363,7 +363,7 @@
</screen>
<para>D'autre part, les utilisateurs du procédé
- <literal>file://</literal> sur les plateformes Windows devront
+ <literal>file://</literal> sur les plateformes Windows doivent
se servir d'une syntaxe qui est un <quote>standard</quote>
officieux pour accéder à leurs dépôts se trouvant sur la même
machine mais sur un disque différent du disque de travail
@@ -378,13 +378,13 @@
…
</screen>
- <para>Dans la seconde syntaxe, vous aurez besoin d'entourer
+ <para>Dans la seconde syntaxe, vous devez entourer
l'URL de guillemets pour éviter que la barre verticale ne soit
interprétée comme un symbole de redirection (un
<quote>pipe</quote>). De plus, remarquez qu'une URL utilise
- des barres obliques (ou <quote>slash</quote>) alors que la
+ des barres obliques (<literal>/</literal>) alors que la
forme native (non-URL) d'un chemin sous Windows utilise des
- barres obliques inversées (ou <quote>antislash</quote>).</para>
+ barres obliques inversées (<literal>\</literal>).</para>
<note>
<para>Les URL Subversion <literal>file://</literal> ne
@@ -396,13 +396,13 @@
cet emplacement en interrogeant directement le système de
fichiers. Cependant, les ressources de Subversion existent
dans un système de fichier virtuel (cf. <xref
- linkend="svn.developer.layerlib.repos" />), et votre
- navigateur ne va pas comprendre comment interagir avec ce
+ linkend="svn.developer.layerlib.repos" />) et votre
+ navigateur ne comprend pas comment interagir avec ce
système de fichiers.</para>
</note>
- <para>Enfin, il faut noter que le client Subversion va
- automatiquement encoder les URL en cas de besoin, exactement
+ <para>Enfin, il faut noter que le client Subversion encode
+ automatiquement les URL en cas de besoin, exactement
comme le fait un navigateur web. Par exemple, si une URL
contient un espace ou un caractère ASCII spécial, comme dans
ce qui suit :</para>
@@ -411,8 +411,8 @@
$ svn checkout "http://hote/chemin avec espace/projet/españa"
</screen>
- <para>alors Subversion va banaliser les caractères spéciaux et
- se comporter comme si vous aviez tapé :</para>
+ <para>alors Subversion banalise les caractères spéciaux et
+ se comporte comme si vous aviez tapé :</para>
<screen>
$ svn checkout http://hote/chemin%20avec%20espace/projet/espa%C3%B1a
@@ -447,38 +447,38 @@
<tbody>
<row>
<entry><literal>file:///</literal></entry>
- <entry>Accès direct au dépôt (sur un disque local)
+ <entry>Accès direct au dépôt (sur un disque local).
</entry>
</row>
<row>
<entry><literal>http://</literal></entry>
<entry>Accès via le protocole WebDAV à un serveur
- Apache configuré pour Subversion</entry>
+ Apache configuré pour Subversion.</entry>
</row>
<row>
<entry><literal>https://</literal></entry>
<entry>Identique à <literal>http://</literal>, mais
- avec chiffrement SSL</entry>
+ avec chiffrement SSL.</entry>
</row>
<row>
<entry><literal>svn://</literal></entry>
<entry>Accès via un protocole personnalisé à un
- serveur <literal>svnserve</literal></entry>
+ serveur <literal>svnserve</literal>.</entry>
</row>
<row>
<entry><literal>svn+ssh://</literal></entry>
<entry>Identique à <literal>svn://</literal>, mais à
- travers un tunnel SSH</entry>
+ travers un tunnel SSH.</entry>
</row>
</tbody>
</tgroup>
</table>
<para>Pour plus d'informations sur la façon dont Subversion
- analyse les URL, se reporter à <xref
+ analyse les URL, reportez-vous à <xref
linkend="svn.advanced.reposurls"/>. Pour plus d'informations
sur les différents types de serveurs réseau disponibles
- pour Subversion, se reporter au <xref
+ pour Subversion, reportez-vous au <xref
linkend="svn.serverconfig"/>.</para>
</sidebar>
@@ -496,17 +496,17 @@
<para>Une copie de travail Subversion est une arborescence
classique de répertoires de votre système local, contenant un
ensemble de fichiers. Vous pouvez éditer ces fichiers comme
- vous le voulez, et s'il s'agit de code source, vous pouvez
+ vous le voulez et, s'il s'agit de code source, vous pouvez
compiler votre programme à partir de ceux-ci de la façon
habituelle. Votre copie de travail est votre espace de travail
personnel privé : Subversion n'y incorporera jamais les
- changements d'autres personnes, ni ne rendra jamais disponibles
- vos propres changements à d'autres personnes, tant que vous ne
+ changements d'autres personnes ni ne rendra jamais disponibles
+ vos propres changements à d'autres personnes tant que vous ne
lui demanderez pas explicitement de le faire. Vous pouvez même
avoir plusieurs copies de travail d'un même projet.</para>
<para>Après que vous ayez apporté quelques modifications aux
- fichiers de votre copie de travail, et vérifié qu'elles
+ fichiers de votre copie de travail et vérifié qu'elles
fonctionnent correctement, Subversion vous fournit des
commandes pour <quote>publier</quote> vos changements vers
les autres personnes qui travaillent avec vous sur votre
@@ -523,14 +523,14 @@
administratif</firstterm> de votre copie de travail. Les
fichiers de chacun de ces répertoires administratifs permettent
à Subversion d'identifier quels fichiers contiennent des
- modifications non-publiées, et quels fichiers sont périmés
+ modifications non-publiées et quels fichiers sont périmés
vis-à-vis du travail des autres personnes.</para>
<para>Un dépôt Subversion contient bien souvent les fichiers
(ou code source) de plusieurs projets ; habituellement,
chaque projet est un sous-répertoire de l'arborescence du
système de fichiers du dépôt. Dans cette situation, la copie
- de travail d'un utilisateur correspondra à une
+ de travail d'un utilisateur correspond à une
sous-arborescence particulière du dépôt.</para>
<para>Par exemple, supposons que votre dépôt contienne deux
@@ -551,8 +551,8 @@
que cela a quelque chose à voir avec verrouiller ou réserver
des ressources, mais ce n'est pas le cas ; cela crée
simplement pour vous une copie privée du projet). Par exemple,
- si vous extrayez <filename>/calc</filename>, vous obtiendrez
- une copie de travail qui ressemblera à ceci :</para>
+ si vous extrayez <filename>/calc</filename>, vous obtenez
+ une copie de travail qui ressemble à ceci :</para>
<screen>
$ svn checkout http://svn.exemple.com/depot/calc
@@ -583,8 +583,8 @@
vous ne lui dites pas de le faire. L'action de publication de
vos modifications est plus communément appelée
<firstterm>propagation</firstterm> (<quote>commit</quote> ou
- <quote>check in</quote> en anglais, et parfois
- <firstterm>archivage</firstterm> , ou
+ <quote>check in</quote> en anglais et, parfois,
+ <firstterm>archivage</firstterm> ou
<firstterm>livraison</firstterm> en français) des
modifications au sein du dépôt.</para>
@@ -602,7 +602,7 @@
<para>À présent, vos modifications de
<filename>bouton.c</filename> ont été propagées au sein du
dépôt, avec un commentaire décrivant ces changements
- (c'est-à-dire, que vous avez corrigé une coquille). Si un
+ (<quote>vous avez corrigé une coquille</quote>). Si un
autre utilisateur extrait une copie de travail de
<filename>/calc/</filename>, il va voir vos modifications dans
la dernière version du fichier.</para>
@@ -678,7 +678,7 @@
une vue intéressante du dépôt. Imaginez un tableau de numéros
de révisions, commençant à 0 et s'étirant de la gauche vers la
droite. Chaque numéro de révision correspond à une arborescence
- de système de fichiers située en-dessous de lui, et chaque
+ de système de fichiers située en-dessous de lui et chaque
arborescence est une photo, un <quote>instantané</quote>
(<quote>snapshot</quote> en anglais) du dépôt prise après une
propagation.</para>
@@ -693,7 +693,7 @@
<para>Contrairement à la plupart des logiciels de gestion de
versions, les numéros de révision de Subversion s'appliquent
- à <emphasis>l'arborescence toute entière</emphasis>, et non
+ à <emphasis>l'arborescence toute entière</emphasis> et non
à chaque fichier individuellement. À chaque numéro de révision
correspond une arborescence toute entière, un état particulier
du dépôt après une propagation. Une autre façon de voir cela
@@ -728,11 +728,11 @@
<para>À cet instant, le répertoire de travail correspond
exactement à la révision 4 du dépôt. Néanmoins, supposons que
- vous modifiiez <filename>bouton.c</filename>, et que vous
+ vous modifiiez <filename>bouton.c</filename> et que vous
propagiez cette modification. En supposant qu'aucune autre
- propagation n'a eu lieu, votre propagation va créer la
- révision 5 du dépôt, et votre copie de travail va maintenant
- ressembler à ceci :</para>
+ propagation n'a eu lieu, votre propagation crée la
+ révision 5 du dépôt et votre copie de travail ressemble
+ maintenant à ceci :</para>
<screen>
calc/Makefile:4
@@ -743,8 +743,8 @@
<para>Supposons maintenant qu'à ce moment précis, Sally propage
une modification d'<filename>entier.c</filename>, créant la
révision 6. Si vous utilisez <command>svn update</command>
- pour mettre à jour votre copie de travail, elle va alors
- ressembler à ceci :</para>
+ pour mettre à jour votre copie de travail, elle ressemble alors
+ à ceci :</para>
<screen>
calc/Makefile:6
@@ -753,15 +753,15 @@
</screen>
<para>Les modifications apportées par Sally à
- <filename>entier.c</filename> vont apparaître dans votre copie
- de travail, et vos modifications seront toujours présentes dans
+ <filename>entier.c</filename> apparaissent dans votre copie
+ de travail et vos modifications sont toujours présentes dans
<filename>bouton.c</filename>. Dans cet exemple, le texte de
<filename>Makefile</filename> est identique dans les révisions
- 4, 5 et 6, mais Subversion va marquer votre copie de travail
+ 4, 5 et 6 mais Subversion marque votre copie de travail
de <filename>Makefile</filename> comme étant à la révision 6
pour indiquer qu'elle est à jour. Ainsi, quand vous effectuez
une mise à jour au niveau de la racine de votre copie de
- travail, celle-ci correspondra en général à une révision
+ travail, celle-ci correspond en général à une révision
donnée du dépôt.</para>
</sect2>
@@ -769,8 +769,7 @@
<!-- ===============================================================
-->
<sect2 id="svn.basic.in-action.track-repos">
- <title>Comment les copies de travail suivent l'évolution du
- dépôt</title>
+ <title>Les copies de travail suivent l'évolution du dépôt</title>
<para>Pour chaque fichier d'un répertoire de travail, Subversion
enregistre deux informations essentielles dans la zone
@@ -799,7 +798,7 @@
<listitem>
<para>Le fichier est inchangé dans le répertoire de
- travail, et aucune modification de ce fichier n'a été
+ travail et aucune modification de ce fichier n'a été
propagée vers le dépôt depuis sa révision de travail. Un
appel à <command>svn commit</command> sur le fichier ne
fera rien, un appel à <command>svn update</command> sur
@@ -812,12 +811,12 @@
<listitem>
<para>Le fichier a été modifié dans le répertoire de
- travail, et aucune modification du fichier n'a été
+ travail et aucune modification du fichier n'a été
propagée dans le dépôt depuis la dernière mise à jour.
Il existe des modifications locales qui n'ont pas été
propagées vers le dépôt, donc un appel à
<command>svn commit</command> sur le fichier permettra
- de publier vos modifications, et un appel à
+ de publier vos modifications et un appel à
<command>svn update</command> ne fera rien.</para>
</listitem>
</varlistentry>
@@ -827,11 +826,11 @@
<listitem>
<para>Le fichier n'a pas été modifié dans le répertoire
- de travail, mais a changé dans le dépôt. Le fichier
+ de travail mais a changé dans le dépôt. Le fichier
devra être mis à jour à un moment ou à un autre, pour
l'amener au niveau de la dernière révision publique.
Un appel à <command>svn commit</command> sur le
- fichier ne fera rien, et un appel à
+ fichier ne fera rien et un appel à
<command>svn update</command> incorporera les dernières
modifications dans votre copie de travail.</para>
</listitem>
@@ -857,8 +856,8 @@
</varlistentry>
</variablelist>
- <para>Tout ceci pourrait sembler compliqué à gérer, mais la
- commande <command>svn status</command> vous indiquera dans
+ <para>Tout ceci peut sembler compliqué à gérer mais la
+ commande <command>svn status</command> vous indique dans
quel état se trouve n'importe quel élément de votre copie de
travail. Pour plus d'informations sur cette commande,
référez-vous à <xref
@@ -871,7 +870,7 @@
<title>Copies de travail mixtes, à révisions mélangées</title>
<para>Un principe général de Subversion est d'être aussi
- flexible que possible. Un type particulierr de flexibilité est
+ flexible que possible. Un type particulier de flexibilité est
la capacité d'avoir une copie de travail contenant des fichiers
et des répertoires avec un mélange de différents numéros de
révision. Malheureusement, cette flexibilité a tendance à
@@ -883,7 +882,7 @@
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-->
<sect3 id="svn.basic.in-action.mixedrevs.update-commit">
- <title>Mises à jour et propagations sont deux choses
+ <title>Mises à jour et propagation sont deux choses
distinctes</title>
<para>Une des règles fondamentales de Subversion est que
@@ -893,7 +892,7 @@
au dépôt ne veut pas dire que vous êtes prêts à recevoir
les modifications d'autres personnes. Et si vous avez de
nouvelles modifications encore en cours, alors
- <command>svn update</command> va élégamment fusionner les
+ <command>svn update</command> fusionne élégamment les
changements du dépôt avec les vôtres, plutôt que de vous
forcer à les publier.</para>
@@ -902,12 +901,12 @@
effectuer pour suivre les mélanges de révision et également
être tolérante vis-à-vis de l'ensemble. Cela est rendu
encore plus difficile par le fait que les répertoires
- eux-mêmes sont suivis en version.</para>
+ eux-mêmes sont suivis en versions.</para>
<para>Par exemple, supposons que vous ayez une copie de travail
qui soit intégralement à la révision 10. Vous éditez le
fichier <filename>truc.html</filename> et réalisez ensuite
- un <command>svn commit</command>, qui crée la révision 15
+ un <command>svn commit</command> qui crée la révision 15
dans le dépôt. Après que la propagation ait réussi, nombreux
sont ceux parmi les nouveaux utilisateurs qui s'attendraient
à ce que toute la copie de travail soit à la révision 15,
@@ -915,17 +914,17 @@
modifications ont pu avoir lieu dans le dépôt entre les
révisions 10 et 15. Le client ne sait rien de ces changements
qui ont été apportés au dépôt, puisque vous n'avez pas encore
- exécuté la commande <command>svn update</command>, et la
+ exécuté la commande <command>svn update</command> et la
commande <command>svn commit</command> ne récupère pas les
nouvelles modifications. D'un autre côté, si la commande
<command>svn commit</command> téléchargeait automatiquement
les modifications les plus récentes, alors il serait
possible d'avoir toute la copie de travail à la révision
- 15, mais dans ce cas, nous enfreindrions la règle
+ 15 mais, dans ce cas, nous enfreindrions la règle
fondamentale selon laquelle <quote>pousser</quote> et
<quote>tirer</quote> doivent demeurer des actions
distinctes. Ainsi, la seule chose que le client Subversion
- peut faire en toute sécurité est de marquer le fichier,
+ peut faire en toute sécurité est de marquer le fichier
<filename>truc.html</filename>, et lui seulement, comme étant
à la révision 15. Le reste de la copie de travail reste à la
révision 10. Seule l'exécution de la commande
@@ -957,7 +956,7 @@
<para>Souvent, les nouveaux utilisateurs n'ont pas du tout
conscience que leur copie de travail contient des révisions
- mélangées. Cela peut être déroutant, car beaucoup de
+ mélangées. Cela peut être déroutant car beaucoup de
commandes client sont sensibles à la révision de travail de
l'élément qu'elles examinent. Par exemple, la commande
<command>svn log</command> est utilisée pour afficher
@@ -985,9 +984,9 @@
version plus ancienne que celle que vous avez déjà) sur
certaines parties de votre copie de travail vers des
révisions plus anciennes ; vous apprendrez comme le faire
- dans le <xref linkend="svn.tour"/>. Vous aurez peut-être envie
+ dans le <xref linkend="svn.tour"/>. Vous avez peut-être envie
de tester une version précédente d'un sous-module contenu
- dans un sous-répertoire, ou bien de comprendre comment un
+ dans un sous-répertoire ou bien de comprendre comment un
bogue est apparu pour la première fois dans un fichier
donné. C'est le côté
<quote>machine à voyager dans le temps</quote> d'un
@@ -999,7 +998,7 @@
<!-- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
-->
<sect3 id="svn.basic.in-action.mixedrevs.limits">
- <title>Les mélanges de révision ont des limites </title>
+ <title>Les mélanges de révisions ont des limites</title>
<para>Quelle que soit la façon dont vous utilisez les
mélanges de révision dans votre copie de travail, il existe
@@ -1009,7 +1008,7 @@
suppression d'un fichier ou d'un répertoire qui n'est pas
complètement à jour. Si une version plus récente de
l'élément existe dans le dépôt, votre tentative de
- suppression sera rejetée, afin de vous empêcher de détruire
+ suppression est rejetée, afin de vous empêcher de détruire
accidentellement des modifications dont vous n'aviez pas
encore connaissance.</para>
@@ -1019,7 +1018,7 @@
<quote>propriétés</quote> à des éléments dans le
<xref linkend="svn.advanced"/>. La révision de travail d'un
répertoire définit un ensemble précis d'entrées et de
- propriétés, et propager la modification d'une propriété
+ propriétés et propager la modification d'une propriété
d'un répertoire périmé risquerait de détruire des
propriétés dont vous n'aviez pas encore connaissance.</para>
@@ -1041,7 +1040,7 @@
<itemizedlist>
<listitem>
<para>Nous avons introduit les notions de dépôt central, de
- copie de travail du client, et d'ensemble des révisions de
+ copie de travail du client et d'ensemble des révisions de
l'arborescence du dépôt.</para>
</listitem>
@@ -1062,8 +1061,8 @@
<para>À présent, vous avez probablement une bonne idée générale
de la façon dont Subversion fonctionne. Armé de cette
- connaissance, vous devriez désormais être prêt à passer au
- chapitre suivant, qui traite en détail des commandes et des
+ connaissance, vous devez désormais être prêt à passer au
+ chapitre suivant qui traite en détail des commandes et des
fonctionnalités de Subversion.</para>
</sect1>
=======================================
--- /trunk/src/fr/book/ch03-advanced-topics.xml Thu Feb 11 09:59:07 2010
+++ /trunk/src/fr/book/ch03-advanced-topics.xml Sun Feb 14 01:24:11 2010
@@ -21,7 +21,7 @@
<para>Ce chapitre dévoile certaines fonctionnalités de Subversion qui,
bien qu'importantes, ne sont pas d'une utilisation quotidienne pour
- un utilisateur normal. Nous supposerons que vous êtes familier avec
+ un utilisateur normal. Nous supposons que vous êtes familier avec
les possibilités de base de gestion de versions sur les fichiers et
répertoires. Sinon, reportez-vous au <xref linkend="svn.basic" />
et au <xref linkend="svn.tour" />. Une fois que vous maîtriserez ces
@@ -51,7 +51,7 @@
Subversion, soit dans un autre contexte qui donnait du sens à ce
numéro particulier.</para>
- <para>Occasionnellement, vous aurez besoin d'identifier un moment
+ <para>Occasionnellement, vous avez besoin d'identifier un moment
précis pour lequel vous n'avez pas de numéro de révision en tête
ou sous la main. C'est pourquoi, en plus des numéros de révision,
<command>svn</command> accepte également en entrée d'autres
@@ -149,7 +149,7 @@
revanche,<literal>HEAD</literal> peut être utilisé avec les deux
types de chemin (local ou URL du dépôt).</para>
- <para>Vous trouverez ci-dessous des exemples de l'utilisation de
+ <para>Vous trouvez ci-dessous des exemples de l'utilisation de
ces mots-clés :</para>
<screen>
@@ -193,15 +193,15 @@
</indexterm>
<para>Les numéros de révision n'ont aucune signification en dehors
- du système de gestion de versions. Cependant, parfois, vous aurez
+ du système de gestion de versions. Cependant, parfois, vous avez
besoin d'associer une date réelle à un moment précis de
l'historique des versions. Pour ça, l'option
<option>--revision</option>(<option>-r</option>) accepte comme
argument une date placée entre accolades (<literal>{</literal> et
<literal>}</literal>). Subversion accepte les dates et les heures
- aux formats définis dans le standard ISO-8601, et quelques autres
- formats. Voici quelques exemples (n'oubliez pas de mettre les
- dates qui contiennent des espaces entre
+ aux formats définis dans le standard ISO-8601 ainsi que quelques
+ autres formats. Voici quelques exemples (n'oubliez pas de mettre
+ les dates qui contiennent des espaces entre
guillemets) :</para>
<screen>
@@ -236,14 +236,14 @@
<para>Si vous spécifiez une date de révision sans préciser
l'heure (par exemple <literal>2006-11-27</literal>), vous
- pourriez penser que Subversion vous donnera la dernière
+ pourriez penser que Subversion vous donne la dernière
révision qui a eu lieu le 27 novembre. En fait, vous aurez une
révision datant du 26, voire même avant. Souvenez-vous que
Subversion renvoie <emphasis>la révision la plus récente du
dépôt</emphasis> à la date spécifiée. Si vous spécifiez une
date sans préciser l'heure, comme <literal>2006-11-27</literal>,
Subversion utilise alors 00h00 comme heure, et la recherche de
- la plus récente révision ne renverra donc pas de résultat
+ la plus récente révision ne renvoit donc pas de résultat
correspondant au 27 novembre.</para>
<para>Si vous voulez inclure le 27 dans votre recherche, vous
@@ -254,7 +254,7 @@
</sidebar>
<para>Vous pouvez également utiliser des intervalles de dates.
- Subversion trouvera alors les révisions incluses entre ces deux
+ Subversion trouve alors les révisions incluses entre ces deux
dates :</para>
<screen>
@@ -264,7 +264,7 @@
<warning>
<para>Puisque l'horodatage d'une révision est stocké comme une
- propriété modifiable et non suivi en versions de la révision
+ propriété modifiable et non suivie en versions de la révision
(reportez-vous à <xref linkend="svn.advanced.props" />), les
horodatages peuvent être changés et ne pas refléter la
chronologie réelle. Ils peuvent même être tous supprimés. Or
@@ -308,7 +308,7 @@
propriétés à des valeurs arbitraires, pour chaque élément de votre
copie de travail. En termes simples, vous pouvez assigner n'importe
quel nom et n'importe quelle valeur à vos propriétés, à la seule
- condition que le nom doit être un texte lisible par un humain. Et
+ condition que le nom soit un texte lisible par un humain. Et
l'atout principal de ces propriétés réside dans le fait qu'elles
sont également suivies en versions, tout comme le contenu textuel
de vos fichiers. Vous pouvez modifier, propager et revenir en
@@ -322,7 +322,7 @@
<para>Subversion a réservé pour son propre usage les propriétés
dont le nom commence par <literal>svn:</literal>. Bien qu'il n'y
en ait seulement que quelques unes d'utilisées actuellement,
- vous ne devriez pas créer vos propres propriétés avec un nom
+ vous ne devez pas créer vos propres propriétés avec un nom
commençant par ce préfixe. Sinon, vous courrez le risque qu'une
future version de Subversion définisse une propriété ayant le
même nom mais avec un usage tout autre.</para>
@@ -342,22 +342,22 @@
<para>Subversion ne fournit pas de recommandation précise quant à
l'utilisation des propriétés. Il demande seulement de ne pas
utiliser de nom de propriété qui commence par le préfixe
- <literal>svn:</literal>. C'est l'espace de noms qu'il garde pour
- son propre usage. Et Subversion utilise bien lui-même les
- propriétés, suivies en versions ou pas. Certaines propriétés
- suivies en versions ont une signification particulière ou des
- effets particuliers quand elles font référence à un fichier ou à
- un répertoire, ou stockent des informations relatives à la
- révision à laquelle elles font référence. Certaines propriétés de
- révision sont automatiquement rattachées à une révision par la
- procédure de propagation et stockent des informations relatives à
- cette révision. La plupart de ces propriétés sont mentionnées
- ailleurs dans ce chapitre ou dans d'autres chapitres comme faisant
- partie de sujets plus généraux. Pour une liste exhaustive des
- propriétés pré-définies de Subversion, référez-vous à
- <xref linkend="svn.ref.properties" />.</para>
-
- <para>Dans cette section, nous examinerons l'utilité des propriétés,
+ <literal>svn:</literal>. C'est l'espace de noms qu'il garde pour
+ on propre usage. Et Subversion utilise bien lui-même les
+ propriétés, suivies en versions ou pas. Certaines propriétés
+ suivies en versions ont une signification particulière ou des
+ effets particuliers quand elles font référence à un fichier ou à
+ un répertoire, ou stockent des informations relatives à la
+ révision à laquelle elles font référence. Certaines propriétés de
+ révision sont automatiquement rattachées à une révision par la
+ procédure de propagation et stockent des informations relatives à
+ cette révision. La plupart de ces propriétés sont mentionnées
+ ailleurs dans ce chapitre ou dans d'autres chapitres comme faisant
+ partie de sujets plus généraux. Pour une liste exhaustive des
+ propriétés pré-définies de Subversion, référez-vous à
+ <xref linkend="svn.ref.properties" />.</para>
+
+ <para>Dans cette section, nous examinons l'utilité des propriétés,
à la fois pour l'utilisateur et pour Subversion lui-même. Vous
apprendrez les sous-commandes <command>svn</command> relatives aux
propriétés et comment la modification des propriétés change votre
@@ -365,29 +365,29 @@
<!-- ===============================================================
-->
<sect2 id="svn.advanced.props.why">
- <title>Pourquoi des propriétés ?</title>
+ <title>Utilisation des propriétés</title>
<para>À l'instar de Subversion, qui utilise les propriétés
pour stocker des méta-données sur les fichiers, les répertoires
- et les révisions qu'il gère, vous pourriez faire une utilisation
- similaire des propriétés. Vous pourriez trouver utile d'avoir un
+ et les révisions qu'il gère, vous pouvez faire une utilisation
+ similaire des propriétés. Vous pouvez trouver utile d'avoir un
endroit, près de vos données suivies en versions, pour stocker
des méta-données relatives à vos données.</para>
<para>Imaginons que vous vouliez créer un site Web qui héberge
beaucoup de photos et qui les affiche avec une légende et une
date. D'accord, mais votre collection de photos change constamment,
- donc vous voudriez automatiser le plus possible la gestion du
+ donc vous voulez automatiser le plus possible la gestion du
site. Ces photos peuvent être relativement volumineuses et vous
voulez pouvoir fournir des miniatures à vos visiteurs, comme
c'est généralement le cas sur ce genre de sites.</para>
<para>Certes, vous pouvez le faire en utilisant des fichiers
- traditionnels. C'est-à-dire que vous aurez votre
+ traditionnels. C'est-à-dire que vous avez votre
<filename>image123.jpg</filename> et une
<filename>image123-thumbnail.jpg</filename> côte à côte dans un
répertoire. Ou, si vous voulez garder les mêmes noms de fichier,
- vous placerez vos miniatures dans un répertoire différent, comme
+ vous placez vos miniatures dans un répertoire différent, comme
<filename>thumbnails/image123.jpg</filename>. Vous pouvez
également stocker vos légendes et dates de la même façon,
séparées encore une fois du fichier image original. Mais le
@@ -454,13 +454,13 @@
Trouver une propriété personnalisée suivie en versions est
également difficile et implique souvent un appel récursif à
<command>svn propget</command> sur toute une copie de travail.
- Dans votre situation, ce pourrait être moins pire que le
+ Dans votre situation, c'est peut-être moins pire que le
parcours linéaire de toutes les révisions. Mais cela laisse
certainement beaucoup à désirer en termes de performance et de
probabilité de réussite, surtout si, pour votre recherche, il
faut une copie de travail de la racine de votre dépôt.</para>
- <para>C'est pourquoi, vous pourriez choisir, en particulier pour
+ <para>C'est pourquoi, vous pouvez choisir, en particulier pour
ce qui concerne les propriétés de révisions, de simplement
ajouter les méta-données au message de propagation. Par
exemple, utilisez une politique de formatage (idéalement
@@ -490,7 +490,7 @@
<!-- ===============================================================
-->
<sect2 id="svn.advanced.props.manip">
- <title>Manipuler les propriétés</title>
+ <title>Manipulation des propriétés</title>
<para>La commande <command>svn</command> offre différentes
possibilités pour ajouter ou modifier des propriétés sur les
@@ -547,8 +547,8 @@
de texte pour y placer votre nouvelle valeur, sauvegarder le
fichier temporaire et quitter l'éditeur. Si Subversion détecte
que la valeur a effectivement changé, il la prend en compte. Si
- vous quittez l'éditeur sans faire de changement, la propriété ne
- sera pas modifiée :</para>
+ vous quittez l'éditeur sans faire de changement, la propriété
+ n'est pas modifiée :</para>
<screen>
$ svn propedit copyright calc/bouton.c ### sortez de l'éditeur sans faire
de modification
@@ -736,7 +736,7 @@
quand vous les propagez dans le dépôt via
<command>svn commit</command>. Vos modifications sur les
propriétés peuvent aussi être annulées facilement : la
- commande <command>svn revert</command> restaurera vos fichiers
+ commande <command>svn revert</command> restaure vos fichiers
et répertoires dans leur état d'avant les modifications, y
compris pour les propriétés. Vous pouvez également obtenir des
informations intéressantes sur l'état des propriétés de vos
@@ -774,7 +774,7 @@
collaborateurs. Si vous faites une mise à jour de votre copie
de travail et que vous recevez un changement incompatible avec
vos propres modifications d'une propriété d'un objet suivi en
- versions, Subversion vous indiquera que l'objet est dans un
+ versions, Subversion vous indique que l'objet est dans un
état de conflit.</para>
<screen>
@@ -785,14 +785,14 @@
$
</screen>
- <para>Subversion créera également, dans le même répertoire que
+ <para>Subversion crée également, dans le même répertoire que
l'objet en conflit, un fichier avec l'extension
- <filename>.prej</filename> qui contiendra les détails du
- conflit. Vous devrez examiner le contenu de ce fichier pour
- décider comment résoudre le conflit. Tant que le conflit ne
- sera pas résolu, la sortie de <command>svn status</command>
- affichera un <literal>C</literal> dans la deuxième colonne pour
- cet objet et vos tentatives de propagation échoueront.</para>
+ <filename>.prej</filename> qui contient les détails du
+ conflit. Vous devez examiner le contenu de ce fichier pour
+ décider comment résoudre le conflit. Tant que le conflit
+ n'est pas résolu, la sortie de <command>svn status</command>
+ affiche un <literal>C</literal> dans la deuxième colonne pour
+ cet objet et vos tentatives de propagation échouent.</para>
<screen>
$ svn status calc
@@ -813,9 +813,9 @@
<para>Vous avez peut-être remarqué que Subversion affiche les
différences au niveau des propriétés d'une manière non standard.
- Certes, vous pouvez toujours re-diriger la sortie de
+ Certes, vous pouvez toujours rediriger la sortie de
<command>svn diff</command> pour créer un fichier patch
- utilisable : le programme patch ignorera ce qui concerne les
+ utilisable : le programme patch ignore ce qui concerne les
propriétés (comme il ignore tout ce qu'il ne comprend pas).
Malheureusement, cela signifie aussi que pour appliquer
intégralement un patch généré par
@@ -826,12 +826,12 @@
<!-- ===============================================================
-->
<sect2 id="svn.advanced.props.auto">
- <title>Configurer des propriétés de façon automatique</title>
+ <title>Configuration automatique des propriétés</title>
<para>Les propriétés constituent une fonctionnalité très puissante
- de Subversion, et sont un élément central de nombreuses
+ de Subversion et sont un élément central de nombreuses
fonctionnalités de Subversion présentées ailleurs dans ce
- chapitre et dans les autres chapitres : comparaisons et
+ chapitre ainsi que dans les autres chapitres : comparaisons et
fusions textuelles, substitution de mots-clés, transformation des
retours à la ligne, etc. Mais pour profiter pleinement des
propriétés, il faut les placer sur les répertoires et fichiers
@@ -849,7 +849,7 @@
en configurant automatiquement certaines propriétés communes des
fichiers. D'abord, sur les systèmes d'exploitation dont le
système de fichiers utilise un bit <quote>exécutable</quote>,
- Subversion ajoutera automatiquement la propriété
+ Subversion ajoute automatiquement la propriété
<literal>svn:executable</literal> aux nouveaux fichiers, ajoutés
ou importés, qui ont ce bit activé (voir <xref
linkend="svn.advanced.props.special.executable" /> pour plus de
@@ -857,9 +857,9 @@
<para>Ensuite, Subversion essaie de déterminer le type MIME du
fichier. Si vous avez configuré le paramètre
- <literal>mime-types-files</literal>, Subversion essaiera de
+ <literal>mime-types-files</literal>, Subversion essaie de
trouver un type MIME correspondant à l'extension du nom de
- fichier. Si un tel type MIME existe, il définira
+ fichier. Si un tel type MIME existe, il définit
automatiquement la propriété <literal>svn:mime-type</literal>
avec la valeur du type trouvé. S'il ne trouve pas de type MIME
correspondant ou s'il n'existe pas de fichier définissant les
@@ -870,7 +870,7 @@
ce fichier avec la valeur
<literal>application/octet-stream</literal> (type MIME générique
indiquant <quote>une suite d'octets</quote>). Bien sûr, si
- Subversion se trompe, ou si vous voulez indiquer un type plus
+ Subversion se trompe ou si vous voulez indiquer un type plus
précis (par exemple <literal>image/png</literal> ou
<literal>application/x-shockwave-flash</literal>), vous pouvez
toujours supprimer ou modifier cette propriété. (Pour d'avantage
@@ -881,21 +881,21 @@
<para>Subversion fournit également, via sa zone de configuration
(voir <xref linkend="svn.advanced.confarea" />), une fonction de
- renseignement automatique des propriétés plus flexible, qui vous
- permet de créer des associations entre d'une part des motifs de
- noms de fichiers et d'autre part des noms de
+ renseignement automatique des propriétés plus flexible qui vous
+ permet de créer des associations entre, d'une part, des motifs de
+ noms de fichiers et, d'autre part, des noms de
propriétés / valeurs de propriétés. Là encore, ces
associations modifient le comportement des commandes
<command>add</command> et <command>import</command>, pouvant non
seulement passer outre la décision prise par défaut d'attribution
- d'une propriété de type MIME, mais pouvant aussi définir d'autres
+ d'une propriété de type MIME mais pouvant aussi définir d'autres
propriétés, qu'elles soient utilisées par Subversion ou
personnalisées. Par exemple, vous pouvez créer une association
qui, à chaque ajout d'un fichier JPEG (c'est-à-dire dont le nom
- est du type <literal>*.jpg</literal>) fixe la propriété
+ est du type <literal>*.jpg</literal>), fixe la propriété
<literal>svn:mime-type</literal> de ce fichier à la valeur
- <literal>image/jpeg</literal>. Ou alors, tout fichier de type
- <literal>*.cpp</literal> se verra affecter la propriété
+ <literal>image/jpeg</literal>. Ou alors, tout fichier de type
+ <literal>*.cpp</literal> se voit affecter la propriété
<literal>svn:eol-style</literal> avec la valeur
<literal>native</literal>, et la propriété
<literal>svn:keywords</literal> la valeur
@@ -950,7 +950,7 @@
Subversion lui-même.</para>
<sidebar>
- <title>Identifier les types de fichiers</title>
+ <title>Identification des types de fichiers</title>
<para>Beaucoup de programmes sur les systèmes d'exploitation
modernes font des suppositions sur le type et le format du
@@ -1039,25 +1039,24 @@
n'est pas correctement définie à une valeur qui indique un
contenu non textuel, peut causer des comportements inattendus.
Par exemple, comme la <quote>fin de ligne</quote> n'a pas de
- sens dans un fichier binaire, Subversion vous empêchera de
+ sens dans un fichier binaire, Subversion vous empêche de
définir la propriété <literal>svn:eol-style</literal> sur ces
fichiers. Cela saute aux yeux quand vous travaillez sur un seul
fichier et que <command>svn propset</command> génère une
erreur. Ça l'est beaucoup moins si vous effectuez une
- opération récursive, où Subversion omettra silencieusement les
+ opération récursive, où Subversion omet silencieusement les
fichiers qu'il considère inappropriés pour une propriété
donnée.</para>
</warning>
- <para>Beginning in Subversion 1.5, users can configure a new
- <literal>mime-types-file</literal> runtime configuration
- parameter, which identifies the location of a MIME types
- mapping file. Subversion will consult this mapping file to
- determine the MIME type of newly added and imported
- files.</para>
+ <para>Depuis Subversion 1.5, les utilisateurs peuvent configurer
+ un nouveau paramètre <literal>mime-types-file</literal> dans la
+ zone de configuration qui identifie un fichier de correspondance
+ des types MIME. Subversion consulte ce fichier pour déterminer
+ le type MIME de tout nouveau fichier ajouté ou importé.</para>
<para>Par ailleurs, si la propriété <literal>svn:mime-type</literal>
- est définie, alors le greffon Apache pour Subversion utilisera
+ est définie, alors le greffon Apache pour Subversion utilise
cette valeur pour renseigner le champ
<literal>Content-type:</literal> de l'en-tête HTTP en réponse à
une requête GET. Cela fournit une indication très importante au
@@ -1096,8 +1095,8 @@
sont exécutables.</para>
</footnote>.
Par ailleurs, bien qu'elle n'ait pas de valeurs définies,
- Subversion lui attribuera la valeur <literal>*</literal>
- lorsqu'il activera cette propriété. Enfin, cette propriété n'est
+ Subversion lui attribue la valeur <literal>*</literal>
+ lorsqu'il active cette propriété. Enfin, cette propriété n'est
valide que sur des fichiers, pas sur des répertoires.</para>
</sect2>
@@ -1195,7 +1194,7 @@
<literal>LF</literal> pour indiquer les fins de ligne sur
sa copie.</para>
- <para>Notez que Subversion stockera en fait le fichier dans
+ <para>Notez que Subversion stocke en fait le fichier dans
le dépôt en utilisant le marqueur standard
<literal>LF</literal> indépendamment du système
d'exploitation. Cela reste toutefois tout à fait
@@ -1238,7 +1237,7 @@
<!-- =================================================================
-->
<!-- =================================================================
-->
<sect1 id="svn.advanced.props.special.ignore">
- <title>Ignorer les éléments non suivis en versions </title>
+ <title>Ignorer les éléments non suivis en versions</title>
<para>Dans n'importe quelle copie de travail, il y a de grandes
chances que les fichiers et répertoires suivis en versions côtoient
@@ -1310,7 +1309,7 @@
noms de fichiers, et les caractères spéciaux (aussi nommés
quantificateurs), qui sont interprétés différemment. </para>
- <para>Il y a différents types de syntaxes de motifs, mais
+ <para>Il y a différents types de syntaxe de motifs, mais
Subversion utilise celle qui est la plus répandue sur les
systèmes Unix, implémentée dans la fonction
<function>fnmatch</function>. Elle reconnaît les caractères
@@ -1320,14 +1319,14 @@
<varlistentry>
<term><literal>?</literal></term>
<listitem>
- <para>Correspond à n'importe quel caractère unique </para>
+ <para>Correspond à n'importe quel caractère unique.</para>
</listitem>
</varlistentry>
<varlistentry>
<term><literal>*</literal></term>
<listitem>
<para>Correspond à n'importe quelle chaîne de caractères, y
- compris la chaîne vide</para>
+ compris la chaîne vide.</para>
</listitem>
</varlistentry>
<varlistentry>
@@ -1432,7 +1431,7 @@
<para>Il y a quand même quelques différences entre CVS et
Subversion concernant les motifs à ignorer. Les deux systèmes
- n'utilisent pas les motifs au même moment, et il y a quelques
+ n'utilisent pas les motifs au même moment et il y a quelques
divergences légères sur ce sur quoi ils s'appliquent.
D'ailleurs, Subversion ne reconnaît pas le motif
<literal>!</literal> pour revenir à une situation où aucun motif
@@ -1443,7 +1442,7 @@
<para>La liste globale des motifs à ignorer est une affaire de goût,
devant plus s'intégrer à la collection d'outils d'un utilisateur
particulier que répondre aux besoins d'une copie de travail
- particulière. C'est pourquoi le reste de cette section s'attachera
+ particulière. C'est pourquoi le reste de cette section s'attache
à décrire l'utilisation de la propriété
<literal>svn:ignore</literal>.</para>
@@ -1462,7 +1461,7 @@
</screen>
<para>Dans cet exemple, des modifications ont été faites sur les
- propriétés de <filename>bouton.c</filename>, et il y a aussi des
+ propriétés de <filename>bouton.c</filename> et il y a aussi des
fichiers non suivis en versions : le programme
<filename>calculatrice</filename> (résultat de votre dernière
compilation du code source), un fichier source
@@ -1474,15 +1473,15 @@
<para>N'est-ce pas précisément la finalité d'un système de
compilation ?</para>
</footnote>.
- Vous savez également que vous aurez toujours des fichiers de
- traces qui traîneront. On peut faire ce constat pour toutes les
+ Vous savez également que vous avez toujours des fichiers de
+ traces qui traînent. On peut faire ce constat pour toutes les
copies de travail locales de ce projet, pas seulement la vôtre. Et
vous savez que cela ne vous intéresse pas, et que cela n'intéresse
très probablement aucun autre développeur, de voir ces fichiers
apparaître à chaque commande <command>svn status</command>. Vous
allez donc utiliser <userinput>svn propedit svn:ignore
calc</userinput>
pour ajouter des motifs à ignorer pour le répertoire
- <filename>calc</filename>. Par exemple, vous pourriez ajouter ce
+ <filename>calc</filename>. Par exemple, vous pouvez ajouter ce
qui suit comme nouvelle valeur de la propriété
<literal>svn:ignore</literal> :</para>
@@ -1491,7 +1490,7 @@
debug_log*
</programlisting>
- <para>Après avoir ajouté cette propriété, vous aurez une propriété
+ <para>Après avoir ajouté cette propriété, vous avez une propriété
modifiée localement dans votre répertoire
<filename>calc</filename>. Mais notez les autres différences sur
le résultat de la commande
@@ -1561,7 +1560,7 @@
coup les éléments non suivis en versions pour ajout. La cible
explicite permet de s'assurer que le répertoire en cours ne sera
pas négligé car déjà suivi en versions et l'option
- <option>--force</option> forcera Subversion à parcourir ce
+ <option>--force</option> force Subversion à parcourir ce
répertoire, ajoutant les fichiers non suivis en versions tout en
respectant la propriété <literal>svn:ignore</literal> et la
variable <literal>global-ignores</literal> de la zone de
@@ -1579,21 +1578,21 @@
<!-- =================================================================
-->
<!-- =================================================================
-->
<sect1 id="svn.advanced.props.special.keywords">
- <title>Substitution de mots-clés </title>
+ <title>Substitution de mots-clés</title>
<para>Subversion a la capacité de substituer des
<firstterm>mots-clés</firstterm> dans les fichiers suivis en
versions par des informations dynamiques et utiles. Les mots-clés
fournissent généralement des indications sur les dernières
modifications faites au fichier. Comme ces informations changent à
- chaque fois que le fichier change, et plus spécifiquement, juste
+ chaque fois que le fichier change et, plus spécifiquement, juste
<emphasis>après</emphasis> que le fichier change, c'est compliqué
pour tout processus, excepté pour le système de gestion de
versions, de garder les données à jour. Sans outil automatique,
adieu la pertinence de ces informations !</para>
- <para>Par exemple, prenons un document dans lequel vous voudriez
- afficher sa date de dernière modification. Vous pourriez charger
+ <para>Par exemple, prenons un document dans lequel vous voulez
+ afficher sa date de dernière modification. Vous pouvez charger
chaque contributeur du document de renseigner le champ
correspondant juste avant de propager ses changements. Mais un
jour ou l'autre, quelqu'un oubliera de le faire. Demandez plutôt
@@ -1607,7 +1606,7 @@
<para>Tous les mots-clés sont sensibles à la casse des caractères
quand ils apparaissent en tant que signets : vous devez
placer les majuscules aux bons endroits pour que le mot-clé soit
- effectivement remplacé. Vous devriez aussi considérer que la
+ effectivement remplacé. Vous devez aussi considérer que la
valeur de la propriété <literal>svn:keywords</literal> est
sensible à la casse (<quote>case-sensitive</quote> en anglais) :
certains mots-clés seront reconnus indépendamment de la casse, mais
@@ -1685,13 +1684,13 @@
une opération effectuée côté client et que votre client ne connaît
pas les changements qui ont eu lieu dans le dépôt depuis votre
dernière mise à jour. Si vous ne mettez jamais à jour de votre
- copie de travail locale, vos mots-clés resteront figés à la même
+ copie de travail locale, vos mots-clés restent figés à la même
valeur même si des changements ont lieu régulièrement dans le
dépôt.</para>
<para>Ajouter des signets dans votre fichier ne fait rien de spécial.
- Subversion n'essaiera jamais d'effectuer la substitution dans votre
- fichier tant que vous ne le lui demanderez pas explicitement. Après
+ Subversion n'essaie jamais d'effectuer la substitution dans votre
+ fichier tant que vous ne le lui demandez pas explicitement. Après
tout, vous écrivez peut-être un document
<footnote>
<para>… ou même peut-être un paragraphe de ce
@@ -1720,7 +1719,7 @@
</programlisting>
<para>Sans la propriété <literal>svn:keywords</literal> activée sur
- ce fichier, Subversion ne fera rien de spécial. Maintenant, si
+ ce fichier, Subversion ne fait rien de spécial. Maintenant, si
nous activons les substitutions pour le mot-clé
<literal>LastChangedDate</literal> :</para>
@@ -1736,15 +1735,15 @@
modifications avant d'activer la propriété). Notez que le fichier
contenait un signet pour le mot-clé <literal>Rev</literal> et que
nous n'avons pas inclus ce mot-clé dans la valeur de la propriété.
- Subversion ignorera simplement les requêtes de substitutions de
+ Subversion ignore simplement les requêtes de substitutions de
mots-clés qui ne sont pas présents dans le fichier et ne
- substituera pas de mot-clé qui ne soit pas présent dans la valeur
+ substitue pas de mot-clé qui ne soit pas présent dans la valeur
de la propriété <literal>svn:keywords</literal>.</para>
<para>Immédiatement après avoir propagé ces modifications de
- propriété, Subversion mettra à jour votre copie de travail avec le
+ propriété, Subversion met à jour votre copie de travail avec le
nouveau texte substitué. Au lieu de voir votre signet
- <literal>$LastChangedDate$</literal>, vous verrez le résultat de la
+ <literal>$LastChangedDate$</literal>, vous voyez le résultat de la
substitution. Ce résultat contient aussi le nom du mot-clé et est
toujours entouré par des caractères dollar (<literal>$</literal>).
Comme prévu, le mot-clé <literal>Rev</literal> n'a pas été
@@ -1764,7 +1763,7 @@
<para>Si quelqu'un d'autre propage une modification de
<filename>meteo.txt</filename>, votre copie de ce fichier
- continuera à afficher la même valeur substituée de mot-clé,
+ continue à afficher la même valeur substituée de mot-clé,
jusqu'à ce que vous mettiez à jour votre copie de travail. Aux
mots-clés de <filename>meteo.txt</filename> seront alors à nouveau
substitués les informations qui se rapportent à la plus récente
@@ -1776,8 +1775,8 @@
<para>Les nouveaux utilisateurs sont parfois surpris par le
fonctionnement du mot-clé <literal>$Rev$</literal>. Puisque le
dépôt a un numéro de révision à la fois unique, global et
- croissant, beaucoup de gens pensent que c'est par ce numéro que
- sera remplacé le mot-clé <literal>$Rev$</literal>. Mais
+ croissant, beaucoup de gens pensent que c'est par ce numéro
+ qu'est remplacé le mot-clé <literal>$Rev$</literal>. Mais
<literal>$Rev$</literal> indique la dernière révision dans
laquelle le fichier a <emphasis>changé</emphasis>, pas la
révision de la dernière mise à jour. Le malentendu est ainsi
@@ -1805,18 +1804,18 @@
substitués, longueur que vous définissez en utilisant la séquence
double deux-points (<literal>::</literal>) après le nom du mot-clé,
suivie du nombre de caractères espace (<literal> </literal>) voulus.
- Quand Subversion devra effectuer la substitution du mot-clé par le
- mot-clé et sa valeur, il ne remplacera que ces espaces, laissant
+ Quand Subversion doit effectuer la substitution du mot-clé par le
+ mot-clé et sa valeur, il ne remplace que ces espaces, laissant
la taille du champ inchangée. Si la valeur est plus courte que la
- largeur du champ, il restera des espaces pour combler la fin ;
- si la valeur est trop longue, elle sera tronquée avec le caractère
+ largeur du champ, il reste des espaces pour combler la fin ;
+ si la valeur est trop longue, elle est tronquée avec le caractère
dièse (<literal>#</literal>) juste avant le caractère dollar
(<literal>$</literal>) final.</para>
<para>Par exemple, pour un document dans lequel vous avez une
section avec les mots-clés Subversion dans un tableau.
L'utilisation de la syntaxe originale de substitution de
- Subversion donnera quelque chose comme :</para>
+ Subversion donne quelque chose comme :</para>
<screen>
$Rev$: Numéro de révision de la dernière propagation
@@ -1824,9 +1823,9 @@
$Date$: Date de la dernière propagation
</screen>
- <para>C'est joli et bien aligné au début. Mais quand vous allez
- propager ce fichier (avec la substitution des mots-clés activée,
- bien évidemment), vous obtiendrez :</para>
+ <para>C'est joli et bien aligné au début. Mais quand vous
+ propagez ce fichier (avec la substitution des mots-clés activée,
+ bien évidemment), vous obtenez :</para>
<screen>
$Rev: 12 $: Numéro de révision de la dernière propagation
@@ -1834,7 +1833,7 @@
$Date: 2006-03-15 02:33:03 -0500 (Wed, 15 Mar 2006) $: Date de la
dernière propagation
</screen>
- <para>Le résultat n'est pas très heureux. Vous seriez alors tenté de
+ <para>Le résultat n'est pas très heureux. Vous êtes alors tenté de
modifier le fichier après la substitution pour que le contenu soit
mieux aligné. Mais cette modification ne serait valable que tant
que les valeurs des mots-clés gardent la même taille. Si le numéro
@@ -1843,7 +1842,7 @@
modifie le fichier, tout le travail d'alignement est à refaire.
Cependant, si vous utilisez la version 1.2 (ou plus) de Subversion,
vous pouvez utiliser la nouvelle syntaxe et définir des largeurs
- de champs adéquates et constantes. Votre fichier ressemblera alors
+ de champs adéquates et constantes. Votre fichier ressemble alors
à ceci :</para>
<screen>
@@ -1882,7 +1881,7 @@
d'utilisateur qui contient des caractères au format UTF-8 codés
sur plusieurs octets risque d'être tronqué en plein milieu d'un
de ces caractères multi-octets. Cette troncature est valide au
- niveau du traitement des octets mais résultera en une chaîne
+ niveau du traitement des octets mais résulte en une chaîne
UTF-8 incorrecte en raison du caractère final tronqué. Il est
ainsi possible que certaines applications, au moment de charger
le fichier, remarquent que le texte UTF-8 est invalide,
@@ -1919,7 +1918,7 @@
fichiers et répertoires est constituée des noms des membres d'une
famille et de leurs animaux de compagnie (c'est assurément un
exemple bizarre, mais soit). Un <command>svn checkout</command>
- standard nous donnerait une copie de travail de l'ensemble de
+ standard nous donne une copie de travail de l'ensemble de
l'arborescence :</para>
<screen>
@@ -1954,7 +1953,7 @@
similaire aux options <option>--non-recursive</option>
(<option>-N</option>) et <option>--recursive</option>
(<option>-R</option>). En fait, elle combine, améliore, remplace
- et à terme rend obsolète ces deux options plus anciennes. Déjà,
+ et, à terme, rend obsolète ces deux options plus anciennes. Déjà,
elle permet à l'utilisateur de spécifier le niveau de récursion de
façon plus précise, en ajoutant des niveaux auparavant non
supportés (ou de manière peu satisfaisante). Voici les valeurs de
@@ -2017,7 +2016,7 @@
<para>Vous pouvez vérifier le niveau de récursion d'une copie de
travail en utilisant la commande <command>svn info</command>.
Si le niveau de récursion n'est pas infini, <command>svn
- info</command> affichera une ligne indiquant le niveau de
+ info</command> affiche une ligne indiquant le niveau de
récursion :</para>
<screen>
@@ -2061,10 +2060,10 @@
que lorsque vous travaillez sur une copie de travail d'un certain
niveau et que vous faites une opération sur un niveau plus faible,
l'opération est limitée à ce niveau faible. En fait, on peut
- généraliser ce raisonnement : pour une copie de travail d'un
+ généraliser ce raisonnement : pour une copie de travail d'un
niveau de récursion arbitraire (éventuellement hétérogène) et pour
une commande Subversion comportant un niveau de récursion, la
- commande conservera le niveau de récursion associé aux éléments de
+ commande conserve le niveau de récursion associé aux éléments de
la copie de travail tout en limitant le rayon d'action de
l'opération au niveau demandé (ou celui par défaut).</para>
@@ -2138,7 +2137,7 @@
définis au sein d'une même copie de travail, les actions sur la
copie de travail ne s'en trouvent pas plus compliquées. Vous
pouvez toujours effectuer des modifications et les propager,
- revenir en arrière, ou afficher les modifications locales de
+ revenir en arrière ou afficher les modifications locales de
votre copie de travail sans spécifier d'option particulière (y
compris <option>--depth</option> et
<option>--set-depth</option>) aux dites commandes. Même
@@ -2173,7 +2172,7 @@
copie de travail.</para>
<para>L'implémentation des extractions superficielles de Subversion
- 1.5 est relativement bonne, mais il y a deux choses intéressantes
+ 1.5 est relativement bonne mais il y a deux choses intéressantes
qu'elle ne permet pas de faire. Premièrement, vous ne pouvez pas
diminuer le niveau de récursion d'un élément de la copie de
travail. Si vous lancez
@@ -2303,7 +2302,7 @@
déverrouiller (abandonner le droit exclusif de modification), de
voir la liste des fichiers qui sont verrouillés et par qui,
d'annoter des fichiers pour lesquels le verrouillage est fortement
- recommandé avant édition, etc. Dans cette section, nous aborderons
+ recommandé avant édition, etc. Dans cette section, nous abordons
toutes les facettes de cette fonctionnalité de verrouillage.</para>
<sidebar id="svn.advanced.locking.meanings">
@@ -2346,7 +2345,7 @@
<!-- ===============================================================
-->
<sect2 id="svn.advanced.locking.creation">
- <title>Créer des verrous</title>
+ <title>Création d'un verrou</title>
<para>Dans un dépôt Subversion, un <firstterm>verrou</firstterm>
est une méta-donnée qui alloue à un utilisateur un accès
@@ -2388,7 +2387,7 @@
(<option>-m</option>), soit via <option>--file</option>
(<option>-F</option>)) pour indiquer la raison du verrouillage du
fichier. En revanche, contrairement à <command>svn
- commit</command>, <command>svn lock</command> n'exigera pas
+ commit</command>, <command>svn lock</command> n'exige pas
automatiquement un message en lançant votre éditeur de texte
préféré. Les commentaires de verrouillage sont optionnels, mais
néanmoins recommandés pour faciliter la communication entre
@@ -2532,8 +2531,8 @@
hasard trente fichiers dans un répertoire nommé
<filename>Images</filename> parce qu'il n'est pas sûr de savoir
quels fichiers il doit modifier et qu'il ne modifie finalement
- que quatre fichiers, alors quand il lancera la commande
- <userinput>svn commit Images</userinput>, la procédure libérera
+ que quatre fichiers, alors quand il lance la commande
+ <userinput>svn commit Images</userinput>, la procédure libère
les trente verrous.</para>
<para>Ce mode de fonctionnement (libérer automatiquement les
@@ -2560,7 +2559,7 @@
<!-- ===============================================================
-->
<sect2 id="svn.advanced.locking.discovery">
- <title>Identifier un verrou</title>
+ <title>Identification d'un verrou</title>
<para>Quand une propagation échoue parce que quelqu'un d'autre a
posé un verrou, il est facile de savoir pourquoi. La commande la
@@ -2616,7 +2615,7 @@
verrou signifie que la copie de travail détient un jeton de
verrouillage (si le fichier est verrouillé par un autre
utilisateur ou depuis une autre copie de travail, alors lancer
- <command>svn info</command> sur la copie de travail ne renverra
+ <command>svn info</command> sur la copie de travail ne renvoit
aucune information relative au verrou). Si l'argument principal
de <command>svn info</command> est une URL, alors les
informations affichées se rapportent à la dernière version de
@@ -2636,7 +2635,7 @@
<!-- ===============================================================
-->
<sect2 id="svn.advanced.locking.break-steal">
- <title>Casser et voler des verrous</title>
+ <title>Cassage et vol d'un verrou</title>
<para>Un verrou n'est pas quelque chose de sacré : dans la
configuration par défaut de Subversion, les verrous peuvent être
@@ -2767,7 +2766,7 @@
<para>Il existe des visions différentes de la résistance que
doit avoir un verrou. Certains considèrent que les verrous
- doivent être respectés à tout prix, et donc libérables
+ doivent être respectés à tout prix et donc libérables
uniquement par leur détenteur ou par un administrateur. Ils
affirment que si n'importe qui peut casser un verrou c'est la
pagaille et tout le concept de verrouillage est mis par terre.
@@ -2777,7 +2776,7 @@
de l'équipe qui ne peut pas être résolu par un outil
logiciel.</para>
- <para>Subversion souscrit à la version <quote>douce</quote>,
+ <para>Subversion souscrit à la version <quote>douce</quote>
mais autorise cependant les administrateurs à mettre en place
une politique plus stricte via l'utilisation de procédures
automatiques. En particulier, les procédures automatiques de
@@ -2829,21 +2828,21 @@
modifications. Ce mécanisme est mis en œuvre par une propriété
spéciale : <literal>svn:needs-lock</literal>. Si cette
propriété est associée à un fichier (quelle que soit sa valeur,
- qui n'est pas prise en compte), alors Subversion essaiera
+ qui n'est pas prise en compte), alors Subversion essaie
d'utiliser les permissions du système de fichiers pour le placer
en lecture seule — à moins, bien sûr, que l'utilisateur
ait explicitement verrouillé le fichier. Quand un jeton de
verrouillage est présent (indiquant que
- <command>svn lock</command> a été lancée), le fichier sera placé
- en lecture-écriture. Quand le verrou sera libéré, le fichier
- passera de nouveau en lecture seule.</para>
+ <command>svn lock</command> a été lancée), le fichier est placé
+ en lecture-écriture. Quand le verrou est libéré, le fichier
+ passe de nouveau en lecture seule.</para>
<para>La théorie est donc que si le fichier image a cette
propriété définie, alors Sally remarquera tout de suite quelque
chose d'étrange à l'ouverture du fichier : beaucoup
d'applications avertissent l'utilisateur immédiatement quand un
fichier en lecture seule est ouvert pour édition et pratiquement
- tous l'empêcheront de sauvegarder ses modifications dans le
+ toutes l'empêcheront de sauvegarder ses modifications dans le
fichier. Cela lui rappellera de verrouiller le fichier avant de
l'éditer, découvrant ainsi le verrou pré-existant :</para>
@@ -2879,7 +2878,7 @@
pouvoir propager des modifications.</para>
<para>Malheureusement, le système n'est pas parfait. Il est
- possible que même si le fichier possède la propriété,
+ possible que, même si le fichier possède la propriété,
l'avertissement de lecture seule ne marche pas. Quelquefois, les
applications ne suivent pas les normes et
<quote>piratent</quote> le fichier en lecture seule, autorisant
@@ -2905,12 +2904,12 @@
<para>Parfois il peut être utile de construire une copie de travail
issue de différentes extractions. Par exemple, vous pouvez avoir
envie d'avoir différents sous-répertoires provenant de différents
- endroits du dépôt, ou même carrément de différents dépôts. Vous
- pourriez arriver un tel enchevêtrement manuellement, en utilisant
- <command>svn checkout</command> pour créer le genre de structure
- voulu pour votre copie de travail . Mais si cette configuration
+ endroits du dépôt ou même carrément de différents dépôts. Vous
+ pouvez arriver à un tel enchevêtrement manuellement, en utilisant
+ <command>svn checkout</command>, pour créer le genre de structure
+ voulu pour votre copie de travail. Mais si cette configuration
est importante pour tous les utilisateurs de votre dépôt, chacun
- devra effectuer les mêmes opérations d'extraction que vous.</para>
+ doit effectuer les mêmes opérations d'extraction que vous.</para>
<para>Heureusement, Subversion supporte les <firstterm>définitions
de références externes</firstterm>. Une définition de références
@@ -2924,7 +2923,7 @@
(voir <xref linkend="svn.advanced.props.manip" />). Elle peut être
définie sur tous les répertoires suivis en versions et sa valeur
décrit à la fois l'URL du dépôt externe et le répertoire côté
- client dans lequel sera extrait cette URL.</para>
+ client dans lequel est extrait cette URL.</para>
<para>L'un des attraits de la propriété
<literal>svn:externals</literal>
est qu'une fois qu'elle est définie pour un répertoire suivi en
@@ -2933,14 +2932,14 @@
d'autres termes, une fois qu'un utilisateur a fait l'effort de
définir la structure de la copie de travail imbriquée, tout le
monde en bénéficie automatiquement : Subversion, lors de
- l'extraction de la copie de travail originale, extraira également
+ l'extraction de la copie de travail originale, extraie également
les copies de travail externes.</para>
<warning>
<para>Les sous-répertoires cibles des définitions de références
externes <emphasis>ne doivent pas</emphasis> déjà exister sur
votre système ou sur le systèmes des autres utilisateurs :
- Subversion les créera lors de l'extraction des copies de travail
+ Subversion les crée lors de l'extraction des copies de travail
externes.</para>
</warning>
@@ -2950,11 +2949,11 @@
définition de références externes, vous pouvez le faire à l'aide
des sous-commandes classiques sur les propriétés. Quand vous
propagez des modifications relatives à la propriété
- <literal>svn:externals</literal>, Subversion synchronisera les
+ <literal>svn:externals</literal>, Subversion synchronise les
éléments extraits par rapport à la définition de références
- externes modifiée dès que vous lancerez
+ externes modifiée dès que vous lancez
<userinput>svn update</userinput>. Tous ceux qui
- mettront à jour leur copie de travail recevront vos modifications
+ mettent à jour leur copie de travail reçoivent vos modifications
concernant les définitions de références externes.</para>
<tip>
@@ -2970,7 +2969,7 @@
composées de sous-répertoires (relativement au répertoire suivi
en versions sur lequel est définie la propriété), d'indicateurs de
révision optionnels et l'URL, absolue et complètement qualifiée,
- du dépôt Subversion. Un exemple pourrait ressembler à
+ du dépôt Subversion. Un exemple peut ressembler à
ceci :</para>
<screen>
@@ -3010,7 +3009,7 @@
de la propriété <literal>svn:externals</literal> est supporté.
Les références externes sont toujours multi-lignes mais l'ordre et
le format des différentes informations ont changé. La nouvelle
- syntaxe ressemble plus à l'ordre des arguments que vous passeriez
+ syntaxe ressemble plus à l'ordre des arguments que vous passez
à la commande <command>svn checkout</command> : l'indicateur
optionnel de révision est placé en premier, puis l'URL du dépôt
Subversion externe et, enfin, le sous-répertoire local relatif.
@@ -3018,7 +3017,7 @@
<quote>URL absolue et complètement qualifiée</quote> pour le dépôt
externe. En effet, le nouveau format accepte les URL relatives et
les URL avec des piquets de révision. L'exemple précédent sur les
- références externes pourrait, dans Subversion 1.5, ressembler à
+ références externes peut, dans Subversion 1.5, ressembler à
ceci :</para>
<screen>
@@ -3030,7 +3029,7 @@
<para>Ou, en utilisant la syntaxe avec les piquets de révision
(décrite en détail dans <xref linkend="svn.advanced.pegrevs" />),
- il pourrait être écrit comme ceci :</para>
+ il peut être écrit comme ceci :</para>
<screen>
$ svn propget svn:externals calc
@@ -3051,7 +3050,7 @@
travail antérieure, vos références externes reviendront elles
aussi dans l'état où elles étaient au moment de cette version
antérieure. Cela signifie aussi que les copies de travail
- externes seront actualisées pour refléter
+ externes sont actualisées pour refléter
<emphasis>leur</emphasis> état au moment de la révision
antérieure. Pour des projets logiciels, cela peut faire la
différence entre une compilation réussie et un échec de
@@ -3064,8 +3063,8 @@
avantages. Malheureusement, ils possèdent aussi les mêmes
inconvénients. Puisque les références indiquées utilisent des URL
absolues, déplacer ou copier un répertoire auquel elles sont
- rattachées n'affectera pas ce qui est extrait en externe (alors
- qu'une référence relative sera, bien évidemment, déplacée avec le
+ rattachées n'affecte pas ce qui est extrait en externe (alors
+ qu'une référence relative est, bien évidemment, déplacée avec le
répertoire). Cela peut vous induire en erreur, voire vous
frustrer, dans certaines situations. Par exemple, imaginons un
répertoire racine appelé <filename>mon-projet</filename> pour
@@ -3093,7 +3092,7 @@
<para>Maintenant utilisez la commande
<command>svn move</command> pour renommer le répertoire
<filename>mon-projet</filename>. À ce moment là, vos
- définitions de références externes pointeront toujours vers un
+ définitions de références externes pointent toujours vers un
chemin sous le répertoire <filename>mon-projet</filename>, même si
ce répertoire n'existe plus.</para>
@@ -3120,7 +3119,7 @@
mais que les opérations de propagation doivent être effectuées
uniquement via <literal>https://</literal>, vous vous retrouvez
bien embêté. Si vos références externes pointent vers une URL de
- type <literal>http://</literal>, vous ne pourrez pas effectuer de
+ type <literal>http://</literal>, vous ne pouvez pas effectuer de
propagation depuis les copies de travail créées via ces
références externes. D'un autre côté, si vous utilisez la forme
<literal>https://</literal> pour les URL, ceux qui voudront
@@ -3193,17 +3192,17 @@
effectués sur une ou plusieurs de ces copies de travail externes,
vous devez lancez <command>svn commit</command> explicitement sur
ces copies de travail — effectuer une propagation sur la
- copie de travail primaire ne traitera pas récursivement les copies
+ copie de travail primaire ne traite pas récursivement les copies
de travail externes.</para>
<para>Nous avons déjà mentionné certains défauts de l'ancien
format de <literal>svn:externals</literal> et comment la version
1.5 de Subversion les corrige. Mais faites attention, en utilisant
les nouveaux formats, à ne pas pénaliser accidentellement des
- utilisateurs qui accèderaient à votre dépôt avec de vieux clients
+ utilisateurs qui accèdent à votre dépôt avec de vieux clients
Subversion. Alors que les clients Subversion 1.5 supportent
toujours le format original des définitions de références
- externes, les vieux clients <emphasis>ne seront pas
+ externes, les vieux clients <emphasis>ne sont pas
capables</emphasis> d'analyser le nouveau format.</para>
<para>En plus des commandes <command>svn checkout</command>,
@@ -3236,8 +3235,8 @@
pratiquement oublier, étant presque aussi flexible pour les
fichiers suivis en versions que pour les autres. Mais cette
***The diff for this file has been truncated for email.***
More information about the svnbook-dev
mailing list