Configurer et accéder au CVS depuis une machine

Configurer et accéder au CVS depuis
une machine Linux
Projet Noeud de Calcul
Revision 0.4
Julien Cuvillier ([email protected])
08 Mars 2002
Table des matières
Introduction
1
2
3
4
5
3
CVS, vous avez dit CVS ?
1.1 Introduction au CVS . . . . . . . . . . . . . . . . . . . . . .
1.2 Schéma typique de l’utilisation de CVS . . . . . . . . . . . .
1.3 Pourquoi est il important d’effectuer régulierement l’opération
commit ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
. .
. .
de
. .
Installation des Outils
2.1 Installation de CVS . . . . . . . . . . . .
2.2 Installation de SSH (Optionnel) . . . . . .
2.3 Installation de Cervisia (Optionnel) . . . .
2.4 Préparation des variables d’environnement
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
Utilisation du client CVS
3.1 Utilisation en mode utilisateur . . . . . . . . . . . . . . . .
3.1.1 Récupérer une copie de travail . . . . . . . . . . . .
3.1.2 Modification des fichiers et répercution sur le serveur
3.2 Utilisation en mode anonyme . . . . . . . . . . . . . . . . .
3.2.1 Récupérer une copie de travail . . . . . . . . . . . .
Quelques commandes de base CVS
4.1 Ajouter un nouveau fichier . . . . . . . . . . . . .
4.2 Ajouter un nouveau sous-répertoire . . . . . . . . .
4.3 Supprimer un fichier . . . . . . . . . . . . . . . .
4.4 Supprimer un sous-repertoire . . . . . . . . . . . .
4.5 Ajouter ou enlever le mode read-only sur un fichier
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
5
.
.
.
.
6
6
7
7
8
.
.
.
.
.
9
9
9
11
12
12
.
.
.
.
.
13
13
14
14
15
15
Pour aller plus loin
5.1 Utilisation d’une clé publique pour l’authentification automatique
avec SSH . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1 Génération de la paire de clés privée/publique . . . . . . .
5.1.2 Upload de la clé publique sur le serveur . . . . . . . . . .
5.1.3 Derniers réglages et test . . . . . . . . . . . . . . . . . .
1
4
4
5
16
16
17
17
18
TABLE DES MATIÈRES
5.2
Utilisation du frontend Cervisia . . . . . . . . . . . . . . . . . . .
2
19
Introduction
Ce document vise à permettre l’accès au CVS distant pour la récupération et la
mise à jour du code source du projet Noeud de Calcul. Le serveur CVS est implanté
définitivement sur un serveur du département Informatique de l’Université Laval,
néanmoins ce document est appelé à être révisé régulièrement ;)
Vous pouvez consulter les documents qui dont je me suis inspiré comme ce miniguide d’utilisation de CVS[1] ou ce document sur l’administration d’un serveur
CVS[2]. Ce dernier document[3] traite de la mise en place d’un serveur CVS totalement sécurisé.
Outils utilisés (version) :
– Linux (Debian 3.0)
– CVS (CVS 1.11.1p1-3)
– SSH (optionnel) (SSH 3.0.2p1-4)
– Cervisia (optionnel) (Cervisia 1.0)
3
Chapitre 1
CVS, vous avez dit CVS ?
1.1 Introduction au CVS
Le Concurrent Versions System pourrait se résumer comme suit : “Une caractéristique de cvs repose sur le fait de permettre à chaque développeur de travailler
dans son propre répertoire. Que ce dernier se trouve sur la même machine que le
référentiel ou en réseau, cvs se charge de fusionner le travail « réparti » dans un
référentiel commun, auquel chacun peut à tout moment se reporter.”
En clair, CVS permet de gérer un dossier commun (le Repository) à tous les développeurs qui pourront, à tout moment et quelle que soit la machine sur laquelle ils
travaillent, récupérer le code source et y répercuter de manière quasi-transparente
les modifications qu’ils y ont apporté. Chaque développeur récupere donc une copie des fichiers contenus dans le repository dans son propre répertoire de travail
(Working Directory) et peut y apporter des modifications indépendamment des
autres développeurs. Lorsqu’il decide d’effectuer une mise à jour, le serveur CVS
fusionne les fichiers modifiés avec ceux du repository et dès lors, chaque développeur à accès à la nouvelle version du projet. C’est bien plus efficace que les
disquettes ou les courriels avec des commentaires du style : “T’as touché a quoi ?
Pourquoi ca marche pas ? ! ! ?”
Dans notre cas, nous allons utiliser un repository situé sur un serveur distant accessible via Internet en mode anonyme (read-only) ou utilisateur (via SSH). La
suite du document va décrire comment configurer un client CVS pour récuperer un
exemple de projet et y effectuer des modifications par lignes de commandes ou par
l’intermédiaire du frontend Cervisia.
4
1.2. SCHÉMA TYPIQUE DE L’UTILISATION DE CVS
1.2 Schéma typique de l’utilisation de CVS
Une fois la phase d’installation et de configuration terminée, l’utilisation de
CVS se résume en trois étapes majeures :
– Récuperation de la dernière version du repository (checkout)
– Modification du code source et/ou autres documents
– Répercution des modifications sur le serveur (commit)
1.3 Pourquoi est il important d’effectuer régulierement
l’opération de commit ?
Etant donné que plusieurs développeurs ont accès au même repository, il est
important d’effectuer un commit aussi souvent que possible, c’est à dire lorsque
les modifications sur un fichier sont terminées et que l’on s’est assuré que ces modifications n’altèrent pas le fonctionnement global du projet. Si vous ne répercutez
pas vos modifications régulierement, il est probable qu’un autre développeur modifie à son tour l’ancienne version du fichier, ce qui entrainera à coup sûr des conflits
et des pertes de données lors de la fusion sur le serveur.
5
Chapitre 2
Installation des Outils
2.1 Installation de CVS
L’installation du client CVS est relativement simple.
Les utilisateurs chanceux d’une Debian n’auront qu’a éxécuter en tant que root la
commande :
apt-get install cvs
Les utilisateurs de “RedHat-like” (RedHat, Mandrake, Suze ...) ont de fortes chances
que le client CVS soit deja présent sur leur machine. Dans le cas contraire, le problème sera réglé par la commande (en tant que root) :
rpm -i ‘‘paquetage-cvs.rpm’’
Le RPM peut être trouvé sur le CD de la distribution ou sur tout site Internet fournissant ce genre de service [4].
Si votre distribution l’exige (Slackware) ou que vous vous en sentez le courage,
vous pouvez toujours utiliser directement les sources de CVS et les compiler vous
même en suivant les indications fournies [5].
Il n’existe pas a ma connaissance de configuration particulière, mais je peux me
tromper ;)
Dans ce cas, cette section sera mise à jour.
6
2.2. INSTALLATION DE SSH (OPTIONNEL)
2.2 Installation de SSH (Optionnel)
Cette étape n’est pas obligatoire si vous utilisez le CVS en mode anonyme mais
vous aurez besoin de SSH pour y accéder en mode utilisateur et effectuer des mises
à jour (commit).
Comme précédemment, je ne pense pas que SSH nécessite une configuration particulière.
L’installation ne devrait donc pas poser de problèmes :
apt-get install ssh (Debian)
rpm -i “paquetage-ssh.rpm” (RedHat-like)
Les sources sont également disponibles[6].
2.3 Installation de Cervisia (Optionnel)
Cervisia est un frontend graphique utilisant les librairies de KDE et qui est très
efficace si vous n’êtes pas trop à l’aise avec les lignes de commandes.
Cet outil est disponible en paquetages RPM et DEB.
Les sources[7] et la documentation[8] sont également disponibles.
Pour rédiger ce mini-guide, j’ai utilisé la version 1.0 de Cervisia mais la version
stable la plus récente est la 1.4 qui apporte apparemment plusieurs améliorations.
7
2.4. PRÉPARATION DES VARIABLES D’ENVIRONNEMENT
2.4 Préparation des variables d’environnement
Cette phase peut être optionnelle, néanmoins, même s’il est possible de les surcharger par des options sur la ligne de commandes, les variables d’environnement
sont souvent appréciables.
Editer le fichier .bashrc de votre répertoire personnel et y ajouter les lignes suivantes :
Pour une utilisation anonyme :
export CVSROOT=:pserver:[email protected]:/usr/local/cvs/pnc
Pour une utilisation en tant qu’utilisateur :
export [email protected]:/usr/local/cvs/pnc
export CVS_RSH=ssh
La ligne “export CVSROOT” indique sur quelle machine se trouve le repository.
Dans notre cas, il s’agit d’une machine du département, accessible via Internet :
w4.ift.ulaval.ca
La partie “username@” représente l’utilisateur qui va tenter de s’identifier sur le
serveur lors de la connection au serveur cvs.
Il s’agit du login que vous utilisez dans les laboratoires.
/usr/local/cvs/pnc est le répertoire servant de repository sur le serveur, il est fourni
par la personne administrant le serveur CVS.
La ligne “export CVS_RSH” indique la méthode de communication entre le client
et le serveur.
Pour plus de securite, nous utilisons ici SSH en cas de connection “utilisateur”.
Le fichier .bashrc est chargé à chaque ouverture de session. Pour forcer Linux à
le recharger, utilisez depuis votre repertoire personnel la commande :
source .bashrc
8
Chapitre 3
Utilisation du client CVS
3.1 Utilisation en mode utilisateur
Le mode utilisateur sera le plus utilisé si vous accédez au CVS depuis votre
machine habituelle. Il permet toutes les opérations de lecture/écriture mais nécessite l’intervention de SSH pour sécuriser les transactions
3.1.1 Récupérer une copie de travail
Créer un répertoire de travail dans votre répertoire personnel :
mkdir jini_cvs
Puis se placer dans ce répertoire et demander une copie de travail :
cvs co startup chat util
Ou si les vous n’avez pas fixé de variables d’environnement :
cvs [email protected]:/usr/local/cvs/pnc co startup chat util
“startup”, “chat” et “util” représentent des sous-répertoires du repository aussi
appelés “modules”. Sur la ligne de commandes, “co” permet de spécifier quels modules récupérer et il suffit alors d’entrer le nom des modules désirés les uns derrière
les autres.
Note : toutes les sources du projet Noeud de Calcul sont dans le module “pnc”
9
3.1. UTILISATION EN MODE UTILISATEUR
Si c’est la première fois que vous utilisez CVS depuis votre machine actuelle,
SSH va demander une confirmation pour la clé de cryptage par un message du
type :
The authenticity of host ’ift-linux2.ift.ulaval.ca (132.203.26.72)’ can’t
RSA1 key fingerprint is b5:5d:49:11:40:2f:1d:cf:c7:67:53:fd:8b:ce:e4:d2.
Are you sure you want to continue connecting (yes/no)?
Il faut bien sûr repondre YES, ce message ne devrait plus apparaitre à la prochaine connection puisqu’il s’agit de l’enregistrement d’une “empreinte” du serveur sur votre machine cliente. L’empreinte du serveur est théoriquement invariable, si elle change d’une connection à l’autre, la transaction n’est plus considérée comme sécurisée.
Si tout se passe bien, le serveur va maintenant réclamer un mot de passe pour
l’utilisateur courant.
Il s’agit du mot de passe Linux et courriel associé à votre login.
Etant donné que votre répertoire est supposé être vide, CVS devrait récupérer l’integralité du repository et en faire une copie dans votre répertoire de travail en y
créant la même arborescence.
Si vous effectuez cette commande pour vérifier une éventuelle mise à jour du projet, tout fonctionne de la même manière mais la différence vient du fait que vous
n’allez pas forcément télécharger l’ensemble du projet.
CVS va cette fois examiner votre working directory, le comparer avec le repository
et ne récuperer que les fichiers dont le numéro de version est supérieur au votre.
Ceci permet d’obtenir rapidement une copie de travail à jour du projet, surtout si
celui ci est volumineux.
10
3.1. UTILISATION EN MODE UTILISATEUR
3.1.2 Modification des fichiers et répercution sur le serveur
Pour un bon fonctionnement de CVS, il ne faut pas modifier l’arborescence
dans votre working directory.
Pour chaque modification effectuée sur un ou plusieurs fichiers, nous allons répercuter les changements sur le serveur (après s’être replacé à la racine du répertoire
jini_cvs) par la commande :
cvs commit -m ‘‘Modif du 26/01’’
L’option “-m” permet de spécifier une courte description de la modification
realisée. Ce paramètre est optionnel mais si il est omis, CVS affichera un message
du type :
Log message unchanged or not specified
a)bort, c)ontinue, e)dit, !)reuse this message unchanged for remaining di
Ce message réclame en fait la description de la modification et peut être contourné
en appuyant sur C. Donc pour être tranquille, il est recommandé d’utiliser l’option
“-m”.
Le serveur CVS va maintenant fusionner les fichiers contenus dans le repository
avec ceux de votre working directory qui ont subit une modification.
Si tout se passe bien, vous devriez obtenir un message du type :
Checking in japster/LisezMoi;
/var/lib/cvs/japster/LisezMoi,v <-- LisezMoi
new revision: 1.3; previous revision: 1.2
done
Le numéro de version est géré automatiquement par le serveur, il est incrementé à chaque mise a jour d’un fichier.
11
3.2. UTILISATION EN MODE ANONYME
3.2 Utilisation en mode anonyme
Le mode anonyme est très pratique car a peu près n’importe qui peut accéder
au CVS sans avoir de compte sur le serveur et ainsi récupérer le code source d’un
projet.
Cette méthode est également pratique pour récupérer rapidement un projet depuis
une machine qui n’est pas équipée de SSH ou pour ne pas se soucier des mots de
passe.
Mais l’utilisation du mode anonyme s’en tient la puisqu’il sera impossible d’effectuer un commit de cette facon, l’accès étant restreint en “read-only” au niveau du
serveur.
3.2.1 Récupérer une copie de travail
Cette méthode ne requiert aucun mot de passe ni le protocole SSH.
Néanmoins, elle ne permet que l’accès en lecture seule, ce qui n’est donc pas suffisant pour travailler directement sur le projet.
Créer un répertoire de travail dans votre répertoire personnel :
mkdir jini_cvs
Puis se placer dans ce répertoire et demander une copie de travail :
cvs co startup chat util
Ou si vous n’avez pas fixé de variables d’environnements :
cvs -d:pserver:[email protected]:/usr/local/cvs/pnc co startup chat ut
“startup”, “chat” et “util” représentent des sous-répertoires du repository aussi
appelés “modules”. Sur la ligne de commandes, “co” permet de spécifier quels modules récupérer et il suffit alors d’entrer le nom des modules désirés les uns derrière
les autres.
Note : toutes les sources du projet Noeud de Calcul sont dans le module “pnc”
12
Chapitre 4
Quelques commandes de base
CVS
Nous avons vu jusqu’ici les deux commandes les plus basiques : checkout (co)
et commit
Les choses deviennent un peu plus délicates lorsqu’il s’agit d’ajouter ou de supprimer des fichiers, voire des répertoires entiers.
Nous allons donc voir comment fonctionnent quelques commandes simples pour
pouvoir s’en sortir dans la majorité des cas.
4.1 Ajouter un nouveau fichier
Imaginons que vous venez de créer une nouvelle classe pour le projet.
Placez vous dans le sous répertoire de votre working directory contenant cette
classe puis tapez la commande :
cvs add nom_fichier
En effectuant cette opération, le fichier voulu sera marqué comme devant être
ajouté lors du prochain “commit”. Pour réellement ajouter votre fichier dans le
repository, il faut donc effectuer un commit.
Si vous êtes correctement placé dans le répertoire contenant le fichier à ajouter, il
sera créé la où il faut dans le repository.
13
4.2. AJOUTER UN NOUVEAU SOUS-RÉPERTOIRE
4.2 Ajouter un nouveau sous-répertoire
Imaginons que vous venez de créer un nouveau package pour le projet.
Supposons que ce package est représenté par le répertoire pnc/zorglub.
Placez vous dans le répertoire pnc/zorglub et tapez la commande :
cvs import -m "Import du 08/03" pnc/zorglub vendortag releasetag
L’option “-m” n’est pas obligatoire mais à l’instar de la commande commit,
cvs va demander une description pour cette opération import.
“pnc/zorglub” représente l’emplacement du sous-répertoire qui sera créé sur le repository.
“vendortag” identifie la personne qui fait un import, vous pouvez mettre votre non
ou pseudonyme.
“releasetag” identifie l’objet de l’import, vous pouvez mettre le nom du sousrépertoire (ici zorglub).
4.3 Supprimer un fichier
Imaginons qu’une classe soit devenue inutile pour le projet.
Tout se déroule en se placant dans le sous-répertoire de votre working directory
contenant le fichier à supprimer.
Il faut tout d’abord supprimer le fichier de votre working directory par la commande :
rm nom_fichier
Il faut ensuite le supprimer du repository par la commande :
cvs delete nom_fichier
En effectuant cette opération, le fichier voulu sera marqué comme devant être
supprimé lors du prochain “commit”. Pour réellement supprimer votre fichier du
repository, il faut donc effectuer un commit.
14
4.4. SUPPRIMER UN SOUS-REPERTOIRE
4.4 Supprimer un sous-repertoire
Il n’y a pas à ma connaissance de moyen de supprimer directement un sousrépertoire du repository.
Pour ce faire, vous devez supprimer un à un tous les fichiers qu’il contient.
4.5 Ajouter ou enlever le mode read-only sur un fichier
Cette opération permet de marquer un fichier pour indiquer aux autres développeurs que vous êtes en train d’apporter des modifications à un fichier. Ce fichier
apparaitra alors en lecture seul aux autres développeurs.
La commande suivante est à effectuer depuis le sous répertoire de votre working directory contenant le fichier concerné :
cvs watch on nom_fichier
Pour retirer le “watch”, remplacez “on” par “off”.
15
Chapitre 5
Pour aller plus loin
5.1 Utilisation d’une clé publique pour l’authentification
automatique avec SSH
L’utilisation de SSH nécessite le mot de passe du compte UNIX utilisé lors de
la connection et ce pour chaque transaction entre le client et le serveur. Il existe
néanmoins un moyen de faire reconnaitre par le serveur votre machine pour un utilisateur donné. Cette méthode permet d’effectuer des transactions sans devoir saisir
votre mot de passe pour chacune d’elle mais nécessite l’emploi d’une clé RSA pour
l’authentification.
A noter que le protocole SSH existe en 2 versions. Le serveur actuel supporte la
version 2 du protocole mais afin de ne pas pénaliser les personnes qui utiliseraient
encore un client basé sur la version 1, nous allons forcer les transactions à utiliser
le protocole 1.
16
5.1. UTILISATION D’UNE CLÉ PUBLIQUE POUR L’AUTHENTIFICATION
AUTOMATIQUE AVEC SSH
5.1.1 Génération de la paire de clés privée/publique
Dans un premier temps, nous allons générer la paire de clés qui nous servira
pour l’authentification. Ces clés sont générées pour un utilisateur et une machine
donnée, vérifiez donc d’être loggé en tant que votre utilisateur courant et tapez la
commande :
ssh-keygen
Répondez aux questions posées en appuyant simplement sur ENTREE. La première permet de spécifier le nom des fichiers qui contiendront les clés (identity par
défaut), la deuxième et la troisième permettent de spécifier un mot de passe (passphrase), le but étant ici de ne plus être contraint d’entrer un mot de passe, nous
allons laisser ce champ vide ;)
Une fois ceci terminé, vous devriez avoir dans votre répertoire “$HOME/.ssh/”
2 fichiers correpondants à votre clé privée (identity) et votre clé publique (identity.pub). C’est cette dernière que nous allons uploader sur le serveur afin d’être
authentifié automatiquement.
5.1.2 Upload de la clé publique sur le serveur
La clé publique doit être stockée dans le répertoire personnel de l’utilisateur
accédant au CVS. Pour ce faire, utilisez la commande :
scp ~/.ssh/identity.pub [email protected]:~/.ssh/
Notez que pour effectuer cette commande, vous aurez encore besoin de saisir
votre mot de passe.
Connectons nous maintenant directement sur le serveur par la commande :
ssh [email protected]
Vous devriez vous trouver dans votre répertoire personnel à l’Université (le
serveur SSH réclame toujours un mot passe, c’est normal).
Placez vous dans le répertoire “.ssh” puis ajoutez votre clé publique à la liste des
clés autorisées à se connecter sans mot de passe par la commande :
cat identity.pub >> authorized_keys
Supprimez le fichier identity.pub (rm identity.pub) puis déconnectez vous (logout).
17
5.1. UTILISATION D’UNE CLÉ PUBLIQUE POUR L’AUTHENTIFICATION
AUTOMATIQUE AVEC SSH
5.1.3 Derniers réglages et test
Comme nous l’avons dit précédemment, nous allons forcer la transaction SSH
à s’effectuer par le protocole 1. Si votre client ne supporte que la version 1 du
protocole, cela ne fait aucune différence, il s’agit juste de s’assurer que l’authentification ne vous sera pas refusée à cause de ce détail.
Editez le fichier $HOME/.ssh/config et ajoutez (ou créez) la ligne “Protocol 1” sans
oublier un retour chariot.
Nous allons maintenant tenter une connection SSH pour tester l’authentification
par la commande :
ssh [email protected]
Si tout ce passe bien, le serveur SSH détecte que la demande de transaction
provient de votre machine, vérifie la clé publique de son fichier “authorized_keys”,
la compare avec votre propre clé privée restée sur votre machine et autorise la
connection sans demander de mot de passe.
En cas de problèmes, vérifiez les droits de votre répertoire personnel sur votre
machine et, au besoin, effectuez :
chmod -R 700 ~/
Vous pouvez également examiner la log de connection pour identifier le problème en tapant :
ssh -v [email protected]
Si tout ceci semble insurmontable, vous pouvez toujours génerer votre paire
de clés puis m’envoyer la partie publique (identity.pub) par courriel à l’adresse
[email protected]
ATTENTION ! ! La paire de clés RSA est à générer une bonne fois pour toute,
elle est valable pour votre utilisateur et votre machine mais les 2 parties sont indissociables. Si vous regénérez les clés après cette manipulation, la clé publique
présente sur le serveur ne sera plus valide et la connection ne sera plus authentifiée.
18
5.2. UTILISATION DU FRONTEND CERVISIA
5.2 Utilisation du frontend Cervisia
Cervisia est un frontend graphique qui utilise les lignes de commandes de la
même manière que ci dessus et qui permet de mieux visualiser les différentes opérations.
F IG . 5.1 – L’interface graphique de Cervisia
19
5.2. UTILISATION DU FRONTEND CERVISIA
Néanmoins, il est incapable de récupérer les prompts de demande de password
lors des connections SSH. Si vous désirez l’utiliser en mode utilisateur, vous devez être authentifié automatiquement par le serveur SSH (pas de demande de mot
de passe) et vous devez vous être assuré que l’empeinte du serveur a bien été enregistrée sur votre machine (Pour vous en assurer, effecuez une connection SSH
standard sur le serveur). Si la connection SSH qui est lancée en tâche de fond bute
sur une demande d’intervention de la part de l’utilisateur, cela fera geler Cervisia
(tout du moins la version 1.0).
Sélectionnez ensuite Repository/Repositories afin d’obtenir la fenêtre suivante :
F IG . 5.2 – La liste de tous les repositories configurés
20
5.2. UTILISATION DU FRONTEND CERVISIA
Ajoutez une entrée pour le Repository en cliquant sur ADD puis en renseignant les champs comme ci dessous (pour le mode anonyme, remplacez cvstest@...
par :pserver :cvs@... et supprimmez ssh) :
F IG . 5.3 – Ajout d’un repository
Pour récupérer le projet, sélectionnez Repository/Checkout et renseignez les
champs comme ci dessous (Les modules sont startup chat util pnc, le working
directory est celui de votre choix tant que vous avez le droit d’y écrire) :
F IG . 5.4 – Configurer Cervisia pour un checkout
21
5.2. UTILISATION DU FRONTEND CERVISIA
Si tout se passe bien, la fenêtre de résultat devrait ressembler à celle ci dessous :
F IG . 5.5 – Résultat d’un checkout
Pour pouvoir répercuter les changements sur le serveur (uniquement en mode
utilisateur), ouvrez votre working directory (File/Open Sandbox) de manière à voir
apparaitre l’arborescence dans la partie supérieure de Cervisia. Vous pouvez faire
un commit général par File/Commit ou faire un commit d’un fichier en particulier
en effectuant un clic droit sur le fichier concerné et en sélectionant Commit.
22
Bibliographie
[1] Utilisation de cvs : http ://www.idealx.org/fr/doc/cvs/cvs.html.
[2] Administration d’un serveur cvs :
http ://ftp.cvshome.org/cvs-1.11.1/cederqvist-1.11.1p1.pdf.
[3] Serveur cvs sécurisé :
http ://www.idealx.org/prj/idx-chrooted-ssh-cvs/dist/
chrooted-ssh-cvs-server.html.
[4] Paquetages rpm : http ://www.rpmfind.net.
[5] Site officiel de cvs : http ://www.cvshome.org.
[6] Site officiel de ssh : http ://www.openssh.com.
[7] Site officiel de cervisia : http ://cervisia.sourceforge.net.
[8] Documentation en ligne de cervisia :
http ://cervisia.sourceforge.net/documentation/gettingstarted.html.
23