Travaux Pratiques

Exemple simple


Avant-propos

L'exercice consiste à initialiser une base cvs, à y déposer un projet, proposé ici sous la forme d'une page html, puis à réaliser localement des modifications de cette page, afin de les prendre en compte par les commandes de cvs. Le texte de l'exercice est indiqué dans le contenu de la page html, que vous lisez actuellement. Elle est localisée intialement dans le répertoire

Les modifications de cette page sont réalisées en pratique en copiant les pages contenues dans le répertoire versions comme indiqué au fur et à mesure de l'exercice. Dans la page html, les lignes en orange peuvent être directement reprises à la souris pour poursuivre l'exercice.

Créer la base CVS en local

La base CVS est créée en local, par exemple, sous le répertoire exemple_simple/base,  qui appartient au login user sur la machine locale.

La base doit être initialisée avant toute opération, ce en pratique qui est fait par la commande cvs -d ~/exemple_simple/base init.

Dans ce cas, le répertoire ~/exemple_simple/base contient un sous-répertoire ~/exemple_simple/base/CVSROOT dans lequel se trouvent les fichiers de gestion de la base.

Accès à la base CVS

L'accès à la base peut se faire de trois manières différentes. Le choix de la façon d'accéder à la base est défini par la variable d'environnement CVSROOT :

Ici, pour l'exercice, l'accès se fait en local. En bash :

En csh ou tcsh :

Dépôt d'un projet dans la base CVS

L'utilisateur user dispose sur la machine locale.cnrs.fr d'un projet page.html qu'il veut déposer dans la base CVS. Il doit choisir son mode d'accès à la base en définissant la variable CVSROOT et les autres variables d'envrionnement nécessaires sur locale.cnrs.fr. Le dépôt initial du projet s'effectue alors par la commande import :

Dans la base CVS a été créé un module projet/ qui contient le fichier page.html,v où l'extension ,v indique qu'il s'agit bien d'une archive.

Récupérer une version de travail

Avant de poursuivre le développement de son projet page.html, l'utilisateur user doit récupérer une version de travail à partir de l'archive CVS. Ceci est réalisé par la commande checkout :

Un répertoire projet/, contenant le fichier projet/page.html et un sous-répertoire projet/CVS est crééé par cette opération. Le développement du projet peut alors être réalisé avec les outils habituels en descendant dans le répertoire projet/ .

L'ensemble des modifications doit être réalisé à partir de cette copie de travail. Il ne faut jamais accéder directement aux fichiers de la base CVS, mais uniquement par l'intermédiaire des commandes de CVS.

Pour afficher un résumé des principales commandes de CVS, tapez dans le répertoire projet/

et réactualisez la page du projet dans votre navigateur.


Codiciel - 2004

Principales commandes de CVS

commande descriptif de l'action
add ajoute un fichier ou un répertoire à la base
checkout extrait une copie de travail
commit archive une version dans la base
diff visualise les différences entre deux versions
history visualise l'historique de la base
import archive une aborescence de fichiers dans une branche d'un module de la base
init met en place une base CVS
log liste les informations sur les fichiers et leurs versions
release quitte la copie de travail d'un module
remove retire un fichier d'un module
rtag manipule un nom symbolique de version pour un ou plusieurs modules
status visualise l'état des fichiers par rapport à la base CVS
tag manipule un nom symbolique de version pour un ou plusieurs fichiers
update met à jour une copie de travail par rapport aux versions de la base

Visualiser l'état de la copie de travail par rapport à la base CVS

Pour visualiser l'état de la page page.html par rapport à la base CVS, il suffit de faire la commande status

Dans ce cas, la commande retourne le résultat suivant, indiquant que le fichier du projet de l'utilisateur a été localement modifié par rapport à la version de la base CVS :

Pour archiver cette modification dans la base CVS, faire :

Pour vérifier que la modification a bien été prose en compte, questionner à nouveau la base

La modification est enregistrée sous le numéro de version 1.2 alors que la version initiale était stockée sous le numéro 1.1 :

Il existe aussi des interfaces graphiques permettant de réaliser ces commandes dans un environnement de fenêtres. Pour en savoir plus, allez chercher la page suivante :

et réactualisez la page du projet dans votre navigateur.


Codiciel - 2004

Interfaces graphiques

Il existe de nombreuses interfaces graphiques permettant de réaliser les commandes CVS dans un environnement de fenêtres. Parmi ces outils, les plus répandus sont :

En supposant que cervisia soit installée sur la machine locale.cnrs.fr, son lancement dans le répertoire de travail projet/ s'effectue par la commande

La manipulation de cette interface est relativement intuitive. Elle dispose également d'un menu d'aide assez complet, avec des informations synthétiques sur CVS. Pour avoir un aperçu de l'interface graphique, chargez les images suivantes dans votre répertoire de travail :

et réactualisez votre page. Les images devraient apparaître ci-dessous :

Les fichiers images sont nouveaux dans le projet et ne sont donc pas répertoriés dans la base CVS. Pour les inclures, il faut les ajouter à la base par la commande add pour signaler l'ajout et commit pour l'archiver. Essayez de réaliser ces commandes par l'intermédiaire de l'interface cervisia.

Les fichiers ajoutés doivent passer du status Not in CVS à Locally Added. Il faut noter que les commandes d'ajout, add, ou de retrait, remove, de fichiers doivent impérativement être suivies de la commande commit pour être prises en compte dans la base CVS.

