II. Systèmes de gestion de version et d’archivage, suite
Article mis en ligne le 2 février 2007
dernière modification le 10 janvier 2022

Cet article est la suite d’un autre sur le même sujet

 Cahier des charges pour un nouveau monde

Tout auteur de programmes ou de textes sur ordinateur est confronté à la nécessité de maintenir l’historique des états successifs de ses documents et de leur cohérence. Dans le cas d’un travail en équipe, il faut en outre permettre aux membres de l’équipe de travailler chacun de son côté pour ensuite réunir leurs contributions. L’article qui précède celui-ci décrivait certaines solutions proposées, pour en arriver à CVS, d’usage universel aujourd’hui, mais non dépourvu de limites et d’insuffisances.

Bref, pour les raisons indiquées ici, je souhaitais trouver un remplaçant à CVS. Il me fallait un système de gestion de versions (VCS) qui, par rapport à CVS, m’apporte les améliorations suivantes :

 impérativement, m’affranchir de l’unicité de l’archive centrale ;
 de façon souhaitable, me permettre de renommer et déplacer fichiers et répertoires et que le système reste cohérent.

Incidemment, pour vous faire une idée d’ensemble de cette question des VCS, vous pouvez lire un article de S. Bortzmeyer qui propose une analyse des tendances actuelles en matière de VCS et consulter le site de référence sur le sujet.

J’ai essayé Subversion (SVN), qui est fondamentalement une réécriture de CVS débarassée des vestiges de RCS, avec un traitement meilleur pour les renommages et déplacements de fichiers et de répertoires, mais toujours la contrainte de l’archive centralisée. Je reparlerai de SVN plus loin, parce que mon éditeur l’utilise, ce qui m’a amené à archiver les textes de mon nouveau livre avec ce système que je commence donc à connaître. SVN est clairement très supérieur à CVS, notamment pour la vitesse, mais ne répond pas à toutes mes attentes.

Ensuite j’ai installé GNU Arch, également connu sous le nom de TLA (pour Tom Lord’s Archive) ; sur le papier cela répond parfaitement au cahier des charges, mais la réalisation est calamiteuse : tous mes répertoires soumis au joug de TLA ont été inondés de fichiers aux noms à coucher dehors, et quelques « plantages » brutaux autant que radicaux m’ont convaincu que pour la sécurité de mes données ce n’était pas la solution.

Le candidat suivant a été Darcs, déjà plus intéressant et utilisable ; je crois que j’aurais pu adopter Darcs, mais finalement je n’ai pas été convaincu : pour moi un tel logiciel doit donner une confiance très forte, parce que l’idée même qu’une fausse manoeuvre due à une imprécision de la documentation puisse détruire mes données est insupportable, or la documentation de Darcs manque de clarté, et la commande du système est complexe.

Mon attention a bien sûr été attirée par Git, le VCS adopté par Linus Torvalds pour la gestion des sources du noyau Linux, ce qui est quand même une bonne référence, mais encore une fois la chose m’a semblé d’une obscurité nuisible à la sécurité de mes données.

Voilà pourquoi, sur les conseils de Manuel Serrano, je me suis orienté vers Mercurial, un VCS compatible avec Git, mais dont l’usage m’a inspiré confiance.

 Mercurial

La logique de Mercurial, en deux lignes, c’est celle de RCS, plus la gestion des arborescences, plus le réseau. Bref, tout ce qu’il me fallait, plus les branches, avec un mode de fonctionnement suffisamment simple pour que l’ascétisme de la documentation ne soit pas un obstacle dirimant à l’usage.

Avec Mercurial, chaque répertoire qui héberge une racine de l’arborescence des fichiers d’un projet en héberge aussi une archive. Ensuite, pour avoir des copies, locales ou par le réseau, il suffit de synchroniser ces différentes archives, un peu comme avec rsync. Alors que CVS obéissait au modèle client-serveur, Mercurial est plutôt dans une logique peer-to-peer, ce qui va dans le sens de l’histoire récente de l’Internet.

Pour créer une archive dans un répertoire : hg init.

Pour y introduire les fichiers du projet (y compris les sous-répertoires) :
hg addremove.

Les autres commandes sont similaires à celles de CVS, préfixées par hg (évidemment...) :

Pour archiver les dernières modifications locales (commit) :
hg ci (il faut impérativement écrire quelque chose dans
le fichier de log pour que le commit soit effectué).

