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 :

Les outils du travail avec l’ordinateur :
I. Systèmes de gestion de version et d’archivage
Mercurial mieux que CVS
Article mis en ligne le 31 mai 2006
dernière modification le 18 août 2017

"http://www.w3.org/TR/REC-html40/loose.dtd">

Changer d'environnement de travail

Changer d'environnement de travail

Laurent Bloch


Un précédent article vous avait fait part de mes tribulations pour
changer de fournisseur d’accès à l’Internet, aujourd’hui je vous
raconterai celles qui résultent de mon changement d’environnement de
travail informatique. Ce n’est pas pur narcissisme de ma part, mais
parce que, ce me semble, ces questions sont importantes et que les
résoudre prend du temps, alors qu’elles n’ont guère de prestige
intellectuel, et que souvent elles sont donc mal résolues. Combien de
messages électroniques recevons-nous qui attestent que leur émetteur,
en 2006, ne sait pas se servir de la messagerie ? Les systèmes
d’exploitation modernes (Unix/Linux/MacOS X, je ne parle pas de ceux
qui sont destinés aux bavardages et aux jeux des adolescents) offrent
de nombreux moyens d’automatiser les tâches courantes, mais qui sait
les utiliser ?



Je suis au milieu du gué de la transition pour deux outils capitaux :
le logiciel que j’utilise pour archiver les versions successives de
mon travail, et celui qui me sert à lire et à écrire mon courrier
électronique. Pour le premier, je change parce que le précédent (CVS,
pour Concurrent Versions System) ne me convenait pas, pour le
second, parce que Pine est en train de disparaître, malgré que
j’en aie, parce qu’il me convenait parfaitement. La transition de CVS
à Mercurial se passe plutôt très bien, celle de Pine à
Gnus est un véritable traumatisme, d’ailleurs je renonce finalement à Gnus et, sans joie, me résigne finalement à un cliquodrome, Claws-Mail. Entre parenthèses, si vous
m’écrivez et ne recevez pas de réponse, ce sera peut-être parce que
vous utilisez mon ancienne adresse chez Noos, qui a expiré à la fin du
mois de juin 2006, et pour laquelle évidemment aucun service de changement
d’adresse n’est fourni, mais ce sera peut-être aussi parce que mes
tâtonnements avec Gnus auront éliminé votre message, trouvez
ici mes excuses anticipées et ayez l’amabilité de renvoyer votre
message à ma nouvelle adresse, lb@laurentbloch.org.
Si vous avez l’impression que je ne réponds pas à vos messages, il s’agit peut-être d’incidents techniques, insistez.



Gestion de versions et archivage



Tous ceux qui écrivent des textes ou des programmes seront de mon avis, rien n'est plus déprimant que l'idée de perdre une partie de son travail à cause d'un incident informatique. Eh bien il y a une chose plus déprimante encore : retrouver dans un texte publié une version périmée d'un passage qui s'est substituée à la version corrigée à la faveur d'une manipulation quelconque.

Le remède que j'ai choisi depuis quelques années pour prévenir ce genre de catastrophes s'appelle logiciel de gestion de versions, ou Version Control
System
(VCS). Les logiciels de ce type gardent dans un dossier spécial (les informaticiens utilisent plutôt le terme répertoire, plus exact, mais la métaphore du dossier n'est ici pas déplacée) des copies des documents qu'on leur confie. Lorsque le document est modifié, on leur confie la nouvelle version, et ils savent n'archiver que la différence entre l'ancienne et la nouvelle version, grâce à l'algorithme du génial programme diff.

Antiquité : RCS



Mon premier VCS fut RCS (pour Revision Control System), auquel je m'initiai sous la férule d'Yves Devillers lorsque nous créâmes l'association Fnet. Il nous imposa cette discipline pour gérer le fonds documentaire et technique de ce qui était un des premiers FAI français, en même temps qu'il nous apprenait avec fermeté l'étiquette du réseau et de la messagerie, je lui en serai toujours reconnaissant.

RCS, dont la première version de Walter F. Tichy remonte à 1982, (voir la man page

) faisait bien le travail, et d'ailleurs certains outils contemporains (CVS par exemple) ne sont qu'ajouts de fonctions supplémentaires à un noyau RCS. Ainsi :
  • pour créer l'archive, dans le dossier qui contient les fichiers dont il faut conserver l'historique des versions successives : mkdir RCS ;
  • pour archiver un fichier, ou mettre à jour l'archive déjà existante : ci -u ce-fichier (ci est à l'origine l'abréviation de check-in, auquel s'est substitué commit) ;
  • pour extraire un fichier de l'archive : co ce-fichier.
C'est simple et de bon goût, et pendant des années les développeurs en ont été satisfaits, mais à l'usage les lacunes de RCS sont devenues gênantes :
  • RCS permet de gérer les fichiers dossier par dossier, mais pas une arborescence de dossiers, du moins pas de façon simple ;
  • RCS ne permet pas de travailler en réseau ;
  • RCS ne permet pas de maintenir concurremment, simultanément, plusieurs versions d'une collection de fichiers.

Renaissance : CVS