Visualisez l'historique et l'arborescence à l'aide de cervisia.

Pour avoir un aperçu du résultat, chargez les fichiers suivants :

et actualisez la page du projet dans votre navigateur.




Codiciel - 2004

Le résultat se présente de la manière suivante :

Nommer les versions avec des noms symboliques

Comme le montre l'exemple, les archives sont automatiquement numérotées à partir du dépôt initial, nommé 1.1.1.1 et 1.1, avec les incréments du type 1.2, 1.3 ... et ainsi de suite pour les versions successives. Il peut être intéressant de nommer explicitement la version d'un ou de plusieurs fichiers du projet à un moment donné afin de définir une version de livraison par exemple. Ceci peut être réalisé simplement en utilisant un nom symbolique attribué avec la commande tag ou rtag. Dans notre exemple, leur seul tag déja existant, v1_0, a été donné au dépôt. En faisant la commande :

Il vient en effet :

Supposons que l'utilisateur veuille nommer la dernière version du projet v2_0, il suffit d'associer ce nom symbolique à tous les fichiers existants. Effectuez cette opération avec cervisia et refaire

Cette fois,

Il est important de noter que les noms symboliques permettent d'associer dans une même version des fichiers qui ne portent pas le même numéro de révision automatique.

Cette opération permet également d'exporter vers un autre utilisateur la version correspondant au nom symbolique. Il est donc possible de figer une version tout en continuant à développer le projet. Lorsque ce second utilisateur est amené à développer le projet également, il est toutefois préférable qu'il récupère la dernière version ou bien travaille sur une autre branche de développement du projet. Dans ce cas, il faut définir cette branche. Ce peut être utile par exemple pour corriger une version alors que le développement s'est poursuivi dans la branche principale.

Pour créer une branche, chargez le fichier suivant :

et réactualisez la page du projet dans votre navigateur.


Codiciel - 2004

Faire des branches

Mettre à jour la base de développement principal sur le fichier page.html, dont la version de révision doit maintenant être 1.4. L'utilisateur va créer une branche à partir de cette version. Réalisez cette opération à l'aide de cervisia. Dans ce cas, il suffit de sélectionner l'ensemble des fichiers du projet et d'aller dans le menu Advanced puis Tag/Branch.... La branche pourras être taggée du nom de version v3_0

Ensuite, l'utilisateur de la branche principale va continuer à développer cette branche. Chargez par exemple un nouveau fichier :

et actualisez le projet par rapport à la base. La version de révision de la page page.html doit être désormais 1.5.


Codiciel - 2004

Travailler dans la branche

Pour travailler dans la branche, il faut commencer par importer la version de travail de la branche, en faisant par exemple la commande

Dans ce cas un second répertoire projet est créé, qui peut être renommé suivant le nom du tag initial de la branche ainsi récupérée

Pour travailler dans la branche, il faut descendre dans ce répertoire

et continuer à y réaliser les modifications nécessaires. Pour suivre ce travail avec cervisia, il ne faut pas oublier d'ouvrir le bon répertoire de travail ! La modification suivante est apportée au fichier page.html :

Il faut noter que la branche est bin basée sur la version 1.4 du fichier page.html.

Le nouveau fichier chargé est identique, avec un fond gris. Les branches peuvent être visualisées par la commande log sous cervisia. Le numéro de révision de la branche est alors 1.4.2.1. Il faut ensuite pouvoir réunir la branche secondaire à la principale. Chargez à nouveau la modification suivante dans la banche secondaire :




Codiciel - 2004

Réunir les branches secondaire et principale

Il faut ensuite pouvoir réunir les modifications de cette branche secondaire à la branche principale et pour cela revenir à la branche principale avant d'y charger le fichier suivant :


Codiciel - 2004

Réunir les branches secondaire et principale

Dans la branche principale, mettre à jour les dernières modifications.

Les développements ou corrections réalisées dans la branche secondaire peuvent être réintégrées dans la branche principale en utilisant l'option merge de cervisia. Généralement cette opération entraîne des conflits, qu'il convient de résoudre avant de pouvoir soumettre la fusion des deux branches à CVS. Les zones conflictuelles sont indiquées par des marqueurs de type

dans les fichiers. Il convient alors d'éditer les fichiers où un conflit est détecté et résoudre le problème avec l'éditeur habituel. Pour conserver une trace des opérations réalisées avec la fusion des branches, il est conseillé de mettre un tag sur la version fusionnée, cette fusion n'étant pas matérialisée à l'écran.

La version qui résout les conflits est 1.7 et on peut par exemple y associer le nom symbolique du type Apres_fusion.

Revenir en arrière

Supposons désormais que la dernière version de labase comporte un problème et qu'il faille revenir à une version antérieure. Afin de faciliter l'historique des modifications, il est possible d'attribuer un nom symbolique au niveau de version des fichiers qui vont être récupérés, avant d'effectuer l'opération. Dans l'exemple, on va supposer que l'administrateur de la base décide de revenir à la version de page.html nommée V2_0.

Pour replacer cette version, il faut commencer par mettre à jour la dernière version du fichier, puis remplacer cette dernière version par la version antérieure choisie et replacer cette version dans la base. Cette opération peut également être réalisée de façon globale sur l'ensemble des fichiers.

Le retour en arrière se fait par les commandes update et commit :

Pour finir, les modifications continuent dans la branche principale.


Codiciel - 2004