Introduction
Cette note contient les informations minimales pour créer un référentiel CVS, ajouter, détruire ou modifier des fichiers, obtenir l'historique des modifications et extraire une version du référentiel. Il n'est pas exhaustif.CVS : pourquoi gérer des versions
Développer un projet qui incorpore plusieurs fichiers se révelle rapidement problématique au fur et à mesure où ce nombre de fichiers différents augmente, ou si plusieurs intervenants participent à ce projet. CVS permet d'avoir une gestion cohérente du projet, de pouvoir extraire une version donnée à jour tout en économisant l'espace disque puisque l'on peut gérer l'avancée du projet par deltas.CVS est en développement depuis 1986 (créé par Dick Grune).
Premier contact
Les exemples donnés ci-dessous ont été faits sous linux en ksh et fonctionnent dans le cas du développement sur une même machine. Il est possible de faire ses développements en réseau, et dans ce cas il faudra en plus instancier une variable CVS_RSH=ssh par exemple (et donner les droits nécessaires).|
TEST CVS >cvs Usage: cvs [cvs-options] command [command-options-and-arguments] where cvs-options are -q, -n, etc. (specify --help-options for a list of options) where command is add, admin, etc. (specify --help-commands for a list of commands or --help-synonyms for a list of command synonyms) where command-options-and-arguments depend on the specific command (specify -H followed by a command name for command-specific help) Specify --help to receive this message The Concurrent Versions System (CVS) is a tool for version control. For CVS updates and additional information, see the CVS home page at http://www.cvshome.org/ or Pascal Molli's CVS site at http://www.loria.fr/~molli/cvs-index.html TEST CVS > TEST CVS >whereis cvs cvs: /usr/bin/cvs /usr/share/cvs /usr/share/man/man5/cvs.5.gz /usr/share/man/man1/cvs.1.gz TEST CVS > |
|
Les fichiers du projets sont déposés sous le répertoire : /ref/essai/mes_fics Nous allons d'abord créer un répertoire pour le dépôt dans CVS : $CVSROOT/cvs_essai, puis lancer la commande d'initialisation du dépôt CVS. |
|
TEST CVS >export CVSEDITOR=/bin/vi #ou n'importe quel autre éditeur TEST CVS >export CVSROOT=/ref/ TEST CVS >mkdir $CVSROOT/CVSROOT TEST CVS >ls $CVSROOT CVSROOT essai TEST CVS >cd $CVSROOT TEST CVS >cvs init TEST CVS >ls $CVSROOT/CVSROOT Emptydir commitinfo,v cvswrappers,v loginfo notify taginfo verifymsg,v checkoutlist config editinfo loginfo,v notify,v taginfo,v checkoutlist,v config,v editinfo,v modules rcsinfo val-tags commitinfo cvswrappers history modules,v rcsinfo,v verifymsg |
|
La variable CVSROOT peut contenir plus d'informations sous la forme :user@nom-reseau:repertoire Les fichiers du projets vont être déclarés dans CVS (dans un répertoire $CVS_ROOT/cvs_essai que nos avons préalablement créé). Pour faire l'import, il faut d'abord se placer dans le répertoire où sont les fichiers à déclarer dans CVS (CVS balaie tous les répertoires à partir de là où vous êtes). |
|
TEST CVS >ls -l essai/mes_fics total 0 -rw-r--r-- 1 ref_do do 0 Nov 7 15:53 fic1.ksh -rw-r--r-- 1 ref_do do 0 Nov 7 15:53 fic2.ksh TEST CVS >cd essai/mes_fics |
|
On va ensuite lancer la commande d'import dans CVS |
|
TEST CVS >cvs import -m "Commentaire sur mon projet" $CVSROOT/cvs_essai mes_fics initial |
|
Ca y est, la première version des fichiers est entrée dans CVS. |
Gérer les modifications
La première version a été crée. Un nouveau développeur va intervenir sur le projet :Il lui faudra rappatrier les fichiers dans un répertoire à lui (/tmp dans l'exemple ci-dessus), faire les modifications nécessaires puis insérer ces modifications versionnées dans le référentiel CVS.
La première action va consister à faire une copie du référentiel en se plaçant dans /tmp.
|
TEST CVS > cvs checkout cvs_essai cvs checkout: Updating cvs_essai/mes_fics U cvs_essai/mes_fics/fic1.ksh U cvs_essai/mes_fics/fic2.ksh |
|
Pour l'exemple, on modifie le fichier fic1.ksh, puis on va demander à CVS de figer cette modification (commit). |
|
TEST CVS >cvs commit fic1.ksh CVS: ---------------------------------------------------------------------- CVS: Enter Log. Lines beginning with `CVS:' are removed automatically CVS: CVS: Modified Files: CVS: fic1.ksh CVS: ---------------------------------------------------------------------- Modification de Ph.R. sur le fichier fic1.ksh Checking in fic1.ksh;312C written /ref_do/cvs_essai/mes_fics/fic1.ksh,v <-- fic1.ksh new revision: 1.2; previous revision: 1.1 done |
|
Le fait de ne pas donner de nom de fichier (on a passé ici fic1.ksh), va obliger CVS à examiner tous les fichiers connus pour voir s'ils ont été modifiés. Par ailleurs, pour éviter d'ajouter à chaque fois un label expliquant les modifications effectuées, il est possible de le renseigner pour tous les fichiers en utilisant l'option -m : cvs commit -m "Label des modifications effectuées" Si entre temps, un autre utilisateur a fait une mise à jour, CVS va indiquer qu'il y a un conflit. Il est possible d'ajouter un nouveau fichier (ou d'un retirer un). Après avoir créé nouveau.ksh, on tape les commandes de mise à jour |
|
TEST CVS >cvs add -m "nouveau fichier" nouveau.ksh TEST CVS >cvs commit TEST CVS >cvs remove nouveau.ksh TEST CVS >cvs commit |
Le suivi des modifications
Développer et historiser est une chose, mais l'important pour le chef de projet est de pouvoir avoir une vision globale de l'avancée du projet.|
L'historique des modifications est récupérable par l'argument log de CVS. |
|
TEST CVS >cvs log cvs log: Logging . RCS file: /ref/cvs_essai/mes_fics/fic1.ksh,v Working file: fic1.ksh head: 1.2 branch: locks: strict access list: symbolic names: initial: 1.1.1.1 mes_fics: 1.1.1 keyword substitution: kv total revisions: 3; selected revisions: 3 description: ---------------------------- revision 1.2 date: 2005/11/08 10:42:53; author: PRI; state: Exp; lines: +1 -0 Modification de Ph.R. sur le fichier fic1.ksh ---------------------------- revision 1.1 date: 2005/11/07 16:07:42; author: PRI; state: Exp; branches: 1.1.1; Initial revision ---------------------------- revision 1.1.1.1 date: 2005/11/07 16:07:42; author: PRI; state: Exp; lines: +0 -0 Commentaire sur mon projet ============================================================================= RCS file: /ref_do/cvs_essai/mes_fics/fic2.ksh,v Working file: fic2.ksh head: 1.1 branch: 1.1.1 locks: strict access list: symbolic names: initial: 1.1.1.1 mes_fics: 1.1.1 keyword substitution: kv total revisions: 2; selected revisions: 2 description: ---------------------------- revision 1.1 date: 2005/11/07 16:07:42; author: PRI; state: Exp; branches: 1.1.1; Initial revision ---------------------------- revision 1.1.1.1 date: 2005/11/07 16:07:42; author: PRI; state: Exp; lines: +0 -0 Commentaire sur mon projet ============================================================================= RCS file: /ref_do/cvs_essai/mes_fics/Attic/nouveau.ksh,v Working file: nouveau.ksh head: 1.2 branch: locks: strict access list: symbolic names: keyword substitution: kv total revisions: 2; selected revisions: 2 description: nouveau ---------------------------- revision 1.2 date: 2005/11/08 11:10:32; author: PRI; state: dead; lines: +0 -0 plus de fichier nouveau.ksh ---------------------------- revision 1.1 date: 2005/11/08 10:57:35; author: PRI; state: Exp; deuxieme modif |
|
On voit sur cette exemple qu'il est important de se mettre d'accord sur une normalisation des commentaires pour un meilleur suivi du projet. Il peut être également nécessaire de filtrer l'affichage en indiquant une date, un fichier, auteur. |
|
TEST CVS >cvs log -d ">2005-11-30" nouveau.ksh TEST CVS >cvs log -wPRI |
L'extraction d'une version
Pour extraire une version et en faire un livrable, il va falloir la marquer, puis l'extraire.|
TEST CVS >cd $CVSROOT cvs rtag "LivrableV1" cvs_essai TEST CVS >cd /repertoire_extraction cvs export -r "LivrableV1" cvs_essai |
|
Le répertoire /repertoire_extraction/cvs_essai contient une version complète de tous les fichiers marqués "LivrableV1" et débarrassée des fichiers de gestion de CVS (les ",v"). Elle peut être empaquetée pour être déployée. Une fois posé, un tag peut être réutilisé pour les commandes comme "cvs update -r LivrableV1" par exemple. |
Conclusions sur CVS
CVS offre des fonctionnalités simples qui permettent de gérer a minima l'évolution d'un projet après une prise en main d'une journée.Le logiciel mériterait cependant d'être plus intégré, en particulier sur le fait que certaines variables d'environnement sont importantes et peuvent empêcher le bon fonctionnent (un calcul de statut élémentaire et clair ne serait pas de trop) et plus encore, que les commandes fonctionnent parfois selon un positionnement absolu et parfois selon un positionnement relatif ; un contrôle minimum permettrait d'éviter quelques problèmes (un cvs init ou checkout mal placé par exemple).
Pour plus d'informations, je vous conseille les deux sites de référence suivant : Les informations fournies sont généralement claires, mais lorsque l'on part de zéro, j'ai du mal à comprendre pourquoi les rédacteurs ne présentent pas les commandes qu'il faut impérativement passer dans l'ordre où on doit les passer...