[svnbook] r3723 committed - * src/fr/book/ch04-branching-and-merging.xml...

svnbook at googlecode.com svnbook at googlecode.com
Fri Apr 23 15:22:31 CDT 2010


Revision: 3723
Author: subversif999 at gmail.com
Date: Fri Apr 23 13:21:19 2010
Log: * src/fr/book/ch04-branching-and-merging.xml
   - Translate Chapter 4

http://code.google.com/p/svnbook/source/detail?r=3723

Modified:
  /trunk/src/fr/book/ch04-branching-and-merging.xml

=======================================
--- /trunk/src/fr/book/ch04-branching-and-merging.xml	Fri Sep 12 07:39:35  
2008
+++ /trunk/src/fr/book/ch04-branching-and-merging.xml	Fri Apr 23 13:21:19  
2010
@@ -1,70 +1,77 @@
  <chapter id="svn.branchmerge">
-  <title>Branching and Merging</title>
+  <title>Gestion des branches</title>

    <blockquote>
      <attribution>Confucius</attribution>
      <para><quote>君子务本
-      (It is upon the Trunk that a gentleman works.)</quote></para>
+      (C'est sur le Tronc qu'un gentleman travaille.)</quote></para>
    </blockquote>


-  <para>Branching, tagging, and merging are concepts common to
-    almost all version control systems.  If you're not familiar with
-    these ideas, we provide a good introduction in this chapter.  If
-    you are familiar, hopefully you'll find it interesting to
-    see how Subversion implements them.</para>
-
-  <para>Branching is a fundamental part of version control.  If
-    you're going to allow Subversion to manage your data, this
-    is a feature you'll eventually come to depend on.  This chapter
-    assumes that you're already familiar with Subversion's basic
-    concepts (<xref linkend="svn.basic"/>).</para>
+  <para>La création, l'étiquetage et la fusion de branches sont des
+    concepts communs à tous les systèmes de gestion de versions. Si
+    vous n'êtes pas familier avec elles, nous fournissons dans ce
+    chapitre une bonne introduction à ces idées. Si vous êtes familier
+    avec elles, vous devriez, avec un peu de chance, être intéressé
+    par la façon dont Subversion les met en pratique.</para>
+
+  <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
+    déjà familier avec les notions de bases de Subversion
+    (<xref linkend="svn.basic"/>).</para>


    <!-- =================================================================  
-->
    <!-- =================================================================  
-->
    <!-- =================================================================  
-->
    <sect1 id="svn.branchmerge.whatis">
-    <title>What's a Branch?</title>
-
-    <para>Suppose it's your job to maintain a document for a division
-      in your company—a handbook of some sort.  One day a different
-      division asks you for the same handbook, but with a few parts
-      <quote>tweaked</quote> for them, since they do things slightly
-      differently.</para>
-
-    <para>What do you do in this situation?  You do the obvious: make
-      a second copy of your document and begin maintaining the two
-      copies separately.  As each department asks you to make small
-      changes, you incorporate them into one copy or the other.</para>
-
-    <para>You often want to make the same change to both copies.  For
-      example, if you discover a typo in the first copy, it's very
-      likely that the same typo exists in the second copy.  The two
-      documents are almost the same, after all; they differ only in
-      small, specific ways.</para>
-
-    <para>This is the basic concept of a
-      <firstterm>branch</firstterm>—namely, a line of
-      development that exists independently of another line, yet still
-      shares a common history if you look far enough back in time.  A
-      branch always begins life as a copy of something, and moves on
-      from there, generating its own history (see <xref
-      linkend="svn.branchmerge.whatis.dia-1"/>).</para>
+    <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.
+      Un beau jour, une autre division vous demande le même manuel,
+      mais avec quelques parties <quote>modifiées</quote> spécialement
+      pour elle, puisqu'elle fait les choses légèrement
+      différemment.</para>
+
+    <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
+      dans une copie ou dans l'autre.</para>
+
+    <para>Vous voulez souvent faire la même modification dans les deux
+      copies. Par exemple, si vous découvrez une coquille dans la
+      première copie, il est très probable que la même coquille existe
+      dans la deuxième copie. Les deux documents sont presque
+      identiques, après tout ; ils ne diffèrent qu'en quelques points
+      mineurs et spécifiques.</para>
+
+    <para>Voilà le concept de <firstterm>branche</firstterm>,
+      c'est-à-dire une ligne de développement qui existe
+      indépendamment d'une autre ligne, mais partage cependant une
+      histoire commune avec elle, si vous remontez suffisamment loin en
+      arrière dans le temps. Une branche commence toujours sa vie en
+      tant que copie de quelque chose, puis diffère à partir de là,
+      selon une histoire qui lui est propre (voir la
+      <xref linkend="svn.branchmerge.whatis.dia-1"/>).</para>

        <figure id="svn.branchmerge.whatis.dia-1">
-        <title>Branches of development</title>
+        <title>Branches de développement</title>
          <graphic fileref="images/ch04dia1.png"/>
        </figure>

