Principe de fonctionnement et commandes essentielles de CVS

Transcription

1 Principe de fonctionnement et commandes essentielles de CVS I. Le Concept CVS : CVS est un outil de développement permettant le versionning. CVS va créer des versions au fur et à mesure du développement, joindre le travail réalisé par l'équipe, et prévenir d'éventuelles erreurs lors du rassemblement de travail. L intérêt est donc, pour tous les développeurs, de pouvoir gérer en même temps les différentes versions d un développement (ou de plusieurs). CVS groupe les sources en module*, conserve un historique de toutes les versions d un fichier, permet de Tagger une version, tout en permettant des accès concurrents au système. * Module = Les modules permettent de distinguer chaque développement spécifique. II.La mise en place : Après avoir installé selon sa distribution la package CVS, on doit créer le répertoire où seront stocké les développements, plus communément appelé le repository CVS : $ mkdir /var/cvs/cvroot $ cvs -d /var/cvs/cvsroot init La commande cvs init permet d initialiser le répertoire pour recevoir les sources des développements. Cette commande crée un répertoire CVSROOT qui contient les fichiers de configurations de CVS pour ce répertoire qui est : /var/cvs/cvsroot/cvsroot Accédez au repository CVS : Avant d importer un projet on va essayer de faire un checkout du nouveau répertoire CVSROOT nouvellement créé.

2 Il y a deux façons d accéder au CVS : Au niveau local (localhost) A distance (ssh, pserver, kserver, gserver) En local : $ cd /se/mettre/dans/un/répertoire $ cvs -d /var/cvs/cvsroot checkout CVSROOT Pour éviter de toujours spécifier l option -d /son/chemin, vous pouvez configurer une variables locale comme suit : $ export CVSROOT=/var/cvs/cvsroot Si l option -d n est pas spécifiée, et qu il n y a pas de variable locale CVSROOT, ce message d erreur apparaît : cvs checkout: No CVSROOT specified! Please use the `-d' option cvs [checkout aborted]: or set the CVSROOT environment variable. A distance : Pour accéder au repository à distance il existe plusieurs façons. La méthode pserver est la plus documentée. Ici seul la méthode SSH est traitée. Pré-requis : Un démon sshd sur le serveur hébergeant CVS Un compte permettant d'accéder au serveur grâce à ssh Un service CVS opérationnel On commence par exporter les variables : $ export [email protected]:/var/cvs/cvsroot $ export CVS_RSH=ssh Si la variable CVS_RSH n est pas renseignée, CVS va essayer de se connecter avec RSH, on peut obtenir le message suivant : connect to address port 544: No route to host Trying krb4 rsh... connect to address port 544: No route to host trying normal rsh (/usr/bin/rsh) : No route to host cvs [checkout aborted]: end of file from server (consult above messages if any)

3 Comme en local, il faut faire un checkout, sauf que le mot de passe de l utilisateur distant sera demandé : $ cd /se/mettre/dans/un/répertoire $ cvs checkout CVSROOT password: Il existe une solution pour ne pas renseigner son mot de passe à chaque commande : L échange de clé : L authentification avec une clé publique et privée : 1. Générer les clés : $ ssh-keygen -t dsa Generating DSA parameter and key. Enter file in which to save the key ($HOME/.ssh/id_dsa): Enter passphrase (empty for no passphrase): Enter same passphrase again: Your identification has been saved in $HOME/.ssh/id_dsa. Your public key has been saved in $HOME/.ssh/id_dsa.pub. The key fingerprint is: 13:7b:9f:4f:0c:9c:77:aa:8e:49:e5:11:c9:f9:09:74 user@server Pour une meilleure sécurité, il est conseillé de mettre une passphrase, il faudra alors à chaque commande donner sa passpharse. 2. Envoyer sa clé publique au serveur $ cat $HOME/.ssh/id_dsa.pub > authorized_keys $ scp $HOME/.ssh/authorized_keys userdistant@ipserveur:/home/userdistant/.ssh/ 3. Connexion Tester la connexion avec la commande : $ ssh -v userdistant@ipserveur Si vous rencontrez des problèmes vous pouvez arrêter le démon sshd et le lancer manuellement en mode verbose : # /usr/sbin/sshd -dd -e Une mauvaise configuration du fichier /etc/ssh/sshd_config peut en être l origine.

4 III.Utilisation : Avant toute chose, il convient d importer un projet sur le serveur afin de travailler dessus. $ cvs import nomprojet concepteur taginitial Maintenant que le projet est intégré à CVS, chaque utilisateur CVS peut travailler en suivant ces étapes : 1. Récupérer les sources avec un checkout $ cvs co nomprojet 2. Effectuer les modifications dans le projet $vi vosfichiers 3. Mettre à jour sa copie locale et tester les modifications $ cvs update nomprojet 4. Valider le travail $ cvs commit 5. Tagger la version Avec un TAG : Avec une BRANCHE : dans la branche courante $ cvs tag tag_name dans une autre branche $ cvs rtag -r branch_name tag_name uniquement les fichiers déjà taggés $ cvs rtag -r old_tag_name tag_name en vérifiant qu'aucun fichiers n'est modifiés localement $ cvs tag -c tag_name dans la branche courante $ cvs tag -b branch_name dans une autre branche $ cvs rtag -b -r branch_name new_branch_name passer dans cette branche $ cvs up -r branch_name

5 Autres commandes : Ajouter un fichier. Un "commit" est nécessaire pour le valider : $ cvs add nomfichier Retirer un fichier : $ cvs remove nomfichier Lister l'ensemble des modifications effectuées sur le fichier : $ cvs log nomfichier Mes problèmes lié à l accès CVS : 1. ACCES SSH Avec Fedora Core 4, mon fichier /etc/ssh/sshd_config n était pas configuré à l origine pour l authentification par clés. Ainsi il me demandait toujours mon password car il sautait l authentification par clé tout en offrant la clé au serveur. Il ne me demandait donc jamais ma passphrase (pour ceux qui en ont). Il faut décocher la ligne et la remplacer par #StrictModes Yes StrictModes no 2. CONNEXION CVS Toujours sous Fedora Core 4, j ai rencontré un problème lors de ma première connexion. Ce message d erreur était persistant : cvs [checkout aborted]: reading CVS/Tag: Not a directory Cette erreur s est résolue lorsque j ai importé un projet à distance : $ mkdir cvstest $ cvs import cvstest tagduprojet taginitial Pierre FAUQUEMBERGUE