Vous n’apprendrez pas avec cet article comment polluer les forêts au mercure ; désolé.
La gestion de version est une pratique essentielle pour qui travaille sur des projets au long court. Pour faire rapide, cette activité consiste à maintenir à chaque étape l’information sur l’état du projet. Cette gestion permet ultérieurement de remettre le projet dans un état donné, et de savoir précisément quelles sont les modifications apportées entre deux étapes.
Cette gestion peut être faite à la main, en archivant le projet au fur et à mesure de son évolution, ou de manière assisté par un outil informatique. Du point de vu outils informatique dédié à la gestion de version, il y a actuellement un grand choix. Les logiciels se différencient tant par leur philosophie d’utilisation que par leurs fonctionnalités.
Les méthodes utilisées dans mon entreprise ne sont pas unifiées, sont très manuelles, et nettement obsolètes. La gestion y est donc bien faite, mais avec un surcout de travail important. Pour mon travail personnel, j’utilise en parallèle mon outil, ce qui me permet d’être très réactif lorsque l’on me demande de remonter dans le temps ou de faire un rapport précis sur une évolution. J’utilise au quotidien Mercurial ; les raisons non technique du choix de ce logiciel parmi d’autres sont notamment sa simplicité et sa capacité à travailler naturellement sur des projets partagés entre des machines Windows et Linux.
Mercurial ne remplissait pas un de mes besoins, la capacité de lier des projets entre eux. Il s’agit simplement de pouvoir lier plusieurs projets organisés à différents endroits sur des ordinateurs, et de regrouper certains stades de projets entre eux. Je travaille dans le monde ferroviaire, et les systèmes impliquent chacun de nombreux composants. Un système complet de contrôle de trains en version 2.5 peut correspondre à un sous-système à bord des trains en version 4.7 et un sous-système débarqué en version 1.8. Intégrer cette fonctionnalité dans la gestion des version est très puissant, Mercurial ne le gère pas en natif.
Une extension, Forest, apporte à Mercurial la gestion de structure arborescente de projets. Un projet géré par Mercurial peut contenir des répertoires qui sont eux même des projets gérés par Mercurial. Les fonctionnalité de Forest, relativement limitées, sont essentiellement l’apport de la récursivité d’une opération Mercurial sur les sous-projets. Il est ensuite très facile de se servir de Forest pour étendre ses actions à l’aide de tout petits scripts. Forest ne permet pas naturellement de fabriquer une dépendance entre projet qui ne soit pas intimement liée à la structure des répertoires. Un projet est un sous-projet d’un projet racine s’il se trouve dans le répertoire du projet racine. Les liens symboliques permettent de se débarasser rapidement de cette contrainte. Alors que le sous-projet se trouve physiquement à un bout du disque, un autre sous-projet à l’autre bout du disque, un meta-projet contient des liens symbolique (Posix) vers ses répertoires. Ce meta-projet est alors le projet racine du système, et la gestion transparente des liens symboliques par Mercurial/Forest permet d’avoir des sous-projets disséminés sur les ordinateurs.
La fonctionnalité la plus intéressante de Forest est l’instantané d’une forêt (Forest Snapshot). Cette commande de Forest permet de déterminer pour un projet les versions des sous-projets à une date donnée. Il est ensuite possible à partir de cet instantané de re-trouver l’état cohérent des sous-projets.
On ainsi finalement tout ce qui était souhaité, à savoir un projet liés à des sous-projets répartis dans des répertoires de travails indépendants, et la possibilité de marqué un état de version cohérent pour les projets et sous-projets à une livraison donnée.
linux logiciel libre mercurial projet python vcs