-    <para>Subversion has commands to help you maintain parallel
-      branches of your files and directories.  It allows you to create
-      branches by copying your data, and remembers that the copies are
-      related to one another.  It also helps you duplicate changes
-      from one branch to another.  Finally, it can make portions of
-      your working copy reflect different branches so that you can
-      <quote>mix and match</quote> different lines of development in
-      your daily work.</para>
+    <para>Subversion possède des commandes pour vous aider à maintenir
+      des branches parallèles de vos fichiers et répertoires. Il vous
+      permet de créer des branches en faisant des copies de vos
+      données et se souvient que les copies sont liées les unes aux
+      autres. Il vous aide aussi à dupliquer les modifications d'une
+      branche vers une autre. Enfin, il permet que des portions de
+      votre copie de travail correspondent à différentes branches,
+      afin que vous puissiez <quote>mélanger</quote> différentes
+      lignes de développement dans votre travail quotidien.</para>

    </sect1>

@@ -72,347 +79,374 @@
    <!-- =================================================================  
-->
    <!-- =================================================================  
-->
    <sect1 id="svn.branchmerge.using">
-    <title>Using Branches</title>
-
-    <para>At this point, you should understand how each commit creates
-      an entirely new filesystem tree (called a <quote>revision</quote>)
-      in the repository.  If you don't, go back and read about revisions in
+    <title>Utilisation des branches</title>
+
+    <para>Rendu à ce chapitre, vous devriez avoir compris que chaque
+      propagation crée une arborescence de fichiers entièrement
+      nouvelle (appelée <quote>révision</quote>) dans le dépôt. Si ce
+      n'est pas le cas, retournez vous informer sur les révisions dans
        <xref linkend="svn.basic.in-action.revs"/>.</para>

-    <para>For this chapter, we'll go back to the same example from
-      <xref linkend="svn.basic"/>.  Remember that you and your
-      collaborator, Sally, are sharing a repository that contains two
-      projects, <filename>paint</filename> and
-      <filename>calc</filename>.  Notice that in <xref
-      linkend="svn.branchmerge.using.dia-1"/>, however, each project
-      directory now contains subdirectories named
-      <filename>trunk</filename> and <filename>branches</filename>.
-      The reason for this will soon become clear.</para>
+    <para>Pour ce chapitre, nous reprendrons le même exemple qu'au
+      <xref linkend="svn.basic"/>. Souvenez-vous que votre
+      collaboratrice Sally et vous partagez un dépôt qui contient
+      deux projets, <filename>paint</filename> et
+      <filename>calc</filename>. Notez cependant que dans la
+       <xref linkend="svn.branchmerge.using.dia-1"/>, le dossier de
+       chaque projet contient désormais des sous-dossiers nommés
+       <filename>trunk</filename> et <filename>branches</filename>.
+       Les raisons de cette arborescence apparaîtront bientôt
+       clairement.</para>

        <figure id="svn.branchmerge.using.dia-1">
-        <title>Starting repository layout</title>
+        <title>Structure initiale du dépôt</title>
          <graphic fileref="images/ch04dia2.png"/>
        </figure>

-    <para>As before, assume that Sally and you both have working
-      copies of the <quote>calc</quote> project.  Specifically, you
-      each have a working copy of <filename>/calc/trunk</filename>.
-      All the files for the project are in this subdirectory rather
-      than in <filename>/calc</filename> itself, because your team has
-      decided that <filename>/calc/trunk</filename> is where the
-      <quote>main line</quote> of development is going to take
-      place.</para>
-
-    <para>Let's say that you've been given the task of implementing a
-      large software feature.  It will take a long time to write, and
-      will affect all the files in the project.  The immediate problem
-      is that you don't want to interfere with Sally, who is in the
-      process of fixing small bugs here and there.  She's depending on
-      the fact that the latest version of the project (in
-      <filename>/calc/trunk</filename>) is always usable.  If you
-      start committing your changes bit by bit, you'll surely break
-      things for Sally (and other team members as well).</para>
-
-    <para>One strategy is to crawl into a hole: you and Sally can stop
-      sharing information for a week or two.  That is, start gutting
-      and reorganizing all the files in your working copy, but don't
-      commit or update until you're completely finished with the task.
-      There are a number of problems with this, though.  First, it's
-      not very safe.  Most people like to save their work to the
-      repository frequently, should something bad accidentally happen
-      to their working copy.  Second, it's not very flexible.  If you
-      do your work on different computers (perhaps you have a working
-      copy of <filename>/calc/trunk</filename> on two different
-      machines), you'll need to manually copy your changes back and
-      forth or just do all the work on a single computer.  By that
-      same token, it's difficult to share your changes in progress
-      with anyone else.  A common software development <quote>best
-      practice</quote> is to allow your peers to review your work as
-      you go.  If nobody sees your intermediate commits, you lose
-      potential feedback and may end up going down the wrong path for
-      weeks before another person on your team notices.  Finally, when
-      you're finished with all your changes, you might find it very
-      difficult to remerge your final work with the rest of the
-      company's main body of code.  Sally (or others) may have made
-      many other changes in the repository that are difficult to
-      incorporate into your working copy—especially if you
-      run <command>svn update</command> after weeks of
-      isolation.</para>
-
-    <para>The better solution is to create your own branch, or line of
-      development, in the repository.  This allows you to save your
-      half-broken work frequently without interfering with others, yet
-      you can still selectively share information with your
-      collaborators.  You'll see exactly how this works as we go.
-      </para>
+    <para>Comme avant, supposons que Sally et vous avez tous deux une
+      copie de travail du projet <quote>calc</quote>. Plus
+      spécifiquement, vous avez chacun une copie de travail de
+      <filename>/calc/trunk</filename>. Tous les fichiers du projet
+      sont dans ce sous-dossier plutôt que dans
+      <filename>/calc</filename> lui-même, parce que votre équipe a
+      décidé que la <quote>ligne principale</quote> de développement
+      du projet allait se situer
+      dans <filename>/calc/trunk</filename>.</para>
+
+    <para>Disons que l'on vous a attribué la tâche d'implémenter une
+      fonctionnalité du logiciel qui prendra longtemps à écrire et
+      touchera à tous les fichiers du projet. Le problème immédiat est
+      que vous ne voulez pas déranger Sally, qui est en train de
+      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
+      à petit, vous allez sûrement rendre les choses difficiles pour
+      Sally (ainsi que pour d'autres membres de l'équipe).</para>
+
+    <para>Une stratégie possible est de vous isoler : vous pouvez
+      arrêter de partager des informations avec Sally pendant une
+      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,
+      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
+      vous travaillez sur différents ordinateurs (vous avez peut-être
+      une copie de travail de <filename>/calc/trunk</filename> sur
+      deux machines différentes), vous aurez besoin de transférer
+      manuellement vos changements entre les deux, ou bien de
+      travailler sur une seule machine. De la même façon, il est
+      difficile de partager vos changements en cours avec quelqu'un
+      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
+      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,
+      vous pourriez avoir du mal à fusionner votre travail avec le
+      code du reste de l'équipe. Sally (et les autres) peuvent avoir
+      apporté de nombreux autres changements au dépôt, changements qui
+      seront difficiles à incorporer dans votre copie de travail,
+      notamment si vous lancez <command>svn update</command> après des
+      semaines d'isolation.</para>
+
+    <para>Une solution bien meilleure est de créer votre propre
+      branche, ou ligne de développement, dans le dépôt. Ceci vous
+      permettra de sauvegarder fréquemment votre travail un peu
+      boiteux sans interférer avec vos collaborateurs ; vous pourrez
+      toutefois partager une sélection d'informations avec eux. Vous
+      découvrirez comment tout cela fonctionne exactement au fur et à
+      mesure de ce chapitre.</para>

      <!-- ===============================================================  
