Ce tutoriel est découpé en deux parties. La première explique comment utiliser CVS lorsque l'on n'est pas développeur, c'est-à-dire comment récupérer des sources CVS et les garder à jour. La seconde partie vous présente comment utiliser CVS pour développer en vous montrant comment modifier, ajouter, retirer des fichiers sur CVS, ainsi que comment réaliser bien d'autres tâches de développeurs. Si vous ne connaissez rien à CVS, il est recommandé de commencer par lire la première partie, puis la seconde ; si vous avez une petite expérience de CVS, mais que vous allez l'utiliser en tant que véritable développeur pour la première fois, vous trouverez votre bohneur dans la seconde partie (mais vous pouvez aussi avoir envie de parcourir rapidement la première partie).
CVS est un système client/serveur qui permet aux développeurs de conserver leurs projets sur un serveur central appelé dépôt (en anglais « CVS repository »). En utilisant les clients CVS et les outils associés, les développeurs peuvent faire des modifications du contenu sur le serveur. En fait, le dépôt CVS conserve chaque changement fait sur chaque fichier, créant ainsi un historique complet de toute l'évolution du développement du projet. Les développeurs peuvent demander des versions antérieures d'un fichier particulier, regarder un historique des modifications et réaliser au besoin plusieurs autres actions utiles.
Un nombre considérable de projets ont leur propre serveur CVS qui est utilisé par les développeurs du projet comme répertoire central pour tous leurs travaux. Les développeurs apportent quotidiennement des améliorations aux sources dans le dépôt CVS. Souvent, ces développeurs sont dispersés dans le monde entier; CVS leur fournit ainsi les mécanismes nécessaires pour unifier leur projet dans une structure centralisée et cohérente. CVS crée le « liant organisationnel » qui permet à ces développeurs d'améliorer leur code sans se marcher sur les pieds, sans perdre des données importantes ou sans être bloqués par l'impossiblité de mettre à jour certains fichiers critiques.
Quand les programmeurs sont prêts, ils archivent la version actuelle de leur travail sur CVS dans un fichier tar.gz et publient celui-ci comme une nouvelle version de leur logiciel. Pourtant, parfois, la dernière version officielle n'est pas assez récente pour vous pour diverses raisons. Dans la première partie de ce tutoriel, nous verrons comment utiliser CVS dans ce but : récupérer la version de développement la plus récente et la plus complète des sources pour votre usage personnel.
Avant que vous ne puissiez utiliser CVS, vous devez l'installer sur votre système. Le moyen le plus simple de vérifier si CVS est installé sur votre système est de taper :
# cvs
Si la commande cvs est trouvée, alors vous l'avez. Sinon, vous devez soit récupérer un paquet binaire pour votre distribution, soit l'installer depuis les sources. Installer CVS depuis les sources est plutôt simple et je vous montre comment le faire ci-dessous.
Installer CVS depuis les sources est facile. Tout d'abord, récupérez le tarball
cvs-1.11.tar.gz depuis
# tar xzvf cvs-1.11.tar.gz # cd cvs-1.11 # ./configure # make # make install
Maintenant, vous êtes prêt à travailler.
Beaucoup de distributions offrent une méthode facile pour installer des
logiciels. Par exemple, Gentoo offre la commande
# emerge cvs
Avant de commencer, il y a quelques notions fondamentales à connaître. La première est que pour se connecter sur un dépôt CVS, vous devez tout d'abord paramétrer un chemin appelé le CVSROOT (la racine CVS). CVSROOT est une chaîne de caractères, un peu comme une URL, qui dit à la commande cvs où se trouve le dépôt distant et comment on souhaite s'y connecter. Pour rendre les choses plus intéressantes, CVS supporte de nombreux formats pour CVSROOT, selon que le dépôt est local ou distant, et dépendamment de la méthode utilisée pour s'y connecter. Voici quelques exemples de CVSROOT avec des explications...
CVSROOT=/home/cvsroot
C'est un exemple de chemin pour une racine CVS locale. Vous devriez utiliser une telle variable si vous voulez vous connecter à un dépôt local situé dans /home/cvsroot; ou bien, vous pouvez aussi avoir un dépôt local monté via NFS sur /home/cvsroot.
CVSROOT=:pserver:cvs@foo.bar.com:/home/cvsroot
Ceci est un exemple de CVSROOT pour un dépôt existant sur l'hôte foo.bar.com et qui réside dans le /home/cvsroot de cette machine. La partie « :pserver: » indique à notre client qu'il doit se connecter à cette machine distante en utilisant le protocole pserver, un protocole incorporé à CVS. Typiquement, les répertoires CVS publics utilisent des pserver pour autoriser l'accès à des utilisateurs anonymes.
CVSROOT=drobbins@foo.bar.com:/data/cvs
Ceci est un exemple de CVSROOT qui utilise le protocole RSH ou SSH. Dans cet exemple, le CVS va accéder au dépôt sur foo.bar.com via le compte drobbins. Si la variable d'environnement CVS_RSH est réglée à « ssh », le client cvs va utiliser SSH pour se connecter, sinon, RSH est utilisé par défaut. L'accès par SSH est plus populaire chez ceux qui aiment la sécurité, mais ni RSH, ni SSH ne permettent l'accès anonyme aux sources. Pour utiliser cette méthode, il faut absolument avoir un compte sur foo.bar.com.
En plus de la racine CVS, vous allez avoir besoin du nom du module (groupe de sources) que vous voulez récupérer ainsi que le mot de passe anonyme que vous devez utiliser pour vous connecter au serveur CVS. À l'inverse des ftp anonymes, il n'y a pas de format « standard » pour les mots de passe anonymes, il faudra donc récupérer les mots de passe spécifiques publiés sur le site web du développeur ou le demander aux développeurs eux-mêmes. Avec ces informations, vous êtes prêt à commencer.
Récupérer des sources se fait en deux temps. Tout d'abord, il faut se connecter
au pserver. Ensuite, on récupère les sources avec la commande
# export CVSROOT=:pserver:cvs@pserver.samba.org:/cvsroot
Cette première commande règle la variable d'environnement CVSROOT. Si vous ne
le faites pas, il faudra faire suivre, à chaque fois, la commande
Voici les commandes utiles pour récupérer une copie à jour des sources de développement. Vous pouvez sauter le panneau suivant pour lire l'explication de ces commandes, et revenir ensuite :
# cvs login (Logging in to cvs@pserver.samba.org) CVS password:(Tapez le mot de passe ici.) # cvs -z5 co samba U samba/COPYING U samba/Manifest U samba/README U samba/Read-Manifest-Now U samba/Roadmap U samba/WHATSNEW.txt(C'est juste une partie de la sortie complète de la commande cvs co output.)
La première commande cvs (ci-dessus) nous connecte au pserver et la seconde demande à notre client de faire un « checkout » (« co ») du module samba en utilisant une compression de type gzip de niveau 5 (« -z5 ») pour accélérer la transmission sur une connexion lente. Pour chaque nouveau fichier créé localement, cvs affiche « U [fichier] », ce qui indique que ce fichier a bien été mis à jour sur le disque (« Updated »).
Une fois le « checkout » terminé, vous aurez un répertoire « samba » dans votre répertoire courant. Remarquez d'ailleurs que chaque répertoire contient un nouveau répertoire « cvs » - CVS y stocke plusieurs informations qui peuvent être ignorées sans problème ici. À partir de maintenant, nous n'avons plus à nous inquiéter que la variable CVSROOT soit réglée ou non, parce que les informations sur le dépôt sont stockées dans ces fameux répertoires « cvs » supplémentaires. À savoir : CVSROOT n'est à définir que pour la première connexion et le premier « checkout ».
Quand vous en êtes là, vos sources sont récentes. Vous pouvez les compiler et les installer, les parcourir et en faire tout ce que vous voulez.
De temps en temps, vous pouvez avoir envie de synchroniser vos sources déjà récupérées avec la version actuelle sur CVS. Pour ce faire, vous n'avez pas besoin de vous connecter à nouveau au pserver; vos informations d'authentification sont mises en cache par cvs dans les répertoires « CVS » dont j'ai parlé. Il suffit d'entrer dans le répertoire principal des sources (dans notre cas « samba ») et de taper :
# cvs update -dP
S'il y a des nouveaux fichiers, cvs va afficher une ligne « U [fichier] » pour chaque fichier qu'il met à jour. Si vous avez déjà compilé les sources une fois, vous allez sans doute voir apparaître beaucoup de lignes « ? [fichier] » ; c'est parce que cvs signale qu'ils ne sont pas sur le dépôt distant.
Remarquez d'ailleurs les deux options utilisées pour faire un « cvs update ». « -d » demande à cvs de créer chez vous les nouveaux répertoires qui ont pu être ajoutés au dépôt (ce qui n'est pas le comportement par défaut), et « -P » sert à supprimer tous les répertoires vides de votre copie locale des sources. « -P » est une bonne idée puisque cvs a tendance à récupérer un bon nombre de répertoires vides (utilisés à une époque, puis abandonnés).
Lorsqu'il s'agit juste de récupérer les sources les plus récentes, c'est à peu près tout ce qu'il suffit de savoir sur cvs. La suite concerne plutôt les développeurs.
En tant que développeur, vous devrez modifier des fichiers sur le serveur CVS. Pour ceci, commencez par faire les changements désirés sur votre copie du dépôt. Ces changements ne se répercutent pas, bien entendu, sur le dépôt distant tant que vous n'avez pas explicitement demandé à cvs de faire un « commit » de vos modifications. Lorsque vous avez suffisamment testé toutes vos modifications, que vous êtes sûr que tout fonctionne parfaitement, alors vous êtes prêt à envoyer vos modifications sur le dépôt distant. Suivez bien les deux étapes. En premier lieu, mettez vos sources à jour, par la commande suivante :
# cvs update -dP
Comme on l'a vu plus tôt, « cvs update » va synchroniser vos sources avec celles du dépôt distant. Mais que va-t-il se passer pour vos modifications ? Rassurez-vous, elles ne seront pas perdues ! Si un autre développeur a modifié un fichier que vous n'avez pas modifié, votre fichier local sera mis à jour, et ainsi, tous les fichiers que vous n'aurez pas touchés seront synchronisés avec les fichiers du dépôt CVS.
De plus, si vous avez modifié localement les lignes 1 à 10 d'un fichier, et qu'un autre développeur a supprimé les lignes 40 à 50, ajouté 12 lignes à la fin de ce fichier, puis réalisé un « commit » avant vous, alors cvs va réaliser une fusion intelligente des modifications réalisées par l'autre développeur sur votre copie, et ainsi, aucun travail n'est perdu. Cela permet à deux développeurs de travailler sur des parties distinctes d'un même fichier en même temps.
Pourtant, si deux développeurs ou plus ont fait des modifications sur la même partie du même fichier, alors les choses se compliquent un tout petit peu. Si cela arrive, alors cvs va vous prévenir qu'il y a un conflit. Aucun travail n'est perdu, mais une intervention de votre part va être requise. En effet, cvs a besoin que vous lui indiquiez comment fusionner les changements.
Nous allons nous intéresser à la résolution des conflits un peu plus loin. Mais pour l'instant, supposons qu'il n'y a pas eu de conflit à la sortie de la commande « cvs update -dP » (ce qui est souvent le cas). Dans ce cas, vos sources locales sont à jour (« up-to-date ») et vous êtes alors prêt à réaliser le « commit » de vos sources. Il suffit de taper la commande suivante dans le répertoire principal de vos sources :
# cvs commit
« cvs commit » ne fait pas qu'appliquer vos modifications sur le dépôt distant. Avant de vraiment envoyer vos sources, cvs va ouvrir votre éditeur par défaut pour que vous puissiez écrire une courte description des changements réalisés. Une fois ce commentaire saisi, enregistrez le fichier et quittez l'éditeur. Vos changements (et les commentaires associés) vont être appliqués au dépôt distant et vont être disponibles pour les autres développeurs de l'équipe.
Il est vraiment très facile de consulter l'historique complet d'un fichier donné avec tous les commentaires que les développeurs (dont vous) ont pu faire lorsqu'ils ont fait des « commit ». Pour accéder à ces informations, faites :
# cvs log myfile.c
« cvs log » est une commande récursive, donc pour consulter le log complet de toute une arborescence d'un répertoire, allez dans le répertoire en question, et tapez :
# cvs log | less
Vous pourriez avoir envie d'utiliser un autre éditeur que celui que cvs utilise par défaut lorsque vous faites un « cvs commit ». Si c'est le cas, réglez la variable d'environnement EDITOR sur le nom de votre éditeur favori. Mettre une telle ligne dans votre ~/.bashrc peut être une bonne idée :
export EDITOR=jpico
Vous pouvez aussi spécifier le commentaire dans la ligne de commande de sorte que cvs n'ait pas à ouvrir un éditeur de texte :
# cvs commit -m 'Ceci doit être un commentaire intelligent'
Avant de continuer de découvrir d'autres commandes cvs, je vous recommande de créer un fichier ~/.cvsrc. En le créant dans votre répertoire personnel, vous pouvez dire à cvs d'utiliser des options par défaut pour chaque commande cvs, et ainsi, vous n'avez pas à vous rappeler de les taper à chaque fois. Voici un exemple de fichier .cvsrc :
cvs -q diff -u -b -B checkout -P update -d -P
En plus de pouvoir spécifier plusieurs options utiles pour un grand nombre de commandes cvs, la première ligne du .cvsrc force le mode silencieux de cvs, ce qui a comme première conséquence de rendre la sortie de « cvs update » beaucoup plus concise et lisible. Une fois ce fichier en place, il vous suffit de taper « cvs update » au lieu de « cvs update -dP » (par exemple).
Il est vraiment facile d'ajouter un fichier source au CVS. En premier lieu, vous devez créer le fichier en question, puis, tapez la commande suivante :
# cvs add myfile.c cvs server: use 'cvs commit' to add this file permanently
Ceci va dire à cvs d'ajouter ce fichier au dépôt la prochaine fois que vous ferez un « cvs commit ». Jusqu'à ce moment, les autres développeurs ne pourront pas le voir.
Pour ajouter un répertoire, la procédure est similaire :
# mkdir foo # cvs add foo Directory /home/cvsroot/mycode/foo added to the repository
À la différence d'un ajout de fichier, lorsque vous ajoutez un répertoire, il apparaît immédiatement dans le dépôt, le « commit » n'est pas requis. Une fois le répertoire local ajouté au dépôt, vous allez remarquer qu'un répertoire « cvs » y est créé pour y stocker les informations CVS. Ainsi, vous pouvez facilement savoir si un répertoire a été ajouté à cvs en regardant s'il contient un répertoire « CVS ».
Comme vous pouvez le deviner, avant d'ajouter un fichier ou un répertoire au dépôt, vous devez bien vérifier que son répertoire parent lui a déjà été ajouté. Sinon, vous aurez l'erreur suivante :
# cvs add myfile.c cvs add: cannot open CVS/Entries for reading: No such file or directory cvs [add aborted]: no repository
Avant de s'occuper de la résolution des conflits, familiarisons-nous avec les sorties de la commande « cvs update ». Si vous créez un fichier ~/.cvsrc qui contient la ligne « cvs -q », vous allez trouver les sorties de « cvs update » beaucoup plus faciles à lire. « cvs update » vous informe de ce qu'il fait, représentant ses actions par un caractère, un espace et un nom de fichier. Par exemple :
# cvs update -dP ? distfiles ? packages ? profiles
« cvs update » utilise le caractère « ? » pour vous signifier qu'il ne sait rien sur les fichiers qu'il retrouve dans votre copie locale mais pas sur le dépôt. Ces fichiers ne font pas partie du dépôt distant, et n'ont pas non plus été prévus pour être ajoutés au dépôt. Voici une liste de tous les messages possibles que CVS utilise :
U [path]
Utilisé lorsqu'un fichier est créé dans votre copie locale, ou si un fichier que vous n'avez pas touché est mis à jour.
A [path]
L'ajout de ce fichier au dépôt a été programmé et sera officiellement ajouté quand vous ferez un « cvs commit ».
R [path]
À l'image de « A », « R » vous indique que la suppression de ce fichier a été prévue. Ce fichier sera effectivement retiré dès que vous aurez fait un « cvs commit ».
M [path]
Cela signifie que ce fichier a été modifié par vous. Il est possible que des modifications aient été fusionnées dans ce fichier sans conflit.
C [path]
Le caractère « C » indique que ce fichier présente des conflits et nécessite une intervention manuelle avant de réaliser votre « commit ».
Désormais, occupons-nous de résoudre ces conflits. Je suis assez impliqué dans le projet Gentoo-Linux et nous avons notre propre serveur cvs configuré sur cvs.gentoo.org. Nous autres, développeurs, passons la majorité de notre temps à hacker les sources du module « gentoo-x86 » et nous avons ajouté un fichier appelé « ChangeLog » qui contient (vous l'aurez deviné) les modifications majeures que nous avons faites sur le dépôt.
Puisque ce ficher est modifié à peu près à chaque fois qu'un changement majeur est réalisé sur CVS, c'est notre plus grande source de conflits. En voici un exemple. Imaginons que j'ai ajouté les lignes suivantes au début du fichier de ChangeLog :
date 25 Feb 2001 J'ai ajouté ce commentaire
Imaginons qu'avant que je ne fasse un « commit » de ces trois nouvelles lignes, un développeur avait déja ajouté les lignes suivantes au début du Changelog et envoyé ses modifications :
date 25 Feb 2001 Un autre développeur a ajouté ce commentaire
Maintenant, lorsque je fais un « cvs update -dP » (comme il faut le faire avant chaque commit), cvs n'est pas capable de fusionner ces modifications sur ma copie locale du ChangeLog parce que nous avons tous les deux ajouté des lignes dans la même partie du fichier. CVS ne sait alors pas quelle partie utiliser. Ainsi, j'ai l'erreur suivante :
RCS file: /home/cvsroot/gentoo-x86/ChangeLog,v retrieving revision 1.362 retrieving revision 1.363 Merging differences between 1.362 and 1.363 into ChangeLog rcsmerge: warning: conflicts during merge cvs server: conflicts found in ChangeLog C ChangeLog
Ahhh, un conflit ! Heureusement, résoudre un conflit est facile. Si je lance mon éditeur favori, je vois le texte suivant au début du fichier « ChangeLog » :
<<<<<<< ChangeLog date 25 Feb 2001 J'ai ajouté ce commentaire ======= date 25 Feb 2001 Un autre développeur a ajouté ce commentaire >>>>>>> 1.363
Au lieu de choisir une version ou l'autre, cvs ajoute les deux versions au fichier ChangeLog et les entoure de caractères spéciaux pour marquer clairement les régions qui posent problème. Maintenant, c'est à moi de remplacer ces régions par les textes qui devraient apparaître dans le ChangeLog; dans ce cas, le texte de remplacement n'est ni l'une, ni l'autre des versions, mais une combinaison des deux :
date 25 Feb 2001 J'ai ajouté ce commentaire Un autre développeur a ajouté ce commentaire
Maintenant que j'ai remplacé les régions conflictuelles du fichier avec le texte approprié (et supprimé les « ======= » et autres marqueurs), je peux faire un « commit » sans aucun problème.
À chaque fois que vous avez besoin d'éditer un fichier pour régler des conflits, vérifiez que vous avez bien parcouru tout le fichier de telle manière que vous n'ayez rien oublié. Sinon, cvs n'autorisera pas votre « commit » et ce jusqu'à ce que le conflit soit résolu. Il est donc très important d'enlever les marqueurs spéciaux que cvs a ajoutés aux fichiers conflictuels. Autre astuce : si vous avez fait une erreur en essayant de résoudre un conflit et que vous avez accidentellement enregistré vos modifications, vous pouvez retrouver la copie originale du fichier dans le fichier « .#nom_du_fichier.version ».
Maintenant, il est temps de découvrir notre dernière commande cvs : supprimer un fichier du dépôt. Supprimer un fichier se fait en deux étapes. Il faut commencer par supprimer le fichier de votre copie des sources, puis exécuter la commande « cvs remove » sur ce fichier :
# rm myoldfile.c # cvs remove myoldfile.c
La suppression du fichier est alors prévue par cvs et sera effective lors de votre prochain « commit ». Une fois le « commit » réalisé, le fichier sera officiellement supprimé du dépôt distant. Pourtant, cvs ne va pas faire disparaître ce fichier et va garder un enregistrement complet de son contenu et de son historique au cas où vous en auriez besoin dans le futur. C'est juste un des nombreux moyens utilisés par cvs pour protéger votre code.
« cvs remove » est récursif, ce qui signifie que vous pouvez supprimer un ensemble de fichiers et lancer la commande « cvs remove » sans autre argument depuis un répertoire parent. Ceci va marquer tous les fichiers supprimés comme « à supprimer » lors du prochain « commit ».
Si vous voulez supprimer un répertoire complet, je vous recommande la méthode suivante. Tout d'abord, supprimez chaque fichier du répertoire et faites un « cvs remove » :
# rm *.c # cvs remove
Ensuite, faites un « commit » :
# cvs commit
Et là, astuce : exécutez les commandes suivantes pour supprimer le répertoire :
# cd .. # cvs remove mydir # rm -rf mydir
Remarquez que supprimer un répertoire ne nécessite pas un autre « commit ». L'ajout et la suppression de répertoires sur le dépôt distant se font en temps réel.
Votre introduction à CVS est terminée. J'espère que ce tutoriel vous a été utile. Il y a bien d'autres choses à savoir sur CVS, que je n'ai pu couvrir dans cette introduction, mais heureusement, la volumineuse documentation disponible vous aidera à étendre vos connaissances sur CVS :
La version originale de cet article a été publiée sur le site developerWorks d'IBM et est la propriété de Westtech Information Services. Ce document est une mise à jour de l'article original et contient diverses améliorations faites par l'équipe de documentation de Gentoo.