Site WWW de Laurent Bloch
Slogan du site

ISSN 2271-3905
Cliquez ici si vous voulez visiter mon autre site, orienté vers des sujets moins techniques.

Pour recevoir (au plus une fois par semaine) les nouveautés de ce site, indiquez ici votre adresse électronique :

II. Systèmes de gestion de version et d’archivage, suite
Article mis en ligne le 2 février 2007
dernière modification le 9 mars 2014
logo imprimer

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.


Forum
Répondre à cet article


pucePlan du site puceContact puceMentions légales puceEspace rédacteurs puce

RSS

2004-2017 © Site WWW de Laurent Bloch - Tous droits réservés
Site réalisé sous SPIP
avec le squelette ESCAL-V3
Version : 3.87.15