-->
      <sect2 id="svn.branchmerge.using.create">
-      <title>Creating a Branch</title>
-
-      <para>Creating a branch is very simple—you make a copy of
-        the project in the repository using the <command>svn
-        copy</command> command.  Subversion is able to copy not only
-        single files, but whole directories as well.  In this case,
-        you want to make a copy of the
-        <filename>/calc/trunk</filename> directory.  Where should the
-        new copy live?  Wherever you wish—it's a matter of
-        project policy.  Let's say that your team has a policy of
-        creating branches in the <filename>/calc/branches</filename>
-        area of the repository, and you want to name your branch
-        <literal>my-calc-branch</literal>.  You'll want to create a
-        new directory,
-        <filename>/calc/branches/my-calc-branch</filename>, which
-        begins its life as a copy of
+      <title>Création d'une branche</title>
+
+      <para>Créer une branche est très simple : il s'agit juste de  
faire
+        une copie du projet dans le dépôt avec la commande
+        <command>svn copy</command>. Subversion est capable de copier
+        non seulement de simples fichiers, mais aussi des dossiers
+        entiers. Dans le cas présent, vous voulez faire une copie du
+        dossier <filename>/calc/trunk</filename>. Où doit résider la
+        nouvelle copie ? Là où vous le désirez, cette décision faisant
+        partie de la gestion du projet. Supposons que votre équipe ait
+        pour convention de créer les branches dans la zone
+        <filename>/calc/branches</filename> du dépôt et que vous
+        vouliez nommer votre branche
+        <literal>ma-branche-calc</literal>. Vous créez alors un
+        nouveau dossier,
+        <filename>/calc/branches/ma-branche-calc</filename>,
+        qui commence ainsi sa vie en tant que copie de
          <filename>/calc/trunk</filename>.</para>

-      <para>You may already have seen <command>svn copy</command> used
-        to copy one file to another within a working copy.  But it can
-        also be used to do a <quote>remote</quote> copy entirely
-        within the repository.  Just copy one URL to another:</para>
+      <para>Vous avez peut-être déjà utilisé
+        <command>svn copy</command> pour copier un fichier vers un
+        autre à l'intérieur d'une copie de travail. Mais il peut aussi
+        être utilisé pour effectuer une copie <quote>distante</quote>
+        entièrement à l'intérieur du dépôt. Il suffit de copier une
+        URL vers une autre :</para>

        <screen>
-$ svn copy http://svn.example.com/repos/calc/trunk \
-           http://svn.example.com/repos/calc/branches/my-calc-branch \
-      -m "Creating a private branch of /calc/trunk."
-
-Committed revision 341.
+$ svn copy http://svn.exemple.com/depot/calc/trunk \
+           http://svn.exemple.com/depot/calc/branches/ma-branche-calc \
+      -m "Création d'une branche privée à partir de /calc/trunk."
+
+Révision 341 propagée.
  </screen>