Pour combler ces lacunes fut créé CVS (en 1986 ou 1989 selon que l'on considère le script précurseur de Dick Grune ou le programme de Brian Berliner qui s'en est inspiré, voir la man
page
), qui ajoute à RCS précisément les trois fonctions que nous venons de mentionner, et qui depuis des années est l'outil de partage standard pour le développement du logiciel libre. Ainsi, le développeur intéressé par un logiciel et désireux de contribuer à son amélioration commencera par télé-charger l'arborescence CVS du projet, ce qui lui permettra de lire le code existant, puis de suggérer des améliorations en soumettant à l'équipe du projet des modifications du code sous forme de patch : patch est la fonction inverse de diff, diff calcule la différence entre deux versions d'un texte, patch applique à l'ancienne version la liste de modifications calculées par diff pour obtenir la nouvelle version. Si le patch du contributeur est accepté par la communauté, le responsable du projet en fera un commit dans l'arborescence principale. Si au sein de la communauté des développeurs se font jour des divergences, ou si l'on souhaite expérimenter une voie nouvelle, CVS permet de maintenir concurremment plusieurs branches du logiciel, qui ultérieurement pourront soit converger à nouveau, soit entériner la scission, appelée fork.

Depuis des années j'utilise CVS de façon solipsiste : j'ai sur un serveur sûr et accessible une archive centrale ; quand je travaille sur un texte ou un programme, plusieurs fois par jour je fais un commit (cvs ci) depuis mon poste de travail du moment, puis dès que possible une mise à jour (cvs update) sur mes autres machines (au bureau, à la maison, le portable).

Cette méthode m'a permis de ne jamais perdre de textes, malgré des pannes diverses et variées. Il ne m'échappe pas que d'autres procédés auraient pu me donner semblable sécurité : ainsi le logiciel Unison me permettrait d'avoir sur chacune de mes machines la copie à l'identique de tout ou partie d'un système de fichiers. Mais ce n'est pas exactement ce que je veux : mes fichiers au bureau et à la maison ne sont pas les mêmes, et en outre cela pose des problèmes, certes solubles, mais pas forcément simples, pour les fichiers de configuration du système.

Lacunes de CVS

Malgré les immenses services rendus à la communauté, et à moi en particulier, CVS n'est pas exempt de critiques :
  • CVS n'est qu'un habillage de RCS, d'où lourdeur, complexité et redondance dont résultent lenteur et, parfois, erreurs ; j'avoue n'avoir personnellement jamais subi d'erreurs, et la dimension modeste de mes travaux me rend la lenteur supportable. La complexité, conjuguée avec la faiblesse de la documentation, est très dissuasive pour le débutant.
  • En ce qui me concerne, le défaut principal est l'unicité de l'archive centrale : lorsque je n'ai plus accès au réseau, je n'ai plus CVS, je travaille sans filet ; j'aimerais avoir une archive accessible par le réseau, et une autre, locale, en l'absence de réseau ; je sais que c'est possible, au prix d'une gymnastique à mon avis incompatible avec l'exigence de sécurité, qui demande de la simplicité.
  • Renommer un fichier, le déplacer dans l'arborescence, déplacer un répertoire sont des opérations courantes au cours de la vie d'un projet, et ignorées par CVS : il faut, à la main, détruire le fichier sous son ancien nom et le réintroduire avec son nouveau nom ou son nouvel emplacement, ce qui a pour conséquence la perte de tout l'historique, or a priori la gestion de l'historique est une des raisons d'être de ce genre de système.

La question des versions de livraison

Un défaut qui me concerne moins, mais gênant pour le développeur de
logiciel, m’a été exposé par Manuel Serrano (auteur du compilateur
Bigloo pour le langage
Scheme
).

Un logiciel de taille moyenne comme Bigloo (120 000 lignes de Scheme)
est construit à partir de centaines de fichiers, répartis entre
quelques dizaines de répertoires. Chacun de ces fichiers a une
évolution propre, certains sont modifiés fréquemment, d’autres moins
souvent, et cela varie selon les étapes du développement. C’est-à-dire
que du point de vue du logiciel de gestion de versions, chaque fichier
a un numéro de version qui évolue indépendemment des autres. Lorsqu’à
une date déterminée l’auteur veut publier une nouvelle version du
logiciel, que nous appellerons version de livraison, construite à partir de tous les fichiers qui ont chacun leur
propre numéro de version, il faut trouver une façon d’enregistrer,
pour cette version du logiciel, les numéros de version de chaque
fichier qui la constitue, afin de pouvoir reconstruire la version
voulue. CVS n’offre aucun mécanisme pour faire cela correctement ; les
adeptes vous orientent en général vers le système d’étiquettes
(tags)
de CVS, une verrue particulièrement inélégante, mal réalisée
et mal documentée du système, et qui de toute façon ne répond pas
vraiment au problème, dans la mesure où elle imposerait une gestion
manuelle des versions.

Cette question des versions de livraison sera reprise dans une note ultérieure.

Quelle est la suite de cette quête ? Vous le saurez en allant lire l’article suivant


This document was translated from LATEX by HEVEA.