FLASH INFORMATIQUE FI



CVS sur redhat




Xavier BARMAZ


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 :

  • 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

Ainsi, parmi les valeurs possibles de la variable CVSROOT, celles-ci sont correctes :

export CVSROOT = /cvs
export CVSROOT =:ext:cvs_user@192.168.1.7:/cvs

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 :

cvs -d /cvs checkout module
cvs -d:ext:cvs_user@192.168.1.7:/cvs commit

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

Qu’est-ce ?

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.

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...]

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

Ce type de module permet de définir un nouveau module qui référencera plusieurs répertoires du repository.

nom_module [options] &module1...

Exclure un répertoire d’un module

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.

!repertoire

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.

Droits d’accès

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 :

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 :

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:[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:cvs_user@192.168.1.7:/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:cvs_user@192.168.1.7:/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 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:cvs_user@192.168.1.7:/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:cvs_user@192.168.1.7:/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:cvs_user@192.168.1.7:/cvs login

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.

cvs - d:pserver:cvs_user@192.168.1.7:/cvs logout

cvs checkout

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.

cvs -d:ext:cvs_user@192.168.1.7:/cvs checkout module1

cvs import

Avant de pouvoir effectuer une récupération d’un module du CVS par la commande cvs checkout, il faut bien évidemment 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:cvs_user@192.168.1.7:/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:cvs_user@192.168.1.7:/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:cvs_user@192.168.1.7:/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:cvs_user@192.168.1.7:/cvs log src/Makefile

cvs add et cvs remove

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 -d:ext:cvs_user@192.168.1.7:/cvs add src/test.c

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:cvs_user@192.168.1.7:/cvs remove src/test.c

cvs rtag

Lorsque le développement d’un module arrive à un niveau exploitable comme la sortie d’une nouvelle version 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:cvs_user@192.168.1.7:/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:cvs_user@192.168.1.7:/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:cvs_user@192.168.1.7:/cvs update module1

cvs release

IIl 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.

cvs -d:ext:cvs_user@192.168.1.7:/cvs release module1

cvs diff

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:cvs_user@192.168.1.7:/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.

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

IVérifions que cette ligne xinitd startup succeeded apparaisse :

cat /var/log/messages

</code
<p class="text" align="justify">IEn tant que root, vérifions que {{LISTEN}} apparaisse dans la ligne suivante:
</p><code>
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 :

export CVS_RSH=ssh
</code
<p class="text" align="justify">Cela aura pour effet que le client CVS devra se connecter en ext. S'il configure sa variable d'environnement CVSROOT, ça donnera:
</p><code>
export CVSROOT=":ext: cvs_user@192.168.1.7:/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 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

/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é.

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/) est un client open-source 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 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.

Références



Cherchez ...

- dans tous les Flash informatique
(entre 1986 et 2001: seulement sur les titres et auteurs)
- par mot-clé

Avertissement

Cette page est un article d'une publication de l'EPFL.
Le contenu et certains liens ne sont peut-être plus d'actualité.

Responsabilité

Les articles n'engagent que leurs auteurs, sauf ceux qui concernent de façon évidente des prestations officielles (sous la responsabilité du DIT ou d'autres entités). Toute reproduction, même partielle, n'est autorisée qu'avec l'accord de la rédaction et des auteurs.


Archives sur clé USB

Le Flash informatique ne paraîtra plus. Le dernier numéro est daté de décembre 2013.

Taguage des articles

Depuis 2010, pour aider le lecteur, les articles sont taggués:
  •   tout public
    que vous soyiez utilisateur occasionnel du PC familial, ou bien simplement propriétaire d'un iPhone, lisez l'article marqué tout public, vous y apprendrez plein de choses qui vous permettront de mieux appréhender ces technologies qui envahissent votre quotidien
  •   public averti
    l'article parle de concepts techniques, mais à la portée de toute personne intéressée par les dessous des nouvelles technologies
  •   expert
    le sujet abordé n'intéresse que peu de lecteurs, mais ceux-là seront ravis d'approfondir un thème, d'en savoir plus sur un nouveau langage.