-      <para>This command causes a near-instantaneous commit in the
-        repository, creating a new directory in revision 341.  The new
-        directory is a copy of <filename>/calc/trunk</filename>.  This
-        is shown in
+      <para>Cette commande entraîne une opération quasi-instantanée
+        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"/>.
+
          <footnote>
-        <para>Subversion does not support copying between different
-        repositories.  When using URLs with <command>svn
-        copy</command> or <command>svn move</command>, you can only
-        copy items within the same repository.</para>
+        <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>

-        While it's also possible to create a branch by
-        using <command>svn copy</command> to duplicate a directory
-        within the working copy, this technique isn't recommended.  It
-        can be quite slow, in fact!  Copying a directory on the
-        client side is a linear-time operation, in that it actually
-        has to duplicate every file and subdirectory on the local disk.
-        Copying a directory on the server, however, is a constant-time
-        operation, and it's the way most people create
-        branches.</para>
+        Bien qu'il soit aussi possible de créer une branche en
+        utilisant <command>svn copy</command> pour dupliquer un dossier
+        à l'intérieur de la copie de travail, cette technique n'est
+        pas recommandée. Elle peut s'avérer assez lente, en fait !
+        Copier un dossier côté client est une opération linéaire en
+        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
+        des branches.</para>

        <figure id="svn.branchmerge.using.create.dia-1">
-        <title>Repository with new copy</title>
+        <title>Dépôt avec nouvelle copie</title>
          <graphic fileref="images/ch04dia3.png"/>
        </figure>

        <sidebar>
-        <title>Cheap Copies</title>
-
-        <para>Subversion's repository has a special design.  When you
-          copy a directory, you don't need to worry about the
-          repository growing huge—Subversion doesn't actually
-          duplicate any data.  Instead, it creates a new directory
-          entry that points to an <emphasis>existing</emphasis> tree.
-          If you're an experienced Unix user, you'll recognize this as
-          the same concept behind a hard link.  As further changes are
-          made to files and directories beneath the copied directory,
-          Subversion continues to employ this hard link concept where
-          it can.  It duplicates data only when it is necessary to
-          disambiguate different versions of objects.</para>
-
-        <para>This is why you'll often hear Subversion users talk
-          about <quote>cheap copies.</quote>  It doesn't matter how
-          large the directory is—it takes a very tiny, constant
-          amount of time and space to make a copy of it.  In fact,
-          this feature is the basis of how commits work in Subversion:
-          each revision is a <quote>cheap copy</quote> of the previous
-          revision, with a few items lazily changed within.  (To read
-          more about this, visit Subversion's web site and read about
-          the <quote>bubble up</quote> method in Subversion's design
-          documents.)</para>
-
-        <para>Of course, these internal mechanics of copying and
-          sharing data are hidden from the user, who simply sees
-          copies of trees.  The main point here is that copies are
-          cheap, both in time and in space.  If you create a branch
-          entirely within the repository (by running <userinput>svn copy
-          <replaceable>URL1</replaceable>  
<replaceable>URL2</replaceable></userinput>), it's a quick, constant-time  
operation.
-          Make branches as often as you want.</para>
+        <title>Des copies peu coûteuses</title>
+
+        <para>Le dépôt Subversion a un design particulier. Quand vous
+          copiez un dossier, il n'y a pas à s'en faire pour la taille
+          du dépôt : en fait Subversion ne duplique aucune donnée. Au
+          lieu de ça, il crée une nouvelle entrée de dossier qui pointe
+          vers une arborescence <emphasis>existante</emphasis>. Si
+          vous êtes un utilisateur expérimenté d'Unix, vous
+          reconnaîtrez là le concept de lien matériel
+          (<quote>hard link</quote>). Au fur et à mesure des
+          modifications faites aux fichiers et dossiers sous le
+          dossier copié, Subversion continue à employer ce concept
+          de lien matériel quand il le peut. Il duplique les données
+          seulement s'il est nécessaire de lever l'ambiguïté entre
+          différentes versions d'objets.</para>
+
+        <para>C'est pourquoi vous entendrez souvent les utilisateurs
+          de Subversion parler de <quote>copies peu coûteuses</quote>
+          (<foreignphrase>cheap copies</foreignphrase> en anglais).
+          Peu importe la taille du dossier, la durée de la copie
+          est constante et très faible,
+          tout comme l'espace disque nécessaire. En fait,
+          cette fonctionnalité est à la base du fonctionnement des
+          propagations dans Subversion : chaque révision est une
+          <quote>copie peu coûteuse</quote> de la révision précédente,
+          avec juste quelques éléments modifiés à l'intérieur (pour en
+          savoir plus à ce sujet, visitez le site web de Subversion et
+          lisez les paragraphes concernant la méthode
+          <quote>bubble up</quote> dans les documents de conception
+          de Subversion).</para>
+
+        <para>Bien sûr, cette mécanique interne de copie et de partage
+          des données est transparente pour l'utilisateur, qui n'y
+          voit que de simples copies d'arborescences. Le point
+          essentiel ici est que les copies sont peu coûteuses, aussi
+          bien en temps qu'en espace disque. Si vous créez une branche
+          entièrement à l'intérieur du dépôt (en lançant
+          <userinput>svn copy <replaceable>URL1</replaceable>
+          <replaceable>URL2</replaceable></userinput>), c'est une
+          opération rapide, à durée constante. Créez des branches
+          aussi souvent que vous le souhaitez.</para>
        </sidebar>

      </sect2>

      <!-- ===============================================================  
