"http://www.w3.org/TR/REC-html40/loose.dtd">
Changer d'environnement de travailLaurent 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
- 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.
- 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.