Pour mettre à jour les fichiers locaux en cohérence avec l’archive :
hg update.

Pour synchroniser une archive dans un autre répertoire :

hg push ~Ma-clef-USB/Travaux/Mes-Articles



La même chose sur un site distant :

hg push --ssh ssh ssh://pmartin@un-ordi.la-bas.net/~/Travaux/Mes-Articles



C’est possible aussi en sens inverse :

hg pull --ssh ssh ssh://fdupont@autre.ailleurs.net/~/Travaux/Mes-Articles



Pour exhiber les différences entre deux versions d’un fichier nommé par exemple list-transformer.scm :

hg log list-transformer.scm

répond :

changeset:   1:b300cfb1e065
tag:         tip
user:        bloch@zenobie.site
date:        Fri Feb 02 17:13:31 2007 +0100
summary:     20070202-2

changeset:   0:edcc2e78a6d9
user:        bloch@zenobie.site
date:        Fri Feb 02 17:11:59 2007 +0100
summary:     20070202-1



Il y a deux changesets numérotés 0 et 1, ce qui permet de demander :

hg diff -r 1 -r 0 --ignore-blank-lines list-transformer.scm



qui répond :

 Subversion

Au premier abord, Subversion (nom de commande svn) est un clone de CVS, plus agréable à utiliser parce qu’il fonctionne mieux et qu’il est plus rapide, ce qui serait déjà de bonnes raisons de l’adopter. En effet la syntaxe et la logique des commandes sont celles de CVS, l’habitué de ce logiciel ne sera pas pris au dépourvu, ce sera toujours svn (checkout|co), svn (commit|ci), svn update pour les opérations courantes.

Au second abord, Subversion comble une lacune grave de CVS : il permet de copier, renommer et déplacer des fichiers et même des répertoires :

Ainsi Subversion conservera la trace de l’origine et de l’historique de chacun de ces fichiers. De plus, ne seront stockées que les différences entre les différents avatars.

Pour les répertoires c’est exactement la même chose : svn mkdir, svn move...

Pour les amateurs d’Eclipse il y a un plugin Subversion : subclipse :-)

La manière la plus commode d’utiliser Subversion, si vous pouvez avoir le contrôle d’un serveur Web, c’est en http :

Mais sinon ça marche avec ssh :

Noter la généralisation de l’usage des notations avec des URI. Vous trouverez sur ce site un article qui décrit l’installation complète d’un serveur Subversion.

Siganlons le projet Trac qui englobe Subversion dans un environnement plus complet, avec Wiki incorporé et système de gestion d’événements.

 Version de livraison avec Subversion

Pour la délicate question des versions de livraison, déjà évoquée dans l’article précédent, Subversion, comme CVS, s’en remet aux tags (marques, étiquettes), mais là elles sont mieux réalisées, ou au moins mieux présentées.

Le dépôt lié à un projet, nous l’avons vu, est constitué de multiples fichiers, dont chacun suit une évolution qui lui est propre. Ainsi à un instant donné chaque fichier aura un numéro de version différent. Livrer une version du produit du projet (programme ou texte) consiste à construire cette version à partir des multiples fichiers à un instant donné, c’est-à-dire à marquer chacun de ces fichiers dans l’état qui est le sien à cet instant, afin de pouvoir ultérieurement retrouver cet état, si l’on doit reconstituer cette version, soit parce que les versions ultérieures auront été moins bonnes, soit pour dépanner un client qui utilise encore cette version, ou pour toute autre raison.

Subversion utilise les marques pour étiqueter ainsi une « tranche de vie » du projet. Concrètement, le répertoire qui abrite le dépôt du projet aura un sous-répertoire tags (ce nom est purement conventionnel, mais les auteurs de Subversion conseillent de s’y tenir), et dans ce sous-répertoire chaque version étiquetée aura son propre répertoire. Chaque répertoire ne comprendra pas la copie intégrale des fichiers, mais plutôt la copie au sens de Subversion, c’est-à-dire uniquement les différences (calculées par diff) avec la version de référence.

On voit ainsi que la copie est l’opération fondamentale de Subversion.

Pour de plus amples détails on pourra se reporter au livre de Mike Manson (adapté par Isabelle Hurbain) Subversion - Pratique du développement collaboratif avec SVN, aux Éditions Eyrolles.