SVNBOOK Chap4 Branching and Merging Using Branches
De Framalang Wiki.
Cette page fait partie du projet Version control with subversion.
| Pseudo | Code | Rôle | Statut |
|---|---|---|---|
| Sub Versif | SVF | Traduction | Terminé |
| Hotshot92 | Relecture | Fait | |
| Validation |
--Sub Versif 24 décembre 2008 à 15:19 (CET):
Source: http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.branchmerge.using
Sommaire |
Titre
Using Branches
Utiliser les branches
Paragraphe 1
At this point, you should understand how each commit creates an entirely new filesystem tree (called a "revision") in the repository. If you don't, go back and read about revisions in the section called "Revisions".
Rendu à ce chapitre, vous devriez avoir compris que chaque propagation crée une arborescence de fichiers entièrement nouvelle (appelée "révision") dans le dépôt. Si ce n'est pas le cas, retournez vous informer sur les révisions dans la section appelée "Révisions".
Paragraphe 2
For this chapter, we'll go back to the same example from Chapter 1, Fundamental Concepts. Remember that you and your collaborator, Sally, are sharing a repository that contains two projects, paint and calc. Notice that in Figure 4.2, "Starting repository layout", however, each project directory now contains subdirectories named trunk and branches. The reason for this will soon become clear.
Pour ce chapitre, nous reprendrons le même exemple qu'au Chapitre 1, Notions Fondamentales. Souvenez-vous que votre collaboratrice, Sally, et vous partagez un dépôt qui contient deux projets, paint et calc. Notez cependant que dans la Figure 4.2, "Structure initiale du dépôt", chaque dossier de projet contient désormais des sous-dossiers nommés trunk et branches. Les raisons de cette arborescence apparaîtront bientôt clairement.
Paragraphe 3
As before, assume that Sally and you both have working copies of the "calc" project. Specifically, you each have a working copy of /calc/trunk. All the files for the project are in this subdirectory rather than in /calc itself, because your team has decided that /calc/trunk is where the "main line" of development is going to take place.
Comme avant, supposons que Sally et vous avez tous deux une copie de travail du projet "calc". Plus spécifiquement, vous avez chacun une copie de travail de /calc/trunk. Tous les fichiers du projet sont dans ce sous-dossier plutôt que dans /calc lui-même, parce que votre équipe a décidé que la "ligne principale" de développement du projet allait se situer dans /calc/trunk.
Paragraphe 4
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 /calc/trunk) 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).
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 /calc/trunk) soit toujours utilisable. Si vous commencez à livrer des changements petit à petit, vous allez sûrement casser des choses pour Sally (ainsi que pour d'autres membres de l'équipe).
Paragraphe 5
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 /calc/trunk 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 "best practice" 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 svn update after weeks of isolation.
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 /calc/trunk 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 "bonnes pratiques" 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 qui seront difficiles à incorporer dans votre copie de travail - notamment si vous lancez svn update après des semaines d'isolation.
Paragraphe 6
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.
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 livrer fréquemment votre travail un peu boiteux sans interférer avec les autres, vous pourrez toutefois partager une sélection d'informations avec vos collaborateurs. Vous verrez comment tout cela fonctionne exactement au fur et à mesure de ce chapitre.
