[svnbook] r3727 committed - * fr/book/ch04-branching-and-merging.xml...
svnbook at googlecode.com
svnbook at googlecode.com
Sat May 1 17:06:39 CDT 2010
Revision: 3727
Author: christophe.nanteuil
Date: Sat May 1 15:05:34 2010
Log: * fr/book/ch04-branching-and-merging.xml
- cross-reading
http://code.google.com/p/svnbook/source/detail?r=3727
Modified:
/trunk/src/fr/book/ch04-branching-and-merging.xml
=======================================
--- /trunk/src/fr/book/ch04-branching-and-merging.xml Fri Apr 23 13:21:19
2010
+++ /trunk/src/fr/book/ch04-branching-and-merging.xml Sat May 1 15:05:34
2010
@@ -17,8 +17,8 @@
<para>La gestion des branches est un élément fondamental de la
gestion de versions. Si vous comptez utiliser Subversion pour
- gérer vos données, c'est une fonctionnalité qui finira par
- devenir indispensable pour vous. Ce chapitre suppose que vous êtes
+ gérer vos données, c'est une fonctionnalité dont vous ne pourrez
+ plus vous passer. Ce chapitre suppose que vous êtes
déjà familier avec les notions de bases de Subversion
(<xref linkend="svn.basic"/>).</para>
@@ -27,7 +27,7 @@
<!-- =================================================================
-->
<!-- =================================================================
-->
<sect1 id="svn.branchmerge.whatis">
- <title>Qu'est-ce qu'une branche?</title>
+ <title>Qu'est-ce qu'une branche ?</title>
<para>Supposons que votre travail soit de maintenir un document
pour une division de votre entreprise, un manuel par exemple.
@@ -36,7 +36,7 @@
pour elle, puisqu'elle fait les choses légèrement
différemment.</para>
- <para>Que faites-vous dans cette situation? Tout naturellement,
+ <para>Que faites-vous dans cette situation ? Tout naturellement,
vous créez une seconde copie du document et commencez à maintenir
les deux copies séparément. Puis, quand chaque division vous
demande de faire des petites modifications, vous les incorporez
@@ -120,7 +120,7 @@
corriger des bogues mineurs ici et là. Elle a besoin que la
dernière version du projet
(dans <filename>/calc/trunk</filename>) demeure en permanence
- utilisable. Si vous commencez à livrer des changements petit
+ utilisable. Si vous commencez à propager des changements petit
à petit, vous allez sûrement rendre les choses difficiles pour
Sally (ainsi que pour d'autres membres de l'équipe).</para>
@@ -129,8 +129,8 @@
semaine ou deux. C'est-à-dire commencer à modifier et à
réorganiser les fichiers dans votre copie de travail, mais
sans effectuer de propagation ni de mise à jour avant que vous
- n'ayez complètement terminé la tâche. Il y a cependant un
- certain nombre de problèmes avec cette stratégie. Premièrement,
+ n'ayez complètement terminé la tâche. Cette stratégie comporte
+ certains risques. Premièrement,
ce n'est pas sans danger. La plupart des gens aiment propager
leurs modifications fréquemment, au cas où leur copie de travail
aurait un accident. Deuxièmement, ce n'est pas très flexible. Si
@@ -143,7 +143,7 @@
d'autre. Une des <quote>bonnes pratiques</quote> du monde du
développement logiciel est de permettre à vos pairs de passer
votre travail en revue au fur et à mesure. Si personne n'a accès
- à vos livraisons intermédiaires, vous vous coupez d'éventuelles
+ à vos propagations intermédiaires, vous vous coupez d'éventuelles
critiques et risquez de partir dans une mauvaise direction
pendant des semaines avant que quelqu'un ne s'en aperçoive.
Enfin, quand vous en aurez fini avec tous vos changements,
@@ -202,15 +202,14 @@
dans le dépôt, créant un nouveau dossier à la révision 341.
Ce nouveau dossier est une copie de
<filename>/calc/trunk</filename>, comme l'illustre la
- <xref linkend="svn.branchmerge.using.create.dia-1"/>.
-
+ <xref linkend="svn.branchmerge.using.create.dia-1"/>
<footnote>
<para>Subversion n'accepte pas les copies entre des dépôts
distincts. Quand vous utilisez des URLs avec
<command>svn copy</command> et <command>svn move</command>,
vous ne pouvez copier que des éléments faisant partie du
même dépôt.</para>
- </footnote>
+ </footnote>.
Bien qu'il soit aussi possible de créer une branche en
utilisant <command>svn copy</command> pour dupliquer un dossier
@@ -220,7 +219,7 @@
terme de durée, puisque chaque fichier et chaque dossier doit
être dupliqué sur le disque local. Copier un dossier sur le
serveur, par contre, est une opération dont la durée est
- constante et c'est la façon dont la plupart des gens créent
+ constante et c'est ainsi que la plupart des gens créent
des branches.</para>
<figure id="svn.branchmerge.using.create.dia-1">
@@ -300,7 +299,7 @@
<command>svn switch</command> est une méthode alternative
pour créer une copie de travail d'une branche).</para>
- <para>Imaginons qu'une semaine passe et que les livraisons
+ <para>Imaginons qu'une semaine passe et que les propagations
suivantes ont lieu :</para>
<itemizedlist>
@@ -430,7 +429,7 @@
Premièrement, Subversion n'a pas de notion interne de
branche — il sait seulement faire des copies. Quand
vous copiez un dossier, le dossier qui en résulte n'est une
- <quote>branche</quote> que parce <emphasis>vous</emphasis>
+ <quote>branche</quote> que parce que <emphasis>vous</emphasis>
le considérez comme tel. Vous aurez beau envisager ce dossier
différemment ou le traiter différemment, pour
Subversion c'est juste un dossier ordinaire auquel sont
@@ -465,11 +464,11 @@
la branche de développement principale.</para>
<para>Pour les projets qui ont un grand nombre de contributeurs,
- il est d'usage courant que la plupart des gens aient des copies
+ il est d'usage que la plupart des gens aient des copies
de travail du tronc. Dès que quelqu'un doit faire des
modifications de longue haleine, susceptibles de perturber
- le tronc, une procédure standard est de créer une branche
- privée et d'y propager les modifications jusqu'à ce que tout
+ le tronc, une procédure standard est qu'il crée une branche
+ privée et qu'il y propage les modifications jusqu'à ce que tout
le travail soit terminé.</para>
<para>Bref, la bonne nouvelle est que Sally et vous n'empiétez
@@ -487,7 +486,7 @@
partagées ; Subversion vous offre la possibilité de
<quote>copier</quote> sélectivement des modifications entre
les branches. Et quand vous aurez tout fini dans votre branche,
- votre groupe de modifications pourra être recopié en entier
+ l'ensemble de vos modifications pourra être recopié en entier
vers le tronc. Dans la terminologie Subversion, l'action
générale de réplication des modifications d'une branche vers
une autre s'appelle la <firstterm>fusion</firstterm> et elle
@@ -497,8 +496,8 @@
<para>Dans les exemples qui suivent, nous supposerons que le
client et le serveur Subversion sont tous deux en version 1.5
(ou plus récente). Si l'un ou l'autre sont en version plus
- ancienne, les choses seront plus compliquées : le système
- ne gérera pas les changements de façon automatique et vous
+ ancienne, les choses sont plus compliquées : le système
+ ne gére pas les changements de façon automatique et vous
devrez utiliser des méthodes manuelles pénibles pour obtenir
des résultats similaires. Vous devrez en effet toujours utiliser
la syntaxe détaillée de la fusion spécifiant l'éventail des
@@ -507,7 +506,7 @@
plus loin dans ce chapitre) et penser à garder trace de ce qui
a déjà été fusionné et de ce qui ne l'a pas encore été. Pour
cette raison, nous recommandons <emphasis>fortement</emphasis>
- que vous vous assuriez que client et serveur sont au moins
+ de vous assurer que client et serveur sont au moins
en version 1.5.</para>
<!-- =============================================================== -->
@@ -515,7 +514,7 @@
<title>Ensembles de modifications</title>
<para>Avant que nous n'allions plus loin, nous devons vous
- avertir que les pages suivantes contiendront de nombreuses
+ avertir que les pages suivantes contiennent de nombreuses
discussions portant sur les <quote>modifications</quote>.
Beaucoup de gens ayant de l'expérience dans les systèmes de
gestion de versions utilisent le terme
@@ -524,10 +523,10 @@
donc clarifier ce que Subversion entend par
<firstterm>ensemble de modifications</firstterm>.</para>
- <para>Tout le monde semble avoir sa propre définition, variant
+ <para>Chacun semble avoir sa propre définition, variant
légèrement, d'un ensemble de modifications, ou tout du moins
- une attente différente de ce qu'un système de gestion de
- versions peut entendre par là. En ce qui nous concerne, disons
+ a une attente différente quant à leur traitement par le système
+ de gestion de versions. En ce qui nous concerne, disons
qu'un ensemble de modifications n'est qu'un simple regroupement
de modifications identifié par un nom unique. Les modifications
peuvent inclure des changements textuels du contenu des
@@ -538,7 +537,7 @@
<para>Dans Subversion, un numéro de révision globale N désigne
une arborescence dans le dépôt : c'est ce à quoi le dépôt
- ressemblait après la N-ème propagation. C'est aussi le nom d'un
+ ressemblait après la N-ième propagation. C'est aussi le nom d'un
ensemble de modifications implicite : si vous comparez
l'arborescence N avec l'arborescence N−1, vous pouvez en
déduire exactement le correctif qui a été propagé. Pour cette
@@ -553,7 +552,7 @@
<userinput>svn log -r 9238</userinput> pour obtenir le détail
des modifications qui ont corrigé le bogue et lancer
<userinput>svn diff -c 9238</userinput> pour voir le
- correctif lui-même. De plus (comme vous le verrez bientôt),
+ correctif lui-même. De plus (comme nous le verrons bientôt),
la commande <command>svn merge</command> de Subversion est
capable d'utiliser les numéros de révision. Vous pouvez
fusionner des listes de modifications spécifiques d'une
@@ -577,7 +576,7 @@
à faire des modifications importantes sur le
<filename>/trunk</filename> du projet. Vous avez intérêt à
recopier ces modifications dans votre propre branche, juste
- pour vous assurer qu'elles se combinent bien avec vos
+ pour vous assurer qu'elles se combinent bien avec vos propres
modifications. En fait, c'est là une bonne pratique :
synchroniser fréquemment votre branche avec la ligne de
développement principale permet d'éviter les conflits
@@ -625,7 +624,7 @@
<command>svn diff</command> et ensuite de compiler et de
tester votre branche. Notez que le répertoire de travail
actuel (<quote><filename>.</filename></quote>) a aussi été
- modifié ; <command>svn diff</command> indiquera que sa
+ modifié ; <command>svn diff</command> indique que sa
propriété <literal>svn:mergeinfo</literal> a été créée ou
modifiée. Ceci est une méta-information importante liée à la
fusion, à laquelle vous ne devriez <emphasis>pas</emphasis>
@@ -642,7 +641,7 @@
pas de conflits <emphasis>sémantiques</emphasis> !).
Si vous rencontrez de graves difficultés, vous pouvez toujours
annuler les modifications locales en lançant
- <userinput>svn revert . -R</userinput> (qui annulera toutes
+ <userinput>svn revert . -R</userinput> (qui annule toutes
les modifications locales) et entamer avec vos collègues
une longue discussion sur le thème
<quote>Qu'est-ce qui se passe ?</quote>. Par contre, si les
@@ -720,8 +719,8 @@
</sidebar>
<para>Supposons qu'une autre semaine s'est écoulée. Vous avez
- propagé des modifications supplémentaires dans votre branche,
- et que vos camarades ont également continué à améliorer le
+ propagé des modifications supplémentaires dans votre branche
+ et vos camarades ont également continué à améliorer le
tronc. Une fois encore, vous aimeriez répercuter les dernières
modifications du tronc vers votre branche et ainsi être synchro.
Lancez juste la même commande <command>svn merge</command>
@@ -765,9 +764,9 @@
Révision 390 propagée.
</screen>
- <para>À présent, vous allez utiliser <command>svn merge</command>
+ <para>À présent, utilisez <command>svn merge</command>
pour répercuter les modifications de votre branche sur le tronc.
- Vous aurez besoin d'une copie de travail de
+ Vous avez alors besoin d'une copie de travail de
<filename>/trunk</filename> qui soit à jour. Vous pouvez
vous la procurer soit en effectuant un
<command>svn checkout</command>, soit en reprenant une vieille
@@ -834,8 +833,8 @@
synchronisation finale, il fusionne le groupe 380:385.</para>
<para>Cependant, lors de la réintégration d'une branche dans
- le tronc, les mathématiques sous-jacentes sont assez
- différentes. Votre branche dédiée est à présent un
+ le tronc, la logique sous-jacente est assez
+ différente. Votre branche dédiée est à présent un
amoncellement de modifications provenant à la fois du tronc
et de votre branche privée et il n'y a donc pas de groupe
de révisions contigu à recopier. En spécifiant l'option
@@ -941,7 +940,7 @@
<para>Il existe également une sous-commande,
<command>svn mergeinfo</command>, qui peut être utile pour
voir non seulement quels ensembles de modifications un
- dossier a absorbé, mais aussi quels ensembles de modifications
+ dossier a absorbés, mais aussi quels ensembles de modifications
il est encore susceptible de recevoir. Ceci donne une sorte
d'aperçu du prochain ensemble de modifications que
<command>svn merge</command> recopiera vers
@@ -960,7 +959,7 @@
r389
r390
-# Quelles modifications sont encore susceptibles d'être fusionnées du
tronc vers la branche?
+# Quelles modifications sont encore susceptibles d'être fusionnées du
tronc vers la branche ?
$ svn mergeinfo http://svn.exemple.com/depot/calc/trunk --show-revs
eligible
r391
r392
@@ -972,7 +971,7 @@
<para>La commande <command>svn mergeinfo</command> prend en
paramètres une URL <quote>source</quote> (d'où les
modifications viennent) et une URL <quote>cible</quote>
- optionnelle (vers laquelle les modifications seraient
+ optionnelle (vers laquelle les modifications sont
fusionnées). Si aucune URL cible n'est fournie, elle suppose
que le dossier actuel est la cible. Dans l'exemple précédent,
puisque nous interrogeons la copie de travail de notre
@@ -1036,16 +1035,16 @@
de rencontrer quelques obstacles (facilement surmontables).
Par exemple, si l'opération de fusion ajoute un nouveau
fichier (ou plus exactement programme son ajout),
- <command>svn revert</command> ne supprimera pas
+ <command>svn revert</command> ne supprime pas
le fichier ; il va juste déprogrammer l'ajout. Vous
vous retrouvez avec un fichier non suivi en versions. Si
ensuite vous tentez à nouveau de lancer la fusion, il
risque d'y avoir des conflits dus au fichier non suivi
- en versions resté <quote>en travers du chemin</quote>.
- Solution ? Après avoir effectué un retour arrière à l'aide
- de <command>svn revert</command>, pensez à nettoyer la
+ en versions resté <quote>en travers du chemin</quote>. La
+ Solution ? Après avoir effectué un retour en arrière à
+ l'aide de <command>svn revert</command>, pensez à nettoyer la
copie de travail et supprimer les fichiers et dossiers
- non suivis en version. Il faut que le résultat de
+ non suivis en versions. Il faut que le résultat de
<command>svn status</command> soit le plus propre possible,
et dans l'idéal vide.</para>
</tip>
@@ -1143,7 +1142,7 @@
permanente. En attendant, en guise de palliatif,
voir <xref
linkend="svn.reposadmin.maint.tk.svndumpfilter"/>.</para>
- </footnote>
+ </footnote>.
</para>
</sect2>
@@ -1216,7 +1215,7 @@
<para>Voilà, c'était la partie difficile : la recherche.
Maintenant que vous savez ce que vous voulez récupérer,
- deux choix s'offrent à vous.</para>
+ deux options s'offrent à vous.</para>
<para>Une possibilité serait d'utiliser
<command>svn merge</command> pour appliquer la révision 808
@@ -1348,7 +1347,7 @@
privée dans le tronc. À la machine à café, vous apprenez par
hasard que Sally a apporté une modification intéressante à
<filename>entier.c</filename> dans le tronc. Vous reportant à
- l'historique des livraisons du tronc, vous vous apercevez
+ l'historique des propagations du tronc, vous vous apercevez
qu'elle a corrigé un bogue crucial en révision 355, qui
impacte directement la fonctionnalité sur laquelle vous êtes
en train de travailler. Vous n'êtes peut-être pas encore prêt
@@ -1388,7 +1387,7 @@
</screen>
<para>Vous pouvez à présent lancer les procédures habituelles
- de tests, avant de livrer cette modification à votre branche.
+ de tests, avant de propager cette modification à votre branche.
Après la propagation, Subversion marque r355 comme ayant été
fusionnée dans la branche, afin qu'une future fusion
<quote>magique</quote> synchronisant votre branche avec le
@@ -1433,7 +1432,7 @@
modifications ; le cas se présente très souvent,
par exemple lorsqu'une équipe gère une
<quote>branche de production</quote> du logiciel
- (nous développerons ce thème dans
+ (ce thème est développé dans
<xref linkend="svn.branchmerge.commonpatterns.release"/>).</para>
<warning>
@@ -1463,8 +1462,8 @@
</warning>
<para>Avertissement : bien que <command>svn diff</command>
- et <command>svn merge</command> soient très similaires au
- niveau conceptuel, leur syntaxe est différente dans de
+ et <command>svn merge</command> soient conceptuellement très
+ similaires, leur syntaxe est différente dans de
nombreux cas. Pour plus de détails, reportez-vous au
<xref linkend="svn.ref"/> ou consultez
<command>svn help</command>. Par exemple,
@@ -1488,12 +1487,12 @@
<para>Si vous fusionnez un dossier et que vous n'avez pas
encore spécifié de cible, <command>svn merge</command>
- supposera qu'il est dans la première situation et essaiera
+ suppose qu'il est dans la première situation et essaie
d'appliquer les modifications dans votre dossier en cours.
Si vous fusionnez un fichier et que ce fichier
(ou un fichier du même nom) existe dans votre dossier de
- travail en cours, <command>svn merge</command> supposera
- qu'il est dans la seconde situation et essaiera d'appliquer
+ travail en cours, <command>svn merge</command> suppose
+ qu'il est dans la seconde situation et essaie d'appliquer
les modifications au fichier local du même nom.</para>
</sect2>
@@ -1502,15 +1501,15 @@
<sect2 id="svn.branchmerge.advanced.advancedsyntax">
<title>Syntaxe de la fusion : pour tout vous dire</title>
- <para>Vous venez de voir des exemples d'utilisation de la
- commande <command>svn merge</command> et vous allez bientôt
- en voir plusieurs autres. Si la confusion règne dans votre
- esprit concernant le fonctionnement des fusions, vous n'êtes
- pas tout seul. De nombreux utilisateurs (en particulier ceux
- qui découvrent la gestion de versions) sont initialement
- perplexes au sujet de la syntaxe de la commande, ainsi que
- quand et comment utiliser cette fonctionnalité. Mais n'ayez
- pas peur, cette commande est en fait bien plus simple que
+ <para>Nous venons de voir des exemples d'utilisation de la
+ commande <command>svn merge</command> et nous allons bientôt
+ en voir plusieurs autres. Si vous n'avez pas bien assimilé le
+ le fonctionnement des fusions, rassurez-vous, vous n'êtes pas un
+ cas isolé. De nombreux utilisateurs (en particulier ceux
+ qui découvrent la gestion de versions) commencent par une phase
+ de perplexité au sujet de la syntaxe de la commande, ainsi que
+ quand et comment utiliser cette fonctionnalité. Mais, en fait,
+ cette commande est bien plus simple que
vous ne le pensez ! Il y a une technique très simple
pour comprendre comment <command>svn merge</command> agit.</para>
@@ -1524,7 +1523,7 @@
les différences sont appliquées à une copie de travail.</para>
<para>Si vous utilisez svn merge pour effectuer de simples
- copies de modifications entre branches, il fera généralement
+ copies de modifications entre branches, elle fait généralement
ce qu'il faut automatiquement. Par exemple, une commande
telle que :</para>
@@ -1532,14 +1531,14 @@
$ svn merge http://svn.exemple.com/depot/calc/une-branche
</screen>
- <para>tentera de dupliquer toutes les modifications faites
+ <para>tente de dupliquer toutes les modifications faites
dans <filename>une-branche</filename> vers votre répertoire
de travail actuel, qui est sans doute une copie de travail
partageant des liens historiques avec la branche. La commande
est suffisamment intelligente pour ne copier que les
modifications que votre copie de travail ne possède pas
encore. Si vous répétez cette commande une fois par semaine,
- elle ne copiera que les modifications
+ elle ne copie que les modifications
<quote>les plus récentes</quote> qui ont eu lieu depuis la
dernière fusion.</para>
@@ -1552,16 +1551,16 @@
<listitem><para>une arborescence initiale (souvent appelée
<firstterm>côté gauche</firstterm>
- de la comparaison)</para></listitem>
+ de la comparaison) ;</para></listitem>
<listitem><para>une arborescence finale (souvent appelée
<firstterm>côté droit</firstterm>
- de la comparaison)</para></listitem>
-
- <listitem><para>une copie de travail qui recevra les
+ de la comparaison) ;</para></listitem>
+
+ <listitem><para>une copie de travail qui reçoit les
différences en tant que modifications locales (souvent
appelée <firstterm>cible</firstterm>
- de la fusion)</para></listitem>
+ de la fusion).</para></listitem>
</orderedlist>
@@ -1577,9 +1576,9 @@
<command>svn revert</command> pour revenir en arrière sur
toutes les modifications.</para>
- <para>La syntaxe de <command>svn merge</command> vous offre
- la possibilité de spécifier les trois paramètres de façon
- assez flexible. Voici quelques exemples :</para>
+ <para>La syntaxe de <command>svn merge</command> est assez
+ flexible quant à la façon de spécifier les trois paramètres.
+ Voici quelques exemples :</para>
<screen>
$ svn merge http://svn.exemple.com/depot/branche1@150 \
@@ -1597,7 +1596,7 @@
cible. La deuxième syntaxe peut être utilisée comme raccourci
pour les cas où vous comparez des révisions différentes de la
même URL. La dernière syntaxe indique que le paramètre copie
- de travail est optionnel ; s'il est omis, elle utilisera
+ de travail est optionnel ; s'il est omis, elle utilise
par défaut le répertoire en cours.</para>
<para>Si le premier exemple donne la syntaxe
@@ -1628,9 +1627,9 @@
<listitem>
<para>Si vous demandez à <command>svn merge</command>
de comparer deux URLs qui n'ont pas de lien entre elles,
- un correctif sera quand même généré et appliqué à votre
- copie de travail, mais aucune métadonnée de fusion ne
- sera créée. Il n'y a pas d'historique commun aux deux
+ un correctif est quand même généré et appliqué à votre
+ copie de travail, mais aucune métadonnée de fusion n'est
+ créée. Il n'y a pas d'historique commun aux deux
sources et les futures fusions
<quote>intelligentes</quote> dépendent de cet
historique commun.</para>
@@ -1643,7 +1642,7 @@
<para>Bien qu'il soit possible de lancer une commande telle
que <userinput>svn merge -r 100:200
<replaceable>http://svn.projetexterieur.com/depot/trunk</replaceable></userinput>,
- le correctif résultant ne comportera aucune métadonnée
+ le correctif résultant ne comporte aucune métadonnée
historique de fusion. À la date d'aujourd'hui, Subversion
n'est pas capable de représenter des URL de dépôts
différents au sein de la propriété
@@ -1711,10 +1710,10 @@
paragraphe va expliquer ces différences.</para>
<para>Pour commencer, supposons que votre copie de travail n'a
- pas de modification locale en cours. Quand vous lancerez
+ pas de modification locale en cours. Quand vous lancez
<command>svn update</command> pour la mettre à jour à une
révision particulière, les modifications envoyées par le
- serveur s'appliqueront toujours <quote>proprement</quote>
+ serveur s'appliquent toujours <quote>proprement</quote>
à votre copie de travail. Le serveur génère le delta en
comparant deux arborescences : d'une part un
instantané virtuel de votre copie de travail, d'autre part
@@ -1729,7 +1728,7 @@
l'utilisateur avancé peut demander au serveur de comparer
<emphasis>n'importe quelle</emphasis> paire d'arborescences,
même des arborescences n'ayant aucun rapport avec la copie
- de travail ! Ce qui laisse potentiellement beaucoup de
+ de travail ! Cela laisse potentiellement beaucoup de
place à l'erreur humaine. Les utilisateurs vont parfois
comparer deux arborescences qui ne sont pas les bonnes,
créant ainsi un delta qui ne s'appliquera pas proprement.
@@ -1739,7 +1738,7 @@
façon que la commande Unix <command>patch</command> se plaint
parfois de <quote>morceaux ratés</quote>
(<foreignphrase>failed hunks</foreignphrase>),
- <command>svn merge</command> se plaindra de
+ <command>svn merge</command> se plaint de
<quote>cibles manquantes omises</quote>
(<foreignphrase>skipped targets</foreignphrase>) :</para>
@@ -1757,7 +1756,7 @@
<para>Dans l'exemple précédent, il est possible que
<filename>baz.c</filename> existe dans les deux instantanés
- de la branche en question ; et que le delta résultant
+ de la branche en question et que le delta résultant
tente de modifier le contenu du fichier, mais que le fichier
n'existe pas dans la copie de travail. Quoi qu'il en soit,
le message <quote>Cible manquante omise</quote> signifie que
@@ -1767,7 +1766,7 @@
en arrière de manière récursive sur toutes les modifications
créées par la fusion
(<userinput>svn revert . --recursive</userinput>), d'effacer
- tout fichier ou dossier non suivi en version restant après le
+ tout fichier ou dossier non suivi en versions restant après le
retour en arrière et de relancer <command>svn merge</command>
avec des paramètres différents.</para>
@@ -2983,7 +2982,7 @@
moment <filename>/trunk</filename> puisse être compilé et
passe avec succès les tests de régression. Une branche
fonctionnelle n'est nécessaire que quand une modification
- nécessite un grand nombre de livraisons susceptibles de
+ nécessite un grand nombre de propagations susceptibles de
déstabiliser le tronc. Une bonne méthode empirique est de se
poser la question suivante : si le développeur
travaillait pendant plusieurs jours en isolation et ensuite
@@ -3131,7 +3130,7 @@
fournisseur est une arborescence au sein de votre propre système
de gestion de versions qui contient des informations fournies
par une entité tierce, ou fournisseur. Chaque version des données
- du fournisseur que vous déciderez d'incorporer dans votre projet
+ du fournisseur que vous décidez d'incorporer dans votre projet
est appelée une
<firstterm>livraison fournisseur</firstterm>.</para>
@@ -3194,10 +3193,10 @@
<para>Nous avons désormais la version actuelle du code source
de libcomplex dans
<filename>/fournisseur/libcomplex/actuel</filename>. À présent,
- nous allons étiqueter cette version (voir
- <xref linkend="svn.branchmerge.tags"/>) et ensuite la copier
- dans la branche de développement principale. Cette opération
- de copie créera un nouveau dossier appelé
+ nous étiquetons cette version (voir
+ <xref linkend="svn.branchmerge.tags"/>) et ensuite nous la
+ copions dans la branche de développement principale. Cette
+ opération de copie crée un nouveau dossier appelé
<filename>libcomplex</filename> au sein du répertoire de notre
projet existant <filename>calc</filename>. C'est dans cette copie
des données du fournisseur que nous ferons nos
@@ -3236,7 +3235,7 @@
libcomplex, la 1.0, par une copie de libcomplex 1.1 et
ensuite ré-appliquer les modifications que nous avions
effectuées précédemment sur cette bibliothèque à la nouvelle
- version. Mais en fait nous allons aborder le problème sous un
+ version. Mais, en fait, nous allons aborder le problème sous un
autre angle, en appliquant les changements apportés à
libcomplex entre les versions 1.0 et 1.1 à notre copie
modifiée de celle-ci.</para>
@@ -3256,12 +3255,12 @@
de la gestion de versions.</para>
<para>Après avoir remplacé le code de la 1.0 par le code de la
- 1.1, <command>svn status</command> listera les fichiers ayant
+ 1.1, <command>svn status</command> liste les fichiers ayant
des modifications locales et peut-être aussi des fichiers
non suivis en versions. Si nous avons fait ce que nous étions
- censés faire, les fichiers non suivis en version sont
+ censés faire, les fichiers non suivis en versions sont
uniquement de nouveaux fichiers introduits par la version 1.1
- de libcomplex ; nous allons donc lancer
+ de libcomplex ; nous lançons donc
<command>svn add</command> sur ces fichiers pour les inclure
dans la gestion de versions. Si le code de la 1.1 ne contient
plus certains fichiers qui étaient dans l'arborescence de la
@@ -3277,10 +3276,10 @@
nous avons faites pour lui donner cet aspect.</para>
<para>Notre branche <filename>actuel</filename> contient
- désormais la nouvelle livraison fournisseur. Nous allons donc
- étiqueter la nouvelle version en 1.1 (de la même façon que
+ désormais la nouvelle livraison fournisseur. Nous étiquetons
+ donc la nouvelle version en 1.1 (de la même façon que
nous avions précédemment étiqueté la livraison fournisseur de
- la version 1.0) et ensuite fusionner les différences entre
+ la version 1.0) et ensuite nous fusionnons les différences entre
les étiquettes de la version précédente et de la nouvelle
version vers notre branche de développement
principale :</para>
@@ -3305,10 +3304,10 @@
version de la bibliothèque, sans la moindre complication ou
conflit.</para>
- <para>Mais les choses ne sont pas toujours aussi simples et en
- fait il arrive assez fréquemment que des fichiers sources
+ <para>Mais les choses ne sont pas toujours aussi simples et, en
+ fait, il arrive assez fréquemment que des fichiers sources
changent d'emplacement d'une version à l'autre d'un logiciel.
- Ceci rend plus compliquée la tâche de s'assurer que nos
+ Ceci complique la tâche de s'assurer que nos
modifications sont toujours valides pour la nouvelle version
du code, et les choses peuvent rapidement dégénérer, jusqu'au
point où nous pouvons être forcés de reporter manuellement nos
@@ -3340,7 +3339,7 @@
processus. Ce script automatise les étapes importantes que
nous avons mentionnées dans la procédure générale de gestion
des branches fournisseurs afin de minimiser les erreurs. Vous
- serez toujours responsable de l'utilisation des commandes
+ êtes toujours responsable de l'utilisation des commandes
<command>svn merge</command> pour fusionner les nouvelles
versions des données tierces vers votre branche de
développement principale, mais
@@ -3361,7 +3360,7 @@
</listitem>
<listitem>
<para>Il prend soin de séries compliquées d'opérations entre
- lesquelles Subversion a besoin d'une livraison
+ lesquelles Subversion a besoin d'une propagation
intermédiaire, telles qu'avant de renommer un fichier ou
un dossier pour la deuxième fois.</para>
</listitem>
@@ -3411,12 +3410,12 @@
il examine le contenu de votre livraison fournisseur
existante, <filename>actuel</filename>, et le compare à la
nouvelle livraison fournisseur. Dans le cas le plus trivial,
- aucun fichier ne sera présent dans une version sans l'être
- dans l'autre et le script effectuera le nouvel import sans
+ aucun fichier n'est présent dans une version sans l'être
+ dans l'autre et le script effectue le nouvel import sans
incident. Cependant, s'il y a des divergences dans
l'agencement des fichiers entre les versions,
- <command>svn_load_dirs.pl</command> vous demandera comment
- résoudre ces différences. Par exemple, vous aurez
+ <command>svn_load_dirs.pl</command> vous demande comment
+ résoudre ces différences. Par exemple, vous avez
l'opportunité d'indiquer au script que vous savez que le
fichier <filename>math.c</filename> de la version 1.0 de
libcomplex a été renommé en <filename>arithmetique.c</filename>
@@ -3428,14 +3427,14 @@
configuration séparé, permettant de spécifier des propriétés
sur des fichiers et dossiers, correspondants à une expression
régulière, qui vont être <emphasis>ajoutés</emphasis> au
- dépôt. Ce fichier de configuration sera indiqué à
+ dépôt. Ce fichier de configuration est indiqué à
<command>svn_load_dirs.pl</command> en utilisant l'option
<option>-p</option> en ligne de commande. Chaque ligne du
fichier de configuration est un ensemble de deux ou quatre
valeurs délimitées par des espaces : une expression
régulière du style Perl à laquelle comparer le chemin ajouté,
un mot clé de contrôle (soit <literal>break</literal> soit
- <literal>cont</literal>) et ensuite en option un nom de
+ <literal>cont</literal>) et ensuite, en option, un nom de
propriété et une valeur.</para>
<screen>
@@ -3452,18 +3451,18 @@
<literal>break</literal> (ce qui signifie qu'aucune autre
modification de propriété ne doit être appliquée à ce chemin).
Si le terme de contrôle est <literal>cont</literal>
- (abréviation de continuer), la comparaison continuera avec la
+ (abréviation de continuer), la comparaison continue avec la
ligne suivante du fichier de configuration.</para>
- <para>Tout espace faisant partie de l'expression régulière, du
+ <para>Toute espace faisant partie de l'expression régulière, du
nom de la propriété ou de la valeur de la propriété doit être
- entouré d'apostrophes ou de guillemets. Vous pouvez banaliser
+ entourée d'apostrophes ou de guillemets. Vous pouvez banaliser
les guillemets et apostrophes qui ne sont pas utilisés pour
- entourer un espace en les faisant précéder d'une barre oblique
+ entourer une espace en les faisant précéder d'une barre oblique
inversée (ou <quote>antislash</quote> :
<literal>\</literal>). L'antislash ne banalise que les
guillemets et apostrophes pendant le traitement du fichier de
- configuration, donc pas la peine de protéger d'autres
+ configuration, ce n'est donc pas la peine de protéger d'autres
caractères au-delà de ce qui est nécessaire pour
l'expression régulière.</para>
@@ -3480,7 +3479,7 @@
avons présenté les concepts d'étiquettes et de branches et
montré comment Subversion implémente ces concepts en copiant des
répertoires avec la commande <command>svn copy</command>. Nous
- ~avons expliqué comment utiliser <command>svn merge</command>
+ avons expliqué comment utiliser <command>svn merge</command>
pour copier des modifications d'une branche à l'autre ou pour
revenir en arrière sur des modifications non-satisfaisantes.
Nous avons étudié l'utilisation de <command>svn switch</command>
More information about the svnbook-dev
mailing list