Subversion est un outil de gestion de version que j’adore. Il est simple à utiliser, robuste, multi-plateforme mais là où il est encore plus fort c’est que régulièrement je me dis que j’aimerai bien qu’il intègre telle ou telle fonctionnalité et généralement c’est déjà le cas sans que je le sache.
Je vais vous parler de la dernière fonctionnalité géniale qu’il intègre : la possibilité d’aggréger dans un même copie de travail des répertoires provenant de différents dépôts.
Prenons un exemple concrêt pour mieux comprendre. Supposons que vous utilisez un framework (qu’il soit maison ou pas tant qu’il est stocké dans un dépôt Subversion) et vous souhaitez développer une application basée sur ce framework. Voici l’arborescence de l’application en question :
--racine |--framework | |--(fichiers du framework) |--application | |--modeles | |--vues | |--controleurs |--www |--index.php
La méthode classique est de faire un export du framework et de l’intégrer dans l’application. Les fichiers exportés du framework feront partie du code de l’application et seront à ce titre stockésdans le dépôt. Il y a 2 gros inconvénients à cette méthode :
- Le code du framework est stocké de manière redondante.
- La mise à jour du code du framework utilisé dans l’application est compliquée car il faut faire les manipulations nécessaires sur chacune des applications l »utilisant.
Heureusement, Subversion propose un moyen de régler ces problèmes. Au lieu de faire un export du répertoire framework, on ajoute la propriété svn:externals au répertoire parent, en l’occurence « racine », et on lui donne la valeur suivante :
framework http://svn.exemple.com/framework
Cette propriété indique à Subversion de créer un répertoire « framework » dont la source est située à l’adresse « http://svn.exemple.com/framework ». L’avantage de cette méthode est qu’un simple update mettra à jour le code du framework sans autre intervention de votre part. De même, une modification dans ce répertoire sera répercutée dans le code du framework et non celui de l’application.
Parfois, la maintenance de l’application reste figée pendant un moment tandis que le framework évolue. Il arrive donc que celui-ci devienne incompatible avec l’application. Pour différentes raisons (notamment économiques), il est parfois impossible de rendre compatible l’application avec la dernière version du framework. Dans ce cas, il suffit d’indiquer le numéro de la révision en plus du chemin vers le dépôt. Ainsi, Subversion restera à cette révision même si le développement du framework se poursuit. Voici l’exemple précédent modifié pour rester figé à la révision 14 :
framework -r14 http://svn.exemple.com/framework
J’ai découvert les svn:externals y’a quelques mois et depuis plus un seul projet sur lequel je travaille n’en dispose pas !
NiKo> En fait, j’ai découvert cette possibilité courant août mais ce billet est resté à l’état d’ébauche jusqu’à aujourd’hui. :/
Ouhaou,
en effet, c’est très très intéressant !
J’ai pas tout compris… C’est où la première partie ? Celle pour débutants
sitges pulsations> Dans ce cas, je te conseille l’excellent livre électronique situé à l’adresse suivante :
svnbook.red-bean.com/
Merci JMF !