This text is a work in progress—highly subject to change—and may not accurately describe any released version of the Apache™ Subversion® software. Bookmarking or otherwise referring others to this page is probably not such a smart idea. Please visit http://www.svnbook.com/ for stable versions of this book.
À ce stade, vous vous êtes certainement rendu compte que Subversion est extrêmement flexible. Parce qu'il implémente les branches et les étiquettes avec le même mécanisme sous-jacent (des copies de répertoires) et parce que les branches et les étiquettes apparaissent au sein de l'espace standard du système de fichiers, beaucoup de gens sont intimidés par Subversion. Il est presque trop flexible. Dans ce paragraphe, nous proposons des suggestions pour organiser et gérer vos données au fil du temps.
Il existe des méthodes standard recommandées pour
structurer un dépôt. La plupart des gens créent un répertoire
trunk
pour la « ligne de développement
principale » (le tronc), un répertoire
branches
qui contiendra les copies de
branches et un répertoire tags
qui
contiendra les copies étiquetées. Si un dépôt ne comprend qu'un
seul projet, les gens créent souvent les dossiers suivants
à la racine :
/
trunk/
branches/
tags/
Si un dépôt contient plusieurs projets, les administrateurs indexent généralement la structure du dépôt par projet (voir la section intitulée « Stratégies d'organisation d'un dépôt » pour en savoir plus sur les « dossiers racine d'un projet »), mais en voici directement un exemple :
/
paint/
trunk/
branches/
tags/
calc/
trunk/
branches/
tags/
Bien sûr, vous restez libre d'ignorer ces agencements courants. Vous pouvez créer toutes sortes de variantes, selon ce qui fonctionne le mieux pour vous ou pour votre équipe. Souvenez-vous que quel que soit votre choix, ce n'est pas un engagement définitif. Vous pouvez réorganiser votre dépôt à tout moment. Parce que les branches et les étiquettes sont des répertoires ordinaires, la commande svn move peut les déplacer ou les renommer selon vos désirs. Passer d'un agencement à un autre consiste juste à lancer une série d'opérations de déplacement côté serveur ; si vous n'aimez pas la façon dont les choses sont organisées dans le dépôt, modifiez juste leur agencement.
Souvenez-vous néanmoins que bien qu'il soit facile de déplacer des dossiers, vous devez aussi rester attentif à vos utilisateurs. Vos modifications sont susceptibles de déboussoler ceux qui ont des copies de travail existantes. Si un utilisateur a une copie de travail d'un répertoire donné du dépôt, votre opération svn move risque de supprimer ce chemin de la révision la plus récente. Lorsque par la suite l'utilisateur lancera svn update, il se verra annoncer que sa copie de travail pointe vers un chemin qui n'existe plus et sera contraint d'effectuer un svn switch vers le nouvel emplacement.
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 :
$ svn delete http://svn.exemple.com/depot/calc/branches/ma-branche-calc \ -m "Suppression d'une branche obsolète du projet calc." Révision 474 propagée.
Astuce | |
---|---|
Rappelez-vous que, comme indiqué dans la section précédente, si votre copie de travail pointe vers un chemin du dépôt qui a été supprimé, une erreur apparaitra à la prochaine mise à jour : $ svn up Actualise '.' : svn: E160005: chemin '/calc/branches/my-calc-branch' n'existe pas Vous n'avez qu'à basculer votre copie de travail vers un chemin qui existe encore : $ svn sw ^/calc/trunk D src/tout.c U src/reel.c A src/entier.c U . Actualisé à la révision 474. |
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.
Si la navigation dans votre dossier 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 :
$ svn copy ^/calc/branches/ma-branche-calc@473 \ ^/calc/branches/ma-branche-calc \ -m "Restaure ma-branche-calc." Révision 475 propagée.
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. Vous savez
qu'il faudra 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 :
$ svn copy ^/calc/trunk ^/calc/branches/stable-1.0 \ -m "Création de la branche stable du projet calc." Révision 476 propagée.
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 propagées dans
/calc/branches/stable-1.0
. C'est-à-dire
qu'au fur et à mesure que les gens continuent de travailler
sur le tronc, quelqu'un reporte 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 évoquons ceci plus en détails dans le
prochain paragraphe.