réalisation des projets c2i

Exemple d’application de la gestion de versions

Un exemple d’application de gestion de versions est disponible l’encyclopédie Wikipédia. En effet, chaque article a un historique intégral depuis sa création, comprenant toutes les modifications jamais effectuées . Il est possible de visualiser les changements apportés entre deux versions arbitraires, de revenir à des versions antérieures, ...

De plus plusieurs personnes peuvent modifier le même article simultanément, avec un conflit uniquement si la même zone a été modifiée de façon incompatible.

Même si le mécanisme est peu visible pour le contributeur, il s’agit bel et bien d’un système de gestion de version.

CVS et la gestion de configuration

CVS (Concurrent Version System), [CVS 00] quand à lui, renouvelle le genre, en

incluant la notion de branche de développement, qui permet un véritable développement

en concurrence, chaque branche pouvant à son tour devenir la branche de référence,

tout en conservant son versionnage propre. Aux capacités multi-utilisateurs d

RCS, CVS ajoute aussi des possibilités de développement en réseau, qui en font un

outil de gestion de configuration, sur laquelle il est utile de faire quelques rappels.

2.1. La gestion de configuration et ses outils

Depuis les débuts de l’informatique, la gestion de configuration automatisée est le

doux rêve de tous les acteurs de l’industrie informatique, qu’ils soient constructeurs,

développeurs ou simple utilisateurs.

D’abords privilège des constructeurs qui fournissaient sur les premiers ordinateurs

des configurations rigides déléguables au mieux à un administrateur système, la gestion

de configuration est devenue le problème de tous avec l’apparition de machines

multi-utilisateurs, des systèmes ouverts, des systèmes micros, et des applications qui

vont avec.

Si on peut dire que l’évolution des systèmes est désormais aux mains des développeurs,

qui enrichissent les systèmes avec des applications, ceux-ci sont loin d’avoir

résolu les nombreux problèmes de gestion de configuration qu’ils posent au reste de

la communauté informatique et que l’on peut résumer rapidement en cette liste :

– les problèmes de structure : modélisation, interfaces, relation, consistence...

– les problèmes de construction : génération, snapshot, optimisation, régénération...

– les problème de comptabilité et d’audit : statistiques, rapports, historique, traçabilité...

– les problèmes de sécurité : contrôle d’accès, cloisonnement, suivi des bugs...

– les problèmes de version : version du logiciel, version de la configuration,

contexte, référentiel...

Tous ces problèmes sont passionants et certains font déjà l’objet de recherches

abondantes dans le monde de la science informatique [MOL 97] ; ceux de la dernière

catégorie ont la particularité de s’appliquer aussi à des documents numériques ne correspondant

pas forcément à des projets informatiques. C’est ce qui a motivé la présente

étude.

En effet, depuis qu’ils ont été mis en relief, ces problèmes de gestion de versions

ont suscité le développement d’outils spécifiques. Dans la partie technique de cet article,

ce sont les services rendus par ces outils que nous associerons au terme de « versionnage

».

2.2. CVS et le travail en groupe

On peut résumer les services de CVS en 4 grands besoins :

– travailler à plusieurs sur les mêmes fichiers au même moment ;

– gérer les versions des fichiers en cours de rédaction ;

– suivre les versions de documents externes ;

– gérer plusieurs branches de développement.

Pour cela CVS utilise une zone de stockage spécifique appelé référentiel, dans

lequel sont stockées toutes les données nécessaires au fonctionnement et suffisante

pour retrouver toutes les données qui lui ont été confiées.

Il fait aussi un grand usage des ressources du système, comme la notion d’utilisateurs

multiples, la structure arborescente des fichiers, et les possibilités client/serveur.

C’est pourquoi ces fonctions-là ne seront pas détaillées.

2.3. Utilisation du référentiel

Un référentiel CVS est un aggrégat d’objets ayant chacun leur version. L’évolution

des objets et de leurs versions se fait par :

– extraction du référentiel (checkout/update) ;

– modification en environnement de travail standard ;

– repose dans le référentiel pour mise à jour (commit).

On dit que CVS utilise un modèle par composition. Pour la gestion de la concurrence,

il s’inspire du modèle des transactions longues, qui a la caractéristique de

supporter autant de divergences que possible entre les différentes versions, la seule

contrainte de cohérence étant exigée au moment de la réunification des versions.

Autrement dit une session de travail avec CVS peut se résumer ainsi :

1. cvs update : Je synchronise ma copie de travail avec le référentiel. CVS me

signale les mises à jour.

2. à la fin de ma session, je valide mon travail. CVS me confirme si mes modifications