-->
      <sect2 id="svn.branchmerge.using.work">
-      <title>Working with Your Branch</title>
-
-      <para>Now that you've created a branch of the project, you can
-        check out a new working copy to start using it:</para>
+      <title>Travail sur votre branche</title>
+
+      <para>Maintenant que vous avez créé votre branche du projet,
+        vous pouvez extraire une nouvelle copie de travail et
+        commencer à l'utiliser :</para>

        <screen>
-$ svn checkout http://svn.example.com/repos/calc/branches/my-calc-branch
-A  my-calc-branch/Makefile
-A  my-calc-branch/integer.c
-A  my-calc-branch/button.c
-Checked out revision 341.
+$ svn checkout http://svn.exemple.com/depot/calc/branches/ma-branche-calc
+A  ma-branche-calc/Makefile
+A  ma-branche-calc/entier.c
+A  ma-branche-calc/bouton.c
+Révision 341 extraite.
  </screen>

-      <para>There's nothing special about this working copy; it simply
-        mirrors a different directory in the repository.  When you
-        commit changes, however, Sally won't see them when she
-        updates, because her working copy is of
-        <filename>/calc/trunk</filename>.  (Be sure to read <xref
-        linkend="svn.branchmerge.switchwc"/> later in this chapter: the
-        <command>svn switch</command> command is an alternative way of
-        creating a working copy of a branch.)</para>
-
-      <para>Let's pretend that a week goes by, and the following
-        commits happen:</para>
+      <para>Cette copie de travail n'a rien de spéciale ; elle
+        correspond juste à un dossier différent du dépôt. Cependant,
+        quand vous propagerez vos modifications, Sally ne les verra
+        pas quand elle effectuera une mise à jour, car sa copie de
+        travail correspond à <filename>calc/trunk</filename> (pensez
+        bien à lire <xref linkend="svn.branchmerge.switchwc"/> plus
+        loin dans ce chapitre : la commande
+        <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
+        suivantes ont lieu :</para>

        <itemizedlist>
          <listitem><para>
-          You make a change to
-          <filename>/calc/branches/my-calc-branch/button.c</filename>,
-          which creates revision 342.</para>
+          Vous modifiez
+          <filename>/calc/branches/ma-branche-calc/bouton.c</filename>,
+          ce qui crée la révision 342.</para>
          </listitem>

          <listitem><para>
-          You make a change to
-          <filename>/calc/branches/my-calc-branch/integer.c</filename>,
-          which creates revision 343.</para>
+          Vous modifiez
+          <filename>/calc/branches/ma-branche-calc/entier.c</filename>,
+          ce qui crée la révision 343.</para>
          </listitem>

          <listitem><para>
-          Sally makes a change to
-          <filename>/calc/trunk/integer.c</filename>, which creates
-          revision 344.</para>
+          Sally modifie
+          <filename>/calc/trunk/entier.c</filename>,
+          ce qui crée la révision 344.</para>
          </listitem>
        </itemizedlist>

-      <para>Now two independent lines of development (shown
-        in <xref linkend="svn.branchmerge.using.work.dia-1"/>) are  
happening on
-        <filename>integer.c</filename>.</para>
+      <para>À présent, deux lignes de développement indépendantes (voir
+      la <xref linkend="svn.branchmerge.using.work.dia-1"/>) existent
+      pour <filename>entier.c</filename>.</para>

        <figure id="svn.branchmerge.using.work.dia-1">
-        <title>The branching of one file's history</title>
+        <title>Historique des branches d'un fichier</title>
          <graphic fileref="images/ch04dia4.png"/>
        </figure>

-      <para>Things get interesting when you look at the history of
-        changes made to your copy of
-        <filename>integer.c</filename>:</para>
+      <para>Les choses deviennent intéressantes quand on regarde
+        l'historique des modifications apportées à votre copie de
+        <filename>entier.c</filename> :</para>

        <screen>
  $ pwd
-/home/user/my-calc-branch
-
-$ svn log -v integer.c
+/home/utilisateur/ma-branche-calc
+
+$ svn log -v entier.c
  ------------------------------------------------------------------------
-r343 | user | 2002-11-07 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines
-Changed paths:
-   M /calc/branches/my-calc-branch/integer.c
-
-* integer.c:  frozzled the wazjub.
+r343 | utilisateur | 2002-11-07 15:27:56 -0600 (jeu. 07 nov. 2002) | 2  
lignes
+Chemins modifiés :
+   M /calc/branches/ma-branche-calc/entier.c
+
+* entier.c:  machiné le bidule.

  ------------------------------------------------------------------------
-r341 | user | 2002-11-03 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines
-Changed paths:
-   A /calc/branches/my-calc-branch (from /calc/trunk:340)
-
-Creating a private branch of /calc/trunk.
+r341 | utilisateur | 2002-11-03 15:27:56 -0600 (jeu. 07 nov. 2002) | 2  
lignes
+Chemins modifiés :
+   A /calc/branches/ma-branche-calc (from /calc/trunk:340)
+
+Création d'une branche privée à partir de /calc/trunk.

  ------------------------------------------------------------------------
-r303 | sally | 2002-10-29 21:14:35 -0600 (Tue, 29 Oct 2002) | 2 lines
-Changed paths:
-   M /calc/trunk/integer.c
-
-* integer.c:  changed a docstring.
+r303 | sally | 2002-10-29 21:14:35 -0600 (mar. 29 oct. 2002) | 2 lignes
+Chemins modifiés :
+   M /calc/trunk/entier.c
+
+* entier.c:  modifié une docstring.

  ------------------------------------------------------------------------
-r98 | sally | 2002-02-22 15:35:29 -0600 (Fri, 22 Feb 2002) | 2 lines
-Changed paths:
-   A /calc/trunk/integer.c
-
-* integer.c:  adding this file to the project.
+r98 | sally | 2002-02-22 15:35:29 -0600 (ven. 22 fev. 2002) | 2 lignes
+Chemins modifiés :
+  A /calc/trunk/entier.c
+* entier.c:  ajout du fichier dans ce projet.

  ------------------------------------------------------------------------
  </screen>

-      <para>Notice that Subversion is tracing the history of your
-        branch's <filename>integer.c</filename> all the way back
-        through time, even traversing the point where it was copied.
-        It shows the creation of the branch as an event in the
-        history, because <filename>integer.c</filename> was implicitly
-        copied when all of <filename>/calc/trunk/</filename> was
-        copied.  Now look at what happens when Sally runs the same
-        command on her copy of the file:</para>
+      <para>Notez bien que Subversion reprend tout l'historique du
+        <filename>entier.c</filename> de votre branche à travers le
+        temps, remontant même au delà du point où il a été copié. Il
+        liste la création d'une branche en tant qu'élément de
+        l'historique, parce qu'<filename>entier.c</filename> a été
+        copié implicitement lorsque <filename>calc/trunk</filename>
+        tout entier a été copié. Maintenant regardez ce qui se passe
+        quand Sally lance la même commande sur sa copie du
+        fichier :</para>

        <screen>
  $ pwd
  /home/sally/calc

-$ svn log -v integer.c
+$ svn log -v entier.c
  ------------------------------------------------------------------------
-r344 | sally | 2002-11-07 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines
-Changed paths:
-   M /calc/trunk/integer.c
-
-* integer.c:  fix a bunch of spelling errors.
-
-------------------------------------------------------------------------
-r303 | sally | 2002-10-29 21:14:35 -0600 (Tue, 29 Oct 2002) | 2 lines
-Changed paths:
-   M /calc/trunk/integer.c
-
-* integer.c:  changed a docstring.
-
-------------------------------------------------------------------------
-r98 | sally | 2002-02-22 15:35:29 -0600 (Fri, 22 Feb 2002) | 2 lines
-Changed paths:
-   A /calc/trunk/integer.c
-
-* integer.c:  adding this file to the project.
+r344 | sally | 2002-11-07 15:27:56 -0600 (jeu. 07 nov. 2002) | 2 lignes
+ Chemins modifiés :
+    M /calc/trunk/entier.c
+
+ * entier.c:  corrigé un ensemble de coquilles.
+
+ ------------------------------------------------------------------------
+ r303 | sally | 2002-10-29 21:14:35 -0600 (mar. 29 oct. 2002) | 2 lignes
+ Chemins modifiés :
+    M /calc/trunk/entier.c
+
+ * entier.c:  modifié une docstring.
+
+ ------------------------------------------------------------------------
+ r98 | sally | 2002-02-22 15:35:29 -0600 (ven. 22 fev. 2002) | 2 lignes
+ Chemins modifiés :
+   A /calc/trunk/entier.c
+
+* entier.c:  ajout du fichier dans ce projet.

  ------------------------------------------------------------------------
  </screen>

-      <para>Sally sees her own revision 344 change, but not the change
-        you made in revision 343.  As far as Subversion is concerned,
-        these two commits affected different files in different
-        repository locations.  However, Subversion
-        <emphasis>does</emphasis> show that the two files share a
-        common history.  Before the branch copy was made in revision
-        341, the files used to be the same file.  That's why you and
-        Sally both see the changes made in revisions 303 and
-        98.</para>
+      <para>Sally voit la modification due à sa propre révision 344,
+        mais pas le changement que vous avez effectué dans la révision
+        343. Pour Subversion, ces deux propagations ont touché des
+        fichiers différents dans des dossiers distincts. Néanmoins,
+        Subversion indique bien que les deux fichiers partagent une
+        histoire commune. Avant que la copie de branche n'ait été
+        faite en révision 341, les fichiers ne faisaient qu'un. C'est
+        pourquoi Sally et vous voyez tous les deux les modifications
+        apportées en révisions 303 et 98.</para>

      </sect2>

      <!-- ===============================================================  
-->
      <sect2 id="svn.branchmerge.using.concepts">
-      <title>The Key Concepts Behind Branching</title>
-
-      <para>You should remember two important lessons
-        from this section.  First, Subversion has no internal concept
-        of a branch—it knows only how to make copies.  When you
-        copy a directory, the resultant directory is only
-        a <quote>branch</quote> because <emphasis>you</emphasis>
-        attach that meaning to it.  You may think of the directory
-        differently, or treat it differently, but to Subversion it's
-        just an ordinary directory that happens to carry some extra
-        historical information.</para>
-
-      <para>Second, because of this copy mechanism, Subversion's
-        branches exist as <emphasis>normal filesystem
-        directories</emphasis> in the repository.  This is different
-        from other version control systems, where branches are
-        typically defined by adding
-        extra-dimensional <quote>labels</quote> to collections of
-        files.  The location of your branch directory doesn't matter
-        to Subversion.  Most teams follow a convention of putting all
-        branches into a <filename>/branches</filename> directory, but
-        you're free to invent any policy you wish.</para>
+      <title>Gestion des branches par Subversion : notions clé</title>
+
+      <para>Il y a deux leçons importantes à retenir de ce paragraphe.
+        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>
+        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
+        associées des informations extra-historiques.</para>
+
+      <para>Deuxièmement, à cause de ce mécanisme de copie, les
+        branches de Subversion existent en tant que
+        <emphasis>dossiers classiques du système de fichiers</emphasis>
+        du dépôt. En cela, Subversion diffère des autres systèmes
+        de gestion de versions, où les branches sont définies par
+        l'ajout d'<quote>étiquettes</quote> extra-dimensionnelles
+        à des groupes de fichiers. L'emplacement du dossier de votre
+        branche importe peu à Subversion. La plupart des équipes ont
+        pour convention de placer toutes les branches dans un dossier
+        <filename>/branches</filename>, mais vous êtes libre
+        d'inventer la convention qui vous plaît.</para>

      </sect2>

@@ -423,201 +457,228 @@
    <!-- =================================================================  
-->
    <!-- =================================================================  
-->
    <sect1 id="svn.branchmerge.basicmerging">
-    <title>Basic Merging</title>
-
-    <para>Now you and Sally are working on parallel branches of the
-      project: you're working on a private branch, and Sally is
-      working on the <firstterm>trunk</firstterm>, or main line of
-      development.</para>
-
-    <para>For projects that have a large number of contributors, it's
-      common for most people to have working copies of the trunk.
-      Whenever someone needs to make a long-running change that is
-      likely to disrupt the trunk, a standard procedure is to create a
-      private branch and commit changes there until all the work is
-      complete.</para>
-
-    <para>So, the good news is that you and Sally aren't interfering
-      with each other.  The bad news is that it's very easy to drift
-      <emphasis>too</emphasis> far apart.  Remember that one of the
-      problems with the <quote>crawl in a hole</quote> strategy is
-      that by the time you're finished with your branch, it may be
-      near-impossible to merge your changes back into the trunk
-      without a huge number of conflicts.</para>
-
-    <para>Instead, you and Sally might continue to share changes as
-      you work.  It's up to you to decide which changes are worth
-      sharing; Subversion gives you the ability to selectively
-      <quote>copy</quote> changes between branches.  And when you're
-      completely finished with your branch, your entire set of branch
-      changes can be copied back into the trunk.  In Subversion
-      terminology, the general act of replicating changes from one
-      branch to another is called <firstterm>merging</firstterm>, and
-      it is performed using various invocations of the <command>svn
-      merge</command> command.</para>
-
-    <para>In the examples that follow, we're assuming that both your
-      Subversion client and server are running Subversion 1.5 (or
-      later).  If either client or server is older than version 1.5,
-      things are more complicated: the system won't track changes
-      automatically, and you'll have to use painful manual methods to
-      achieve similar results.  That is, you'll always need to use the
-      detailed merge syntax to specify specific ranges of revisions to
-      replicate (see
-      <xref linkend="svn.branchmerge.advanced.advancedsyntax"/> later
-      in this chapter), and take special care to keep track of what's
-      already been merged and what hasn't.  For this reason,
-      we <emphasis>strongly</emphasis> recommend that you make sure your
-      client and server are at least at version 1.5.</para>
+    <title>Fusions : pratiques de base</title>
+
+    <para>Désormais, Sally et vous travaillez sur des branches
+      parallèles du projet : vous travaillez sur une branche
+      privée et Sally travaille sur le <firstterm>tronc</firstterm>,
+      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
+      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 travail soit terminé.</para>
+
+    <para>Bref, la bonne nouvelle est que Sally et vous n'empiétez
+      pas l'un sur l'autre. La mauvaise nouvelle est qu'il est très
+      facile de <emphasis>dériver</emphasis> chacun de son côté.
+      Rappelez-vous qu'un des problèmes lié à la stratégie
+      d'<quote>isolement</quote> est que lorsque vous en aurez fini
+      avec votre branche, il risque d'être quasi impossible de
+      refusionner vos modifications dans le tronc sans avoir à faire
+      face à un grand nombre de conflits.</para>
+
+    <para>À la place, Sally et vous pourriez continuer de partager
+      vos changements au fur et à mesure de votre travail. C'est à
+      vous de décider quelles modifications valent la peine d'être
+      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
+      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
+      s'effectue à l'aide de plusieurs exécutions de la commande
+      <command>svn merge</command>.</para>
+
+    <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
+      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
+      révisions à répliquer
+      (voir <xref linkend="svn.branchmerge.advanced.advancedsyntax"/>
+       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
+       en version 1.5.</para>

    <!-- =============================================================== -->
      <sect2 id="svn.branchmerge.changesets">
-      <title>Changesets</title>
-
-      <para>Before we proceed further, we should warn you that there's
-        going to be a lot of discussion of <quote>changes</quote> in
-        the pages ahead.  A lot of people experienced with version
-        control systems use the terms <quote>change</quote>
-        and <quote>changeset</quote> interchangeably, and we should
-        clarify what Subversion understands as
-        a <firstterm>changeset</firstterm>.</para>
-
-      <para>Everyone seems to have a slightly different definition
-        of changeset, or at least a different
-        expectation of what it means for a version control system to
-        have one.  For our purposes, let's say that a changeset is just
-        a collection of changes with a unique name.  The changes might
-        include textual edits to file contents, modifications to tree
-        structure, or tweaks to metadata.  In more common speak, a
-        changeset is just a patch with a name you can refer to.</para>
-
-      <para>In Subversion, a global revision number N names a tree in
-        the repository: it's the way the repository looked after the
-        Nth commit.  It's also the name of an implicit changeset: if
-        you compare tree N with tree N−1, you can derive the exact
-        patch that was committed.  For this reason, it's easy to think
-        of revision N as not just a tree, but a changeset as well.  If
-        you use an issue tracker to manage bugs, you can use the
-        revision numbers to refer to particular patches that fix
-        bugs—for example,
-        <quote>this issue was fixed by r9238.</quote> Somebody
-        can then run <userinput>svn log -r 9238</userinput> to read about
-        the exact changeset that fixed the bug, and run
-        <userinput>svn diff -c 9238</userinput> to see the patch itself.
-        And (as you'll see shortly)
-        Subversion's <command>svn merge</command> command is able to use
-        revision numbers.  You can merge specific changesets from one
-        branch to another by naming them in the merge
-        arguments: passing <userinput>-c 9238</userinput> to <command>svn  
merge</command> would merge
-        changeset r9238 into your working copy.</para>
-
-      </sect2>
+      <title>Ensembles de modifications</title>
+
+      <para>Avant que nous n'allions plus loin, nous devons vous
+        avertir que les pages suivantes contiendront 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
+        <quote>modifications</quote> et le terme <quote>ensemble de
+        modifications</quote> de façon interchangeable et nous allons
+        donc clarifier ce que Subversion entend par
+        <firstterm>ensemble de modifications</firstterm>.</para>
+
+      <para>Tout le monde 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
+        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
+        fichiers, des modifications de l'arborescence ou des
+        ajustements portant sur les méta-données. En langage plus
+        courant, un ensemble de modifications n'est qu'un correctif
+        avec un nom auquel vous pouvez vous référer.</para>
+
+      <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
+        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
+        raison, il est facile de se représenter une révision N non
+        seulement comme une arborescence, mais aussi comme un ensemble
+        de modifications. Si vous utilisez un système de gestion des
+        incidents pour gérer vos bogues, vous pouvez utiliser les
+        numéros de révision pour vous référer à des correctifs
+        particuliers permettant de résoudre des bogues — par
+        exemple, <quote>cet incident a été corrigé par r9238</quote>.
+        Quelqu'un peut alors lancer
+        <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),
+        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
+        branche à une autre en les nommant dans les paramètres de
+        la fusion : donner comme argument
+        <userinput>-c 9238</userinput> à <command>svn merge</command>
+        fusionne la liste de modifications r9238 avec
+        votre copie de travail.</para>
+
+    </sect2>

    <!-- =============================================================== -->
      <sect2 id="svn.branchemerge.basicmerging.stayinsync">
-      <title>Keeping a Branch in Sync</title>
-
-      <para>Continuing with our running example, let's suppose that a
-        week has passed since you started working on your private
-        branch.  Your new feature isn't finished yet, but at the same
-        time you know that other people on your team have continued to
-        make important changes in the
-        project's <filename>/trunk</filename>.  It's in your best
-        interest to replicate those changes to your own branch, just
-        to make sure they mesh well with your changes.  In fact, this
-        is a best practice: frequently keeping your branch in sync
-        with the main development line helps
-        prevent <quote>surprise</quote> conflicts when it comes time
-        for you to fold your changes back into the trunk.</para>
-
-      <para>Subversion is aware of the history of your branch and
-        knows when it divided away from the trunk.  To replicate the
-        latest, greatest trunk changes to your branch, first make sure
-        your working copy of the branch
-        is <quote>clean</quote>—that it has no local
-        modifications reported by <command>svn status</command>.  Then
-        simply run:</para>
+      <title>Comment garder une branche synchronisée</title>
+
+      <para>Continuons avec notre exemple précédent et imaginons
+        qu'une semaine a passé depuis que vous avez commencé à
+        travailler sur votre branche privée. Votre nouvelle
+        fonctionnalité n'est pas encore terminée, mais en même temps
+        vous savez que d'autres personnes de votre équipe ont continué
+        à 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
+        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
+        <quote>surprise</quote> le jour où vous reversez vos
+        modifications dans le tronc.</para>
+
***The diff for this file has been truncated for email.***


More information about the svnbook-dev mailing list