[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