Dur Comme Faire

Le 9 juillet 2003 je faisais partie des quelques dizaines de milliers de veinards qui ont assisté au concert des Rolling Stones au Stade de France. J'avais réussi à rentrer avec mon appareil photo numérique. J'ai donc mitraillé une partie de la soirée. Bien-sûr j'étais loin et mon appareil n'était pas une merveille mais ça fait des souvenirs. Là, normalement c'est le moment où vous vous demandez pourquoi je vous raconte cela, n'est-ce pas ?

Tout simplement parce qu'en rentrant chez moi j'ai eu la déception de constater de la carte mémoire de mon appareil était illisible. J'ai essayé des tas de lecteurs mais sans résultat. Par réflexe, j'ai mis cette carte de côté, au cas où.

Bien m'en a pris car plus de 3 ans après j'ai finalement pu récupérer ces fameuses photos grâce au logiciel PhotoRec.

L'utilisation en ligne de commande n'est pas forcément très ergonomique mais le résultat est là. J'ai récupéré près de 150 photos sur 3 cartes qu'aucun lecteur ne voulait lire.

Voici un aperçu des caractéristiques de ce logiciel :

• Disponible sur un large éventail de plate-formes (DOS/Win9x, Windows NT 4/2000/XP/2003, Linux, FreeBSD, NetBSD, OpenBSD, Sun Solaris, Mac OS X)
• Support des systèmes de fichiers courants (FAT, NTFS, EXT2/EXT3, HFS+ et partiellement ReiserFS)
• Reconnaissance de 80 formats de fichier

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