CVS sur redhat - Flash informatique

CVS sur redhat
Xavier.Barmaz@epfl.ch, EPFL - SV-IT
Partager
des informations est la base même
d’une communauté d’utilisateurs.
Lors de développement en particulier, il est de rigueur de
pouvoir travailler à plusieurs sur le même module. Or,
lorsque le nombre de personnes excède le seuil critique de
deux, il devient vite difficile de gérer le projet car chacun
peut facilement, par exemple, remplacer une version récente
par une plus ancienne. De plus, le chef de projet se trouve
plus occupé à gérer la synchronisation des travaux de chacun
plutôt que de s’investir dans ces occupations de gestion. A cela
s’ajoutent aussi les problèmes de répartition géographique.
Dès lors, il devient indispensable de faire usage d’un outil
spécialisé appelé CVS.
CVS signifie Concurrent Versions System. Il s’agit d’un
logiciel fonctionnant sur le principe client-serveur et permettant de gérer efficacement des fichiers ou plus exactement
toutes les versions du même fichier modifié au fil du temps.
On peut alors, en toute simplicité, retrouver d’anciennes
versions de fichiers, consulter l’historique des modifications,
bref, garder une trace de tout le vécu du projet.
CVS est un système habituellement utilisé pour maintenir
et gérer des fichiers sources. Mais il peut également convenir
pour tout autre élément ayant les mêmes besoins de gestion
(fichiers HTML, documentation, répertoire téléphonique,
etc.). Il peut être utilisé de manière locale ou via un réseau.
Ce dernier point est très important car il permet de s’acquitter
du problème géographique cité plus haut.
Prérequis
Le serveur CVS fut initialement créé pour tourner sur
des systèmes de type Unix/Linux. Il existe aussi des versions
pour Windows et Macintosh. Toutefois, nous allons nous
en tenir à des explications pour un serveur CVS sur une
version Advanced Server de Red Hat ainsi qu’à l’utilisation
côté client. Lors d’une installation de base de la distribution
Red Hat AS, le serveur CVS est déjà installé. Reste donc
à le configurer. Voyons donc, dans un premier temps, la
configuration matérielle requise ainsi que les concepts de base
de CVS. Finalement, nous illustrerons la configuration du
serveur Red Hat par le biais d’un exemple pratique.
Remarque: Les informations sur les commandes clientes
(checkout, commit, ...) utilisées se trouvent dans la section
Commandes de l’article.
Configuration matérielle
CVS est peu gourmand en terme de puissance de calcul
du serveur, n’importe quelle machine courante peut faire l’affaire. Veillons toutefois à respecter les spécificités matérielles
requises par le système d’exploitation.
Au niveau disque, il est prudent de disposer pour le repository d’environ 3 fois le volume de la totalité des fichiers
qui y seront stockés. Cette taille peut s’avérer à terme trop
limitée si les modifications sont nombreuses, mais il s’agit
d’un bon départ.
Concernant la mémoire, trois facteurs entrent en jeu:
❚ t: taille du plus gros fichier géré par CVS
❚ v: volume total du plus gros checkout (recupère une copie
locale d'un module du repository)
❚ n: nombre maximum de checkout simultanés
Le besoin maximal de mémoire peut alors être estimé
par la formule:
10 * t + n * max(2 Mo, v)
Cette mémoire peut être constituée en majorité de mémoire virtuelle, CVS n’ayant besoin que de peu de mémoire
physique pour fonctionner, la valeur fournie pour la formule
précédente doit donc servir à dimensionner le swap de la
machine. Une machine Unix équipée de 32 Mo de mémoire
centrale peut gérer un gros repository avec un nombre conséquent d’utilisateurs.
Prenons maintenant quelques minutes pour acquérir le
vocabulaire et les concepts liés à CVS.
Repository
Qu’est-ce?
Le repository, ou dépôt en français, correspond au répertoire distribué dans lequel sont stockés tous les fichiers et
répertoires sous le contrôle de CVS. Il contient entre autres
tous les modules, tous les historiques de fichiers ainsi que
tous les fichiers d’administration qui ont été développés avec
le logiciel CVS.
Le repository peut être considéré comme un système de
fichiers distribués à part entière: il fournit aux clients qui en
ont l’accès les modules de développement et les sources dont
ils auront besoin pour travailler. Habituellement, le repository
n’est jamais directement accessible de la part des clients qui
vont plutôt utiliser leur client CVS pour récupérer en local
les modules du repository dont ils ont besoin. Ils récupèrent
ainsi une copie d’un module puis travaillent sur cette copie,
avant de mettre à jour le repository. Ce dernier contiendra
alors les nouveaux changements qui ont été effectués par
les clients.
Selon la façon dont on souhaite utiliser CVS, le repository
peut être installé directement chez le client, qui y aura ainsi
accès en local, ou bien quelque part dans le monde, auquel
cas le repository distant peut être contacté par une méthode
d’accès spécifique.
Localisation
Afin de pouvoir accéder au repository, qu’il soit local ou
distant, un client a besoin de spécifier plusieurs choses:
fi 7 – 14 septembre 2004 – page 3
CVS sur redhat
❚ la méthode d’authentification utilisée (local par défaut).
Nous utiliserons ssh pour plus de sécurité;
❚ le nom d’utilisateur du client (pas d’authentification par
défaut);
❚ l’adresse de la machine distante contenant le repository
(localhost par défaut);
❚ le répertoire (local ou distant) où se trouve le repository.
Ces informations sont stockées dans une variable d’environnement cliente appelée CVSROOT. Cette variable doit
respecter la syntaxe suivante:
methode_authentification:username@adresse:repertoire
Dans la définition du module, on peut également
spécifier uniquement la liste des fichiers du répertoire choisi
qui seront récupérés lors du checkout.
mon_module module1/src Makefile
Les modules de type alias
Un module de type alias -a représente un autre nom pour
un répertoire du repository.
nom_module -a repertoire
Les modules de type ampersand
Ainsi, parmi les valeurs possibles de la variable CVSROOT,
celles-ci sont correctes:
Ce type de module permet de définir un nouveau module
qui référencera plusieurs répertoires du repository.
export CVSROOT = /cvs
export CVSROOT =:ext:[email protected]:/cvs
nom_module [options] &module1...
On peut également spécifier à la commande CVS que l’on
souhaite utiliser une variable temporaire lors de l’appel de
la commande. La variable CVSROOT n’est plus utilisée et
il faut spécifier à chaque fois le répertoire du repository par
l’option -d. Cela se fait par la syntaxe suivante:
Exclure un répertoire d’un module
cvs -d /cvs checkout module
cvs -d:ext:[email protected]:/cvs commit
!repertoire
Lorsque l’on récupère une copie d’un module en local,
la variable CVSROOT utilisée pour réaliser le «checkout»
est sauvegardée au sein du fichier Root contenu dans les
répertoires CVS/ ajoutés par la commande dans chacun des
répertoires du module.
Administration serveur
Le répertoire CVSROOT (à ne pas confondre avec la
variable d’environnement cliente vue ci-dessus) du repository
contient plusieurs fichiers qui sont réservés pour effectuer
l’administration du serveur CVS. On peut ainsi définir les
modules qui seront offerts par le repository, spécifier des attributs et options sur les fichiers du repository ou encore ajouter
diverses actions à réaliser lors de commandes spécifiques par
le client. Passons en revue le fichier modules ainsi que les
fichiers des droits d’accès, de gestion des comptes et le fichier
.cvsignore. Il en existe bien évidemment d’autres.
Modules
Lors du checkout sur un module, le répertoire désigné
ainsi que tous ses sous-répertoires sont récupérés. Or, il est
possible d’interdire des répertoires dans la définition d’un
module.
Ainsi, pour définir un alias sur le répertoire module1 du
repository tout en excluant le répertoire src/cpp, il faut procéder comme suit:
mon_module -a !module1/src/cpp module1
Les options d’un module
On peut définir des options lors de la définition d’un
module. On peut notamment spécifier l’exécution de commandes ou de programmes lorsqu’une commande CVS est
exécutée:
-e progname: définit un programme qui sera exécuté lorsque
le module sera exporté.
-i progname: définit un programme qui sera exécuté lorsque
des fichiers du module seront mis à jour (commit).
-o progname: définit un programme qui sera exécuté lorsque
le module sera récupéré via un checkout.
-t progname: définit un programme qui sera exécuté lorsque
le module sera taggé.
-u progname: définit un programme qui sera exécuté lorsqu’un cvs update sera effectué sur le répertoire racine du
module en question.
Qu’est-ce?
Droits d’accès
Ce fichier définit toutes les associations de fichiers qui
représenteront les modules CVS. Il existe différents types
de modules suivant la désignation que nous souhaitons leur
donner. La différence entre les types de modules suivants
réside dans la manière dont ils organisent les fichiers et
répertoires qui les composent.
Lorsque l’on utilise une méthode d’authentification,
il est possible de définir une liste d’utilisateurs qui auront
uniquement le droit d’accès en lecture sur le repository. Pour
cela, il y a deux moyens d’y parvenir:
Les modules réguliers
Un module régulier est la façon la plus simple de désigner
un module CVS. Il définit simplement que tel répertoire dans
le repository CVS aura tel nom pour module.
nom_module [options] repertoire [fichiers...]
fi 7 – 14 septembre 2004 – page 4
Le fichier readers
L’ensemble des utilisateurs qui seront stockés dans ce
fichier auront uniquement accès au repository en lecture. Ils
pourront ainsi uniquement réaliser les opérations clientes
CVS en lecture (checkout, status, log), mais pas en écriture
(commit, add, ...). La syntaxe de ce fichier est la suivante:
CVS sur redhat
cat /cvs/CVSROOT/readers
utilisateur1
utilisateur2
...
utilisateurN
Le fichier writers
L’ensemble des utilisateurs qui seront stockés dans ce
fichier auront un accès au repository en écriture. Ce qui implique que tous les autres utilisateurs n’auront qu’un accès
en lecture sur ce repository. La syntaxe de ce fichier est la
même que le fichier readers. Si les deux fichiers readers et
writers existent, alors le fichier readers est traité en priorité,
c’est à dire que:
❚ si l’utilisateur apparaît dans readers, il aura un accès en
lecture uniquement;
❚ sinon et s’il n’apparaît pas dans writers, il aura également
un accès en lecture uniquement;
❚ sinon,s’il n’apparaît pas dans readers mais dans writers,
il aura un accès en lecture et écriture.
Gestion des comptes
Ce sujet, très lié au point précédent, concerne les comptes
linux et CVS.
La vérification des comptes lors d’une authentification
peut se faire de deux manières: soit via les comptes systèmes,
soit via les comptes CVS du fichier passwd qui se trouve
dans le répertoire CVSROOT directement sous chaque
repository.
Pour désactiver l’utilisation des comptes système il faut
éditer le fichier config du répertoire CVSROOT et changer
la valeur de SystemAuth à no. Si la valeur vaut yes, alors
CVS recherchera l’utilisateur qui souhaite se loguer parmi la
liste des utilisateurs systèmes, si celui-ci n’apparaît pas dans
le fichier passwd du répertoire CVSROOT.
Chaque ligne du fichier passwd, qu’il faut créer, répond
à la syntaxe suivante:
login_CVS:[mot_de_passe_crypt][:login_systeme]
❚
❚
login_CVS: le login utilisé par le client CVS
mot_de_passe_crypt: le mot de passe chiffré
avec la
commande crypt. Si ce champ est omis, tous les mots
de passe seront acceptés sans vérification
❚ login_systeme: l’utilisateur système utilisé par CVS
pour accéder au repository. Si ce champ est omis, l’utilisateur système utilisé sera celui indiqué par le champ
login_CVS.
CVS ne fournit pas d’outil permettant à un utilisateur de
modifier son mot de passe.
Fichier .cvsignore
Le fichier .cvsignore, dernier fichier d’administration
traité dans cet article, définit une liste de fichiers qui seront
ignorés par les commandes CVS. Cette liste peut contenir des
noms de fichiers complets ou des expressions régulières.
cvsignore du repository
Ce fichier permet de définir des fichiers qui seront ignorés
dans tout le repository sans exceptions.
.cvsignore du répertoire HOME
L’utilisateur peut également définir sa propre liste de
fichiers ignorés, tout simplement en les ajoutant dans le
fichier .cvsignore de son répertoire home.
Méthodes d’authentification
CVS permet d’utiliser sa propre méthode d’authentification
pour se connecter au repository distant. Suivant la rapidité
d’exécution ou la sécurité que nous souhaitons obtenir, une
méthode d’authentification sera préférée à une autre. Il est
également possible de se connecter au même repository avec
des méthodes d’authentifications différentes. Personnellement, nous avons opté pour la méthode ssh qui paraît être
la plus sûre et la plus appropriée. Détaillons ces différentes
méthodes.
Variable CVS_RSH
CVS utilise par défaut le logiciel rsh pour effectuer les
commandes à distance vers le repository. C’est le cas lors d’une
authentification par pserver (login/mot de passe) ou kserver
(Kerberos). ssh, quant à lui, offre la plus grande sécurité et
correspond à un protocole rsh sécurisé par cryptage RSA.
Le protocole de communication utilisé par CVS est spécifié
dans la variable d’environnement CVS_RSH.
export CVS_RSH=ssh
La méthode pserver
Il s’agit de la méthode d’authentification la plus simple.
Elle s’effectue tout simplement par login et mot de passe
suivant le protocole rsh. Son gros avantage est la rapidité
d’exécution du serveur, qui n’a à crypter aucune donnée
puisque que toutes celles-ci circuleront en clair sur le réseau,
y compris le mot de passe lors de l’authentification. Son
inconvénient est donc le fait que la communication ne soit
aucunement sécurisée.
cvs -d:pserver:[email protected]:/cvs checkout module1
Notons au passage l’utilisation de l’option «-d» pour
indiquer le chemin du repository sans devoir valoriser au
préalable la variable CVSROOT.
La méthode kserver
Cette méthode s’appuie sur l’utilisation de Kerberos, qui
est un protocole d’authentification réseau créé par le MIT
et qui utilise la cryptographie des clés au lieu des mots de
passe en texte clair. Kerberos renforce la sécurité du système
et empêche que des personnes non autorisées interceptent
les mots de passe des utilisateurs.
cvs -d:kserver:[email protected]:/cvs checkout module1
La méthode GSSAPI
Cette méthode s’appuie sur l’utilisation d’une interface
générique aux systèmes de sécurisation des réseaux. Il est ainsi
fi 7 – 14 septembre 2004 – page 5
CVS sur redhat
possible d’utiliser une connexion TCP/IP banale en tant que
protocole de communication avec CVS, mais d’utiliser une
méthode d’authentification sécurisée via GSSAPI. Il faut
que le logiciel CVS ait été compilé avec le support GSSAPI
pour pouvoir l’utiliser. Par défaut, GSSAPI authentifie la
connexion, mais pas les données qui circuleront par cette
connexion, auquel cas il faut utiliser l’option -a.
cvs -d:gserver:[email protected]:/cvs checkout module1
La méthode External Protocol
Cette méthode, que nous avons utilisée, s’appuie sur un
logiciel externe pour réaliser la connexion et l’authentification
de celle-ci. Le cas le plus courant est d’utiliser un serveur SSH
pour effectuer le cryptage des données que vont s’échanger
le client et le serveur CVS. N’importe quel autre logiciel de
sécurisation peut être spécifié via la variable CVS_RSH.
cvs -d:ext:[email protected]:/cvs checkout
module1
Commandes
Pour mieux comprendre le fonctionnement de CVS, il
convient de signaler une série de commandes qui permettent
au client d’interagir avec le serveur. A l’heure actuelle, bon
nombre d’outils graphiques rendent ces dernières transparentes, toutefois l’appréhension des commandes améliore
notre compréhension des processus. Les utilisateurs de linux
ou macintosh en mode terminal apprécieront.
cvs login
La commande «cvs login» permet, comme son nom l’indique, de se connecter à un repository. Cette commande n’est
utilisée que dans le cas d’une méthode d’authentification
de type pserver afin de s’authentifier une seule et unique
fois auprès du serveur.
cvs -d:pserver:[email protected]:/cvs login
ment que ce module ait été intégré dans le repository distant.
Ceci se fait par la commande cvs import. Lors de l’appel de
cette commande, il faut préciser quelques informations nécessaires, comme un commentaire précédé de l’option «-m»,
le nom du répertoire où créer le module, le nom du module
que possèdera ce nouvel import et son tag actuel.
cvs -d:ext:[email protected]:/cvs import -m
"Ma version 1" monprojet demoi starter
cvs commit
La commande «cvs commit» permet aux développeurs
de valider les changements qu’ils ont effectués auprès de leur
copie locale d’un module, récupéré avec la commande cvs
checkout. Lors du cvs commit, le logiciel cvs demande généralement à l’utilisateur de rentrer un texte de log qui permettra à l’administrateur et aux autres développeurs de prendre
connaissance des modifications effectuées par ce commit.
L’option -m permet de le faire en ligne de commande.
cvs -d:ext:[email protected]:/cvs commit
cvs status et cvs log
cvs status permet de consulter le statut de la copie locale
d’un fichier. Ainsi, si la copie est à jour par rapport à celle du
repository, CVS retrounera un message Up-to-date.
cvs -d:ext:[email protected]:/cvs status
src/Makefile
cvs log permet de consulter tout ou une partie des opérations
réalisées sur le fichier en question (opération de commit
principalement), ainsi que des informations sur ce fichier
(version, branche,...). Il est ainsi possible de voir les dernières personnes qui ont contribuées aux modifications de ce
fichier, ainsi que les textes de log qu’ils ont apportés sur ces
modifications.
cvs -d:ext:[email protected]:/cvs log src/
Makefile
cvs add et cvs remove
cvs - d:pserver:[email protected]:/cvs logout
Lorsque un nouveau fichier est créé par le développeur
dans sa copie locale, il faut savoir qu’il ne sera pas traité par
CVS ni ajouté dans le repository tant que l’ordre n’aura pas
été donné. La commande cvs add permet d’indiquer à CVS
qu’un nouveau fichier a été créé et qu’il doit maintenant
être traité comme un fichier du repository. Cependant, la
commande cvs add n’ajoute pas encore le fichier dans le
repository, l’envoi de données se fera uniquement au prochain
cvs commit.
cvs checkout
cvs -d:ext:[email protected]:/cvs add src/
test.c
La commande cvs checkout permet de récupérer une
copie locale d’un module du repository. En effet, les développeurs ne doivent JAMAIS travailler directement sur le
repository, mais en récupérer une copie locale chez eux. Ils
effectuent ensuite les modifications sur cette copie, puis valident leurs modifications avec la commande cvs commit.
De même, lorsque un fichier est supprimé de la copie
locale, il ne disparaît pas du repository distant. Il faut en
avertir CVS par la commande cvs remove. Une fois encore,
le fichier ne sera réellement supprimé que lors du prochain
cvs commit.
cvs -d:ext:[email protected]:/cvs checkout
module1
cvs -d:ext:[email protected]:/cvs remove
src/test.c
cvs import
cvs rtag
cvs logout
La commande «cvs logout» permet, comme son nom
l’indique, de se déconnecter d’un repository. Cette commande
n’est utilisée que dans le cas d’une méthode d’authentification
de type pserver.
Avant de pouvoir effectuer une récupération d’un module
du CVS par la commande cvs checkout, il faut bien évidemfi 7 – 14 septembre 2004 – page 6
Lorsque le développement d’un module arrive à un
niveau exploitable comme la sortie d’une nouvelle version
CVS sur redhat
d’un logiciel par exemple, il est utile de pouvoir garder un
repère dans le repository qui indiquera que l’état actuel des
fichiers sera considéré comme la version 1.2 du module par
exemple. Cela se fait avec la commande cvs rtag.
cvs -d:ext:[email protected]:/cvs rtag V1_2
module1
De plus, il est possible de créer de nouvelles branches d’un
module CVS. Une branche correspond à un nouveau stade
d’évolution du module. Par exemple, il est possible de créer
une branche d’un module pour implémenter les nouvelles
fonctionnalités de ce module, qui sortiront dans la version
suivante; et une autre branche qui servira à débuguer la
version courante de ce module. Ceci se fait également par la
commande cvs rtag.
cvs -d:ext:[email protected]:/cvs rtag -b -r
V1_0 V1_0_DEBUGGAGE
cvs update
Lorsque qu’un module est récupéré du repository via
la commande cvs checkout et que des modifications sont
effectuées sur la copie locale, il peut se passer beaucoup de
temps jusqu’au prochain cvs commit. CVS étant utilisé
pour du travail collaboratif sur un même module, il se peut
qu’entre-temps, un autre développeur ait déjà effectué des
modifications sur le repository par un commit. Il faut donc,
avant d’effectuer la validation des modifications, rapatrier
la nouvelle version du fichier modifié, et effectuer la fusion
des deux versions.
cvs -d:ext:[email protected]:/cvs update
module1
cvs release
Il est possible de vouloir supprimer la copie locale d’un
module du repository pour, par exemple, récupérer de la
place sur le disque dur. Or, il est nécessaire de vérifier, avant
de supprimer la copie locale, que toutes les modifications
ont bien été apportée et validée sur le repository par un cvs
commit. C’est le but de la commande cvs release.
Configuration serveur
Tout d’abord, il faut préparer le serveur à gérer les
demandes CVS. Cela se fait par le biais du super démon
xinetd.d. Créons le fichier:
cd /etc/xinetd.d
nano cvspserver
Editons le fichier et valorisons le service:
# description: cvspserver
service cvspserver {
socket_type = stream
protocol
= tcp
wait
= no
user
= root
passenv
= PATH
server
= /usr/bin/cvs
server_args
= -f --allow-root=/cvs pserver
disable
= no
}
Il est possible d’autoriser l’accès à plusieurs repositories,
il suffit pour cela de répéter autant de fois que nécessaire
l’option --allow-root. Vérifions que la ligne cvspserver 2401/
tcp dans le fichier /etc/services existe. Autrement, l’ajouter.
Redémarrer le démon:
/etc/init.d/xinetd stop
/etc/init.d/xinetd start
Vérifions que cette ligne xinitd startup succeeded apparaisse:
cat /var/log/messages
En tant que root, vérifions que LISTEN apparaisse dans la
ligne suivante:
netstat -nlpd | grep 2401
Authentification ssh
Le serveur ssh doit être configuré. Nous n’entrerons pas
dans ces détails. Il est nécessaire de préciser au préalable
la méthode d’authentification Client-Serveur. Dans notre
cas, nous utilisons ssh, si bien qu’il faut valoriser la variable
d’environnement suivante:
cvs -d:ext:[email protected]:/cvs release
module1
export CVS_RSH=ssh
cvs diff
Cela aura pour effet que le client CVS devra se connecter en
ext. S’il configure sa variable d’environnement CVSROOT,
ça donnera:
Une autre des fonctionnalités importantes de CVS est de
pouvoir comparer deux versions d’un même fichier. Ceci est
utile quand, par exemple, dans une version, un bug est apparu
alors qu’il n’y était pas dans la version précédente. Il suffit
donc de comparer les deux versions de ce fichier pour afficher
la liste des modifications qui ont été effectuées, et ainsi retrouver très facilement d’où vient le bug en question.
cvs -d:ext:[email protected]:/cvs diff -r
V1_0 -r V1_2
Best Practice
Nous voilà donc parés pour illustrer, par un exemple
concret, la mise en place du serveur, ainsi que la gestion
succincte des comptes et des droits.
export CVSROOT=":ext: [email protected]:/cvs
Nous avons choisi de réaliser une authentification ssh par mot
de passe et non pas par clé via la cryptographie asymétrique.
Cela signifie que si c’est la première connexion du client vers
le serveur CVS, le serveur demande au client si le fingerprint
de la clé publique présentée est bien le bon. En répondant
oui, la clé publique du serveur est alors rajoutée au fichier
~/.ssh/known_hosts ou à un équivalent.
Comptes
Nous n’avons pas utilisé le fichier passwd du repository
mais travaillé uniquement avec les comptes systèmes.
La première étape à réaliser est de créer un nouvel utilisateur Unix qui sera considéré comme l’Administrateur
CVS pour ce repository, ainsi qu’un groupe qui représentera
fi 7 – 14 septembre 2004 – page 7
CVS sur redhat
l’ensemble des utilisateurs ayant accès à ce repository, utilisateurs
préalablement créés au niveau du système.
useradd cvsadmin
Pour ajouter un utilisateur à un groupe, il suffit d’éditer le fichier
/etc/group et de rajouter l’utilisateur au bout de la ligne en séparant
le nom des membres par une virgule.
nom_de_groupe: champ_special: numero_de_groupe: membre1, membre2
Repository
Lors de l’installation d’un serveur CVS, il faut dédier une zone
de son disque dur, typiquement un répertoire, qui représentera le
repository, contenant tous les modules qui seront importés dans
CVS. Donc, une fois les droits d’écriture donnés aux utilisateurs et
groupes, il faut initialiser le repository. Cela se fait tout simplement
par la commande init de CVS.
cvs -d /cvs init
Cette commande créera une entrée CVSROOT sous le répertoire
du repository /cvs. Ce CVSROOT, comme vu plus haut, contient
entre autre les fichiers d’administration du serveur CVS.
Attention: il faut être logué en tant qu’Administrateur CVS de
ce repository pour faire la commande d’initialisation, sinon les
fichiers créés n’auront pas les droits voulus.
Droits
Une fois le repository créé, il faut encore accorder les droits et
permissions au groupe sur le repository.
cd /cvs
chgrp -R groupname .
chmod ug+rwx . CVSROOT
permet, comme tout client, de rapidement vérifier
l’état des fichiers et répertoires.
Autre
TkCVS (http://www.twobarleycorns.net/tkcvs.
html) est une interface graphique basée Tcl/Tk. Il
affiche le statut des fichiers dans le répertoire courant
et fournit des boutons et des menus pour exécuter
les commandes CVS sur les fichiers sélectionnés.
TkDiff est inclus pour visualiser les changements
qui ont eu lieu. L’avantage principal de ce logiciel est
qu’il fonctionne sur Unix, Windows et MacOSX.
Pour Windows, il faut cependant obtenir la version
PC de Diff.
CvsGui (http://cvsgui.sourceforge.net/) est un ensemble de clients CVS écrit en C++ avec une licence
GPL. Ce site contient de multiples informations sur
différents autres clients.
Conclusion
Comme nous l’avons montré, l’installation du
serveur CVS se fait très facilement. Toutefois, pour
l’administrer finement au niveau des droits, des comptes, des accès et des fichiers d’administration, il faut
encore acquérir de nombreux concepts. En effet, la
gestion détaillée d’un tel serveur demande de longues
heures de pratique et de planification, mais le jeu en
vaut largement la chandelle ainsi qu’un gain de temps
incomparable pour les projets communs à venir.
/cvs représente ici le répertoire d’entrée pour le repository. Ces
commandes sont indicatives, et chaque administrateur devra gérer
sa propre stratégie d’accès. Voilà, désormais le développeur n’a plus
qu’à se mettre au travail en utilisant son client CVS préféré.
Références
Clients CVS
❚
Nous n’avons pas testé pleinement tous les clients suivants, mais
leurs spécificités semblent indiquer que toutes les fonctionnalités
CVS sont intégrées.
Windows
TortoiseCVS (http://www.tortoisecvs.org/) semble être le client
le plus approprié et facile d’utilisation pour Windows. Un simple
clic droit de souris permet d’agir sur les fichiers et répertoires locaux
ainsi que sur ceux du repository définis au préalable dans la variable
CVSROOT des préférences du programme.
Linux
Cervisia (http://www.kde.org/apps/cervisia/) est un client opensource graphique pour KDE. Mais la plupart du temps il convient
d’utiliser le terminal en ligne de commande pour récupérer et
modifier des projets.
Macintosh
CVL (http://www.sente.ch/software/cvl/) pour Concurrent Versions Librarian. Il s’agit d’une interface graphique pour CVS. Il
fi 7 – 14 septembre 2004 – page 8
❚
❚
❚
❚
❚
❚
❚
❚
❚
❚
❚
https://www.cvshome.org/
http://www.lifl.fr/~boulet/formation/syst-dist/exposes2003-2004/cvs/index.html
h t t p : / / c o a c h i n g . e p f l . c h / I N / i n d e x.
php?content=cvs
http://www.uta.edu/oit/how-to/docs/cvs.php
http://www.int-evry.fr/mci/user/procacci/cvs/
cvs001.html
http://www.fr.linuxfromscratch.org/view/blfs-1.0fr/server/cvsserver.html
http://www.alianwebserver.com/informatique/
linux/cvs.htm
http://www.opikanoba.org/n/?2003/11/24/6-configuration-du-serveur-cvs-sous-linux
http://www.idealx.org/doc/cvs.fr.html
http://ricky81.developpez.com/tutoriel/cvs/introduction/
http://okki666.free.fr/docmaster/articles/
linux102.html
http://linux.ensimag.fr/cvs.html ■