[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