SVNBOOK Chap4 Branching and Merging Branch Maintenance Data Lifetimes
De Framalang Wiki.
Cette page fait partie du projet Version control with subversion.
| Pseudo | Code | Rôle | Statut |
|---|---|---|---|
| Sub Versif | SVF | Traduction | Fait |
| Hotshot92 | Relecture | Fait | |
| Validation |
Sommaire |
Titre
Data Lifetimes
Durée de vie des données
Paragraphe 1
Another nice feature of Subversion's model is that branches and tags can have finite lifetimes, just like any other versioned item. For example, suppose you eventually finish all your work on your personal branch of the calc project. After merging all of your changes back into /calc/trunk, there's no need for your private branch directory to stick around anymore:
Une autre fonctionnalité intéressante liée aux principes de fonctionnement de Subversion est que les branches et les étiquettes peuvent avoir des durées de vie limitées, tout comme n'importe quel autre élément suivi en versions. Par exemple, supposons que vous avez enfin terminé votre travail sur votre branche personnelle du projet calc. Après avoir fusionné toutes vos modifications vers /calc/trunk, le répertoire contenant votre branche privée n'a plus de raison d'exister :
Paragraphe 2
$ svn delete http://svn.example.com/repos/calc/branches/my-calc-branch \
-m "Removing obsolete branch of calc project."
Committed revision 375.
$ svn delete http://svn.exemple.com/depot/calc/branches/ma-branche-calc \
-m "Suppression d'une branche obsolète du projet calc."
Révision 375 propagée.
Paragraphe 3
And now your branch is gone. Of course, it's not really gone: the directory is simply missing from the HEAD revision, no longer distracting anyone. If you use svn checkout, svn switch, or svn list to examine an earlier revision, you'll still be able to see your old branch.
Et maintenant votre branche a disparu. Bien sûr, elle n'a pas vraiment disparu : le répertoire est juste absent de la révision HEAD, ne gênant plus personne. Si vous utilisez svn checkout, svn switch ou svn list pour examiner une révision plus ancienne, vous pourrez toujours voir votre vieille branche.
Paragraphe 4
If browsing your deleted directory isn't enough, you can always bring it back. Resurrecting data is very easy in Subversion. If there's a deleted directory (or file) that you'd like to bring back into HEAD, simply use svn copy to copy it from the old revision:
Si la navigation dans votre répertoire supprimé ne vous suffit pas, vous pouvez toujours le récupérer. Ressusciter des données est très facile dans Subversion. S'il y a un dossier (ou un fichier) supprimé que vous aimeriez faire réapparaître dans HEAD, utilisez simplement svn copy pour le copier depuis l'ancienne révision.
Paragraphe 5
$ svn copy http://svn.example.com/repos/calc/branches/my-calc-branch@374 \ http://svn.example.com/repos/calc/branches/my-calc-branch \ -m "Restore my-calc-branch." Committed revision 376.
$ svn copy http://svn.exemple.com/depot/calc/branches/ma-branche-calc@374 \ http://svn.exemple.com/depot/calc/branches/ma-branche-calc \ -m "Restaure ma-branche-calc." Committed revision 376.
Paragraphe 6
In our example, your personal branch had a relatively short lifetime: you may have created it to fix a bug or implement a new feature. When your task is done, so is the branch. In software development, though, it's also common to have two "main" branches running side by side for very long periods. For example, suppose it's time to release a stable version of the calc project to the public, and you know it's going to take a couple of months to shake bugs out of the software. You don't want people to add new features to the project, but you don't want to tell all developers to stop programming either. So instead, you create a "stable" branch of the software that won't change much:
Dans notre exemple, votre branche personnelle a eu une durée de vie relativement limitée : vous l'aviez peut-être créée pour corriger un bogue ou implémenter une nouvelle fonctionnalité. Quand votre tâche est finie, il en va de même pour la branche. Cependant, en développement logiciel, il est aussi courant d'avoir deux branches "principales" côte à côte pour de très longues périodes. Par exemple, supposons que le moment est venu de publier une version stable du projet calc pour le public, et vous savez que ça prendra quelques mois pour éliminer les bogues du logiciel. Vous ne voulez pas que les gens ajoutent de nouvelles fonctionnalités au projet, mais vous ne voulez pas non plus dire à tous les développeurs d'arrêter de programmer. Donc à la place, vous créez une branche "stable" du logiciel qui ne changera pas beaucoup :
Paragraphe 7
$ svn copy http://svn.example.com/repos/calc/trunk \ http://svn.example.com/repos/calc/branches/stable-1.0 \ -m "Creating stable branch of calc project." Committed revision 377.
$ svn copy http://svn.exemple.com/depot/calc/tronc \ http://svn.exemple.com/depot/calc/branches/stable-1.0 \ -m "Création de la branche stable du projet calc." Committed revision 377.
Paragraphe 8
And now developers are free to continue adding cutting-edge (or experimental) features to /calc/trunk, and you can declare a project policy that only bug fixes are to be committed to /calc/branches/stable-1.0. That is, as people continue to work on the trunk, a human selectively ports bug fixes over to the stable branch. Even after the stable branch has shipped, you'll probably continue to maintain the branch for a long time - that is, as long as you continue to support that release for customers. We'll discuss this more in the next section.
Dès lors les développeurs sont libres de continuer à ajouter des fonctionnalités de pointe (ou expérimentales) à /calc/trunk, et vous pouvez poser comme convention pour le projet que seules les corrections de bogues seront livrées à /calc/branches/stable-1.0. C'est-à-dire qu'au fur et à mesure que les gens continueront de travailler sur le tronc, quelqu'un reportera de façon sélective les corrections de bogues vers la branche stable. Même après que la branche stable aura été publiée, vous continuerez probablement à maintenir la branche pendant longtemps - c'est-à-dire pour aussi longtemps que vous continuerez à fournir aux clients un support sur cette version. Nous évoquerons ceci plus en détails dans le prochain paragraphe.
