Gestion des fichers d`un projet : CVS

Gestion des fichers d’un projet : CVS
9 mai 2005
1
Introduction
Pour travailler en groupe sur un projet, le besoin d’un outil de partage de fichiers se fait assez
vite sentir. Ce que l’on recherche, c’est un moyen de :
– Mettre en commun un ensemble de fichiers sur une machine distante
– Pouvoir obtenir une copie de l’ensemble des fichiers du projet
– Pouvoir mettre à jour la version partagée à partir d’une version locale
– Pouvoir mettre à jour une version locale à partir d’une version partagée
– Gérer les invévitables conflits.
– Mémoriser les modifications pour pouvoir revenir sur des versions précédentes
L’outil que nous allons investiguer réalise toutes ces tâches. Il s’agit de CVS (Concurrent Version
System). De nombreux autres produits similaires existent, que ce soit dans le domaine OpenSource
(subversion, arch) ou dans le domaine commercial (clearcase). CVS reste l’outil le plus répandu,
malgrès quelques défauts que nous aborderons.
Le principe de CVS est de stocker non seulement les fichiers, mais également les modifications
faites entre deux versions d’un même fichiers. CVS permet alors à tout moment de reconstruire une
version particulière d’un fichier.
2
Architecture
CVS offre une architecture centralisée (pour une architecture répartie, on s’intéressera à arch).
Tous les fichiers d’un projet vont donc reposer dans un endroit unique, appelé dépôt ou repository
en anglais. Chaque dépôt CVS peut abriter plusieurs modules. Un modules peut correspondre à
un projet, ou bien à une sous partie d’un projet, suivant la granularité choisie. Une fois un dépôt
construit, il faut s’y connecter pour l’utiliser. CVS propose plusieurs moyen de connexion possible
entre la machine cliente (la machine d’un des membres du projet) et la machine serveur abritant le
dépôt :
accès direct les deux machines sont confondues
mode serveur pserver, gserver, kserver un démon cvsd écoute sur un port dédié les requêtes
des clients. Chaque version de serveur permet un type d’authentification différente.
accès en mode rsh/ssh : les manipulations sont effectuées en accès direct, mais par l’intermédiaire d’une connexion rsh/ssh.
1
Toutes les commandes cvs sont accessibles à partir du seul exécutable éponyme. L’exécutable
cvs utilise la variable d’environnement CVSROOT pour savoir quel est son dépôt de travail, ou bien
l’option -d de la commande. Dans ce TP, nous allons travailler en mode local (machines cliente
et serveur confondues). La seule variante pour les autres modes est la syntaxe de la définition de
CVSROOT.
3
Initialisation d’un dépot
Créez un répertoire qui sera votre dépôt cvs et intialiser la variable d’environnement CVSROOT à
cette valeur. Appelez ensuite la commande cvs init, qui créera un répertoire CVSROOT à l’intérieur
du répertoire spécifié, contenant les fichiers propres à la partie serveur de cvs.
$>mkdir ~/cvs
$>setenv CVSROOT ~/cvs
$>cvs init
$>cd ~/cvs
$>ls
CVSROOT
Toutes les commandes CVS que nous verrons utilisent cette variable d’environnement. L’alternative est d’utiliser l’option -d de la commande cvs pour spécifier la racine du CVS.
4
Utilisation de base
Nous allons passer en revue les différentes commande de CVS. Chaque commande CVS est de
la forme :
$> cvs [<options>...] <sous-commande> [<options sous-commande>...] [<noms fichiers>...]
Pour obtenir de la documentation :
$> cvs --help-commands
$> cvs --help-options
4.1
Création d’un nouveau projet
Créons d’abord un nouveau projet. Deux cas se présentent : un projet vide ou l’import d’un
projet existant.
Pour créer un nouveau projet sur le dépôt CVS à partir d’un répertoire existant, on se place
DANS le répertoire racine des sources du projet, et on exécute la commande cvs import.
$> cd /into/rep/sources
$> cvs import -m "Message stockée dans les logs cvs" nom_projet tag1 tag2
# verification :
$> cd /tmp
$> cvs checkout nom_projet
$> ls nom_projet
2
Nous aborderons la significations des tags plus tard. Sachez juste que cela permet d’identifier
par un nom plutôt que par un numéro une version particulière d’un fichier, ici la version initiale.
Pour partir d’un projet vide, il suffit de créer l’arborescence vide du projet et d’en faire un
import.
Comme exercice, répéter les commandes précédentes pour importer le contenu d’un de vos
projets dans le dépôt CVS créé ci-dessus.
4.2
Cycle de développement
Pour un des développeurs du projet, la vision est la suivante : il va créer une version locale du
projet à partir du dépôt (commande cvs checkout). Ensuite, il va utiliser ses outils habituels pour
modifier les fichiers de la version locale. Périodiquement, il va synchroniser sa copie locale avec le
dépôt, pour récupérer les modifications faites par les autres développeurs (commande cvs update).
Et enfin, il va reverser ses modifications dans le dépôt (commande cvs commit). Dans la version
locale, un répertoire CVS contient les informations sur les fichiers locaux ainsi que sur le dépôt. Par
défaut, un fichier ou un répertoire nouveau créé dans la copie locale n’est pas suivi par CVS. Pour
cela, il faut explicitement utiliser la commande cvs add.
En résumé, on sort d’abord les fichiers du dépôt pour les mettre dans un répertoire local, on les
modifie, puis on les remet dans le dépôt.
4.3
Création de la copie locale
Pour commencer à travailler, la première opération est de créer une copie locale des fichiers
d’un projet stocké dans un dépôt CVS. Pour cela, on utilise la commande cvs checkout. Cette
commande peut s’abréger en cvs co ou cvs get. Le seul argument nécessaire est le nom du module
que l’on souhaite charger. Un répertoire local est alors crée, portant le nom du module, et contenant
tous les fichiers de ce module. En outre, un répertoire CVS contient l’état des fichiers par rapport
au dépot.
$> cvs checkout nom_projet
Cette commande va consulter le répertoire nom_projet sur la machine et dans le répertoire
racine CVS indiqué par la variable d’environnement CVSROOT. Une fois la copie locale crée, placer
vous à l’intérieur du répertoire de plus haut niveau. Les commandes CVS ultérieure utiliseront les
informations contenus dans le répertoire CVS.
4.4
Mise à jour de la copie locale
La copie locale dérive avec le temps de la version centralisée sur le serveur. Pour incorporer les
modifications de la version commune dans la version locale, il faut utiliser la commande cvs update :
$> cvs update -dP
L’option -d demande à CVS de créer dans la copie locale les nouveaux répertoires qui ont été
rajoutés au dépôt, le comportement par défaut est de ne pas les créer. L’option -P supprime les
répertoires vide de la copie locale.
La commande cvs update est assez bavarde. Au niveau de la sortie, remarquez par exemple le
U nom_fichier signifiant que le fichier a été mis à jour.
3
4.5
Modification du dépôt
Vous pouvez modifier les fichiers de la copie locale avec vos outils habituels. Quand vous voudrez
incorporer vos modifications au dépot, il suffit d’utiliser la commande cvs commit.
$> cvs update -dP
$> cvs commit
Avant d’utiliser la commande cvs commit, il faut impérativement mettre sa copie locale à jour
avec les modification faites par les autres membres du projet, en utilisant la commande cvs update.
Cette commande va permettre de détecter les conflits éventuels entre vos modifications et celles des
autres développeurs. Nous traiterons des conflits un peu plus tard, et supposons pour le moment
que tout se passe bien.
Cette commande ouvre l’éditeur de texte pointé par la variable d’environnement CVSEDITOR, ou
par EDITOR si la première n’existe pas. Vous devez alors rentrer une description de vos modifications,
fichier par fichier que vous avez modifié.
4.6
Ajouter un document au pot commun
Pour rajouter une nouvelle ressource à la gestion CVS, il faut d’abord créer un fichier normalement. Ensuite, il faut spécifier explicitement que cette ressource doit être ajoutée à la copie CVS
locale. Pour cela :
$> cvs add Toto.java
Cette commande ajoute le fichier Toto.java à la copie locale. Il ne sera ajouté au dépôt qu’à la
prochaine validation (cvs commit).
Pour les répertoires, la commande à utiliser est la même. Par contre, la validation de la création
est implicite.
Faites attention, quand vous ajouter un fichier ou un répertoire dans le CVS, assurez vous que
toute l’arborescence parente menant à cette ressource a été également rajoutée au CVS.
4.7
Enlever un document du pot commun
L’opération de suppression se fait en deux temps. D’abord il faut supprimer le document de la
copie locale, puis informer CVS de cette suppression :
$> rm Toto.java
$> cvs remove Toto
Le fichier est alors marqué ”à supprimer” lors de la prochaine validation. A noter que CVS
gardera au niveau du dépôt toute l’historique du fichier, et qu’il sera donc possible de le récupérer.
La commande cvs remove est récursive, ce qui permet de marquer pour la suppression toute une
arborescence.
5
Signification des messages de CVS
Avant de s’intéresser à la gestion des conflits, regardons un peu plus avant la sortie de la commande cvs update. Pour utiliser un format allégé, vous pouvez rajouter l’option -q à la commande.
4
U fichier : la copie locale du fichier a été mise à jour
? fichier : fichier existant dans la copie locale mais pas dans le dépôt, et non gérés par CVS.
Typiquement des fichiers crées localement et qui n’ont pas été ajoutés grâce à cvs add.
A fichier : l’ajout de ce fichier au dépôt a été programmé.
M fichier : vous avez modifié ce fichier localement. CVS a pu incorporer les modifications provenant du dépôt sans générer de conflit.
R fichier : la suppression de ce fichier du dépôt a été programmée.
C fichier : vous avez modifié ce fichier localement. CVS a incorporé les modifications provenant
du dépôt, mais elles rentrent en conflit avec les votres.
6
Gestion des conflits
Qu’est-ce qu’un conflit ? CVS se repère à l’intérieur des fichiers textes par les numéros de ligne.
Si deux modifications ont été faites sur le même fichier par deux source différentes, alors il y a
conflit. CVS ne gère pas lui même les conflits, il ne fait que les signaler. CVS incorpore dans le
fichier créant le conflit les 2 modifications conflictuelles, entourées de balises ”==========”.
Le développeur doit alors résoudre manuellement le problème, puis valider la correction.
Exercice : créez volontairement un conflit. Pour cela, faites 2 copies locales du même module
d’un dépôt CVS. Modifiez un des fichiers dans la première copie, validez les modifications pour
les reverser dans le dépôt. Modifiez le fichier dans la 2e copie, et mettez à jour cette copie. La
commande cvs update doit signaler un conflit pour ce fichier. Editez alors le fichier, réglez le
problème et valider la modification.
A tout moment, la commande cvs status fichier permet de connaı̂tre l’état d’un fichier.
7
Définition de versions
De manière interne, CVS identifie les différentes versions des fichiers par des numéros de la
forme ”x.y.z”, avec plus ou moins de chiffres. Pour les versions successives, le dernier numéro est
incrémenté.
On peut également donner un nom à une version d’un fichier. Plus intéressant, on peut donner
le même nom à un ensemble de versions de fichiers, créant ainsi la notion de version au niveau du
projet tout entier.
Pour cela :
$> cvs tag nomDuTag nom
Ici nom désigne un fichier ou un répertoire. Dans le deuxième cas, le marquage sera récursif.
Pour voir les différents tags d’un fichier :
$> cvs status -v fichier
Pour créer une copie locale à partir d’une certaine version :
$> cvs checkout -r tag module
5
8
Création de branche séparées
Les premiers numéros de la version d’un fichier identifie la branche de développement. CVS peut
suivre en même temps plusieurs branches de développement/ Une utilisation commune de CVS est
de maintenir des branches séparées pour une version stable d’un projet et pour une version de
développement.
Pour créer une branche, on utilisera :
$> cvs tag -b stable
Cette commande crée la branche stable à partir des versions des fichiers de la copie locale.
$> cvs rtag -b -r tag stable module
Cette commande crée la branche stable dans le module module à partir de la version marquée
tag des fichiers.
Pour utiliser une branche spéciale :
$> cvs checkout -r stable module
Cette commande crée une copie locale à partir de la branche stable.
$> cd module
$> cvs update -r stable
Cette commande mets à jour une copie locale à partir d’une branche particulière.
9
CVS sous Eclipse
L’utilisation de CVS à partir d’Eclipse est assez facile. Une perspective (nom désignant sous
Eclipse une configuration spécifique de l’interface utilisateur) particulière est réservée à cet usage.
Pour l’obtenir, faire Window, Open a Perspective, Other, CVS Repository Exploring
Un clic droit sur la partie de gauche permet de lancer New, Repository Location. Remplissez
le formulaire qui apparaı̂t. Ce formulaire permet à Eclipse de récolter les informations nécessaires
pour la connexion à un dépôt cvs. Une fois le dépôt trouvé, vous pouvez créer un nouveau projet à
partir de n’importe quelle branche. Vous pouvez alors repasser à une perspective normale.
Dans la perspective normale, un menu est rajouté pour les fichiers sous contrôle CVS, permettant
les opérations de mise à jour et de validation.
10
Utilisation de CVS par SSH
Seule la syntaxe de CVSROOT change. Il faut également spécifier que l’on veut utiliser SSH
pour faire la connexion à la machine serveur (par défaut rsh est utilisé).
$> setenv CVS_RSH=ssh
$> setenv CVSROOT :ext:login@machine:/chemin/vers/cvsroot
6