sont compatibles avec les autres travaux en cours.

3. si elles ne le sont pas, j’ai le choix de conserver mon autonomie ; je ne profiterai

plus des mises à jour concernant cet objet. Ce choix se répercutera sur les tentatives

de mises à jour futures (warning), à moins que je ne crée ma propre branche de développement.

4. si je choisis la dissidence, et que je veux en faire profiter les autres, je dois créer

une nouvelle branche.

Chaque transaction est enregistrée et peut faire l’objet d’une action (envoi d’un

message électronique à l’équipe de développement

– pour chacun de connaitre l’historique des actions et en particulier des modifications

apportées à chaque objet 8

– pour l’administrateur de savoir qui en est où.

Remarque : Il est courant d’ajuster les droits pour mettre tous les développeurs

à égalité. En revanche, il ne peut y avoir à tout moment qu’une branche principale,

chaque branche pouvant reprendre ce titre sur commande, d’où le besoin d’une certaine

concertation dans l’équipe.

2.4. Evolutions

Le succès de CVS s’explique par le fait qu’il effectue des tâches compliquées

faciles contrôler, du fait de l’accessibilité des textes et la simplicité de l’outil[PUR 00].

On constate à l’usage que :

– les conflits sont rares et généralement faciles à résoudre ;

– la gestion des versions est rassurante pour les auteurs qui peuvent retrouver à

tout moment une version satisfaisante à leur goût ;

– le fait d’associer aux validations des échanges de messages ou d’autres actions

aide à mesurer l’activité réelle de développement ;

D’une manière générale, l’utilisation d’un mécanisme automatique de contrôle responsabilise

les participants. L’un des spécialistes français de CVS [MOL 97] y voit

même une explication au faible nombre de conflits.

2.5. Limites

On a vu plus haut que CVS ne couvre pas tous les besoins de ses utilisateurs en

matière de gestion de configuration. On peut classer aussi dans cette catégorie les

problèmes organisationnels qui sont laissés à la liberté des gestionnaires de projets car

ils sont d’un autre niveau comme :

– quand une version peut-elle être validée ?

– qui a le droit de metre à jour la branche courante ?

– quand doit-on créer une nouvelle branche ?

Ce sont des décisions concertées que doivent prendre les développeurs au moment

où ils conviennent de versionner un projet. Contrairement à d’autres tâches de spécification

des projets informatiques, il est très facile d’intégrer dans un référentiel CVS

un projet en cours.

8. Cette fonction comprend la possibilité de récupérer n’importe quelle trouvaille perdue par

mégarde entre deux mises à jour, sans avoir recours aux sauvegardes.

celui de l’arborescence est encore pire. De même, il est délicat de mélanger deux

arborescences ayant des référentiels différents ;

– l’utilisation de fichiers spéciaux au sens du système. Cette limite de CVS le rend

impropre à la sauvegarde (mais qui n’empêche en rien la sauvegarde du repository, au

contraire).

3. Exemples de tâches

Voyons donc quelques tâches typiques des professionnels de l’information, tâches

qui peuvent justifier un système de versionnage. [BOR 00] Les exemples sont montrés

avec la ligne de commande de CVS. CVS a aussi des interfaces graphiques.

3.1. Retrouver un serveur web dans l’état où il était le 10 février

Le contenu des serveurs web évolue très vite, souvent sans tenir compte des problèmes

d’archivage. On supprime ou on modifie des pages qu’on ne garde pas. Cela

rend très difficile toute analyse de l’évolution d’un serveur, par exemple.

Souvent, on éprouve le besoin de garder une copie du serveur à une date donnée.

Mais, sans outil de gestion des versions, il est très difficile, après coup, de retrouver la

copie pertinente.

On voit ainsi des serveurs web dont le répertoire contient index.html, index.

html.old, index.html.very-old, links.html, links.html.old, etc. Sans que

l’on puisse dire facilement quel links.html va avec quel index.html.

Un bon système de versionnage permet de récupérer l’état d’un ensemble de pages

à une date donnée.

Commande CVS pour récupérer le répertoire htdocs, avec tous ses fichiers, dans

son état du 10 février :

cvs checkout -D '2001-02-10' htdocs

Un système de gestion de versions peut permettre de marquer un ensemble de

fichiers d’un label, qui facilitera l’extraction ultérieure.

Commande CVS pour marquer le répertoire htdocs :

cvs tag VERSION_DURAND_MODIFIEE_DUPONT

et pour extraire le répertoire tel qu’il était lors du marquage :

cvs checkout -r VERSION_DURAND_MODIFIEE_DUPONT htdocs