Initiation `a CVS - Mon site SPIP

Transcription

Ecole Centrale Paris
LABORATOIRE de MECANIQUE
DES SOLS, STRUCTURES ET MATERIAUX
CNRS UMR 8579
Initiation à CVS
A.-S. Mouronval
Version destinée au groupe Oofe
Grande Voie des Vignes
92295 Châtenay-Malabry
Tél : +33 (0) 141 13 13 38
Fax : +33 (0) 141 13 14 30
http ://www.mssmat.ecp.fr
Décembre 2004
Table des matières
1
Avant-propos
3
2
Objectifs et déroulement du TP
3
3
CVS c’est quoi ?
3.1 Intêrets de CVS . . . . .
3.2 Un peu de vocabulaire ...
3.3 Les interfaces graphiques
3.4 Que lire ? . . . . . . . .
.
.
.
.
3
3
4
4
5
4
Avant de commencer les choses sérieuses ...
4.1 Version de CVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.2 Réglage de la date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4.3 Se placer dans le groupe de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
5
5
5
5
Du côté administrateur
5.1 Création du répertoire de dépôt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2 Initialisation du dépôt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.3 Gestion des droits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7
7
7
7
6
Du côté utilisateurs
6.1 Accès au dépôt . . . . . . . . . . . . .
6.2 Mise en place des variables CVS . . . .
6.3 Mise en place des fichiers dans le dépôt
6.4 Obtenir une copie de travail . . . . . . .
6.5 Archiver ses modifications . . . . . . .
6.6 Consulter les logs . . . . . . . . . . . .
6.7 Effectuer des comparaisons . . . . . . .
6.8 Se mettre à jour par rapport au dépôt . .
6.9 Gestion de versions . . . . . . . . . . .
6.10 Utilisation des mots-clé . . . . . . . . .
6.11 Commande annotate . . . . . . . . .
6.12 Branches . . . . . . . . . . . . . . . .
6.13 Fin des travaux . . . . . . . . . . . . .
6.14 Livraison d’une version . . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
9
9
9
10
11
12
16
16
17
22
23
24
25
32
32
7
Conseils
7.1 Se familiariser avec CVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
7.2 Quand faire un update, commit ... ? . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
34
34
34
8
Pour aller plus loin
8.1 Ajout/suppresion de fichier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.2 Mode pseudo-lock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
8.3 Renommer un fichier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
35
35
35
35
9
Annexes
9.1 Changer de groupe sous Unix/Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.2 NTPD : synchroniser son heure sous Linux/Unix . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
9.3 Formes courtes des commandes cvs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
36
36
36
36
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
1
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
10 Références
10.1 CVS . . . . . . . . . . . . .
10.2 Autres systèmes de contrôle
10.3 Interfaces graphiques . . . .
10.4 Outils annexes . . . . . . . .
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
38
38
38
38
38
1 Avant-propos
Ce tutorial s’inspire de nombreuses références dont [11, 9, 8].
Les conventions d’écriture adoptées ici sont les suivantes :
– le style de fonte "machine" est réservé aux noms de fichiers/répertoires, aux commandes Unix, cvs et aux sorties
écran ;
– une ligne de commande débute par ”$” ;
– ”(...)” dans une sortie écran indique qu’une partie des informations a été supprimée afin de faciliter sa lecture.
2 Objectifs et déroulement du TP
Les objectifs de cette session de travail sont les suivants :
– se familiariser avec les commandes CVS ;
– savoir où trouver les informations utiles pour éventuellement passer à un niveau avancé ;
– avoir des notions de développement en groupe.
Le TP consiste à développer un code à trois à l’aide de CVS. Pour cela,
– Former trois binômes (correspondant à trois développeurs fictifs U1, U2 et U3) ;
– Se logguer via ssh sur bambou.mss.ecp.fr ou ebenier.mss.ecp.fr (cvs et l’interface graphique que nous utiliserons y
sont correctement installés) ;
– Récupérer l’archive adaptée (TP CVS U1.tar.gz, TP CVS U2.tar.gz ou TP CVS U3.tar.gz) sur notre site
web
http ://www.mssmat.ecp.fr/article.php3 ?id article=844 ;
Ces archives sont composées d’un répertoire vide (”rep travail”) dans lequel vous travaillerez, d’un repertoire
"modifications" contenant les sources du code modifiées et enfin, pour U1, d’un répertoire "src org" contenant les sources initiales du projet sur lequel vous allez travailler ensemble ;
– Récupérer le fichier ”commandes.txt” utilisable pour faire directement des ”copier-coller” des commandes à taper ;
– Détarer l’archive dans votre /home.
Mais avant de débuter, un peu de théorie ...
3
CVS c’est quoi ?
CVS (Concurrent Versions System) est un outil permettant de travailler à plusieurs de manière concurrente sur un projet.
Son principe est simple : les utilisateurs travaillent sur une copie locale du projet et ajoutent les modifications au dépôt, le
répertoire qui contient toutes les révisions de tous les fichiers du projet.
3.1
Intêrets de CVS
Avec CVS, vous pouvez notamment :
– Travailler à plusieurs sur le même fichier (par exemple sur des fonctions différentes) : CVS permet de fusionner les
modifications des différents intervenants ;
– Consulter l’historique des modifications d’un fichier (qui a fait quoi, quand ?) ;
– Consulter les différences entre deux versions d’un fichier ;
3
– Récupérer n’importe quelle version d’un projet ou d’un fichier.
CVS est un logiciel libre et gratuit, distribué sous licence GNU GPL (voir le Site Officiel [2]). Il est disponible sous Linux,
Unix et Windows.
Remarque : il existe bien sûr d’autres systèmes de gestion de version comme Subversion [15] ou Arch [13] (voir les références
de la section 10.2 pour plus de détails).
3.2
Un peu de vocabulaire ...
Pour une bonne compréhension de la suite de ce tutorial, il est judicieux d’éclaircir tout d’abord quelques points de vocabulaire :
–
–
–
–
révision (revision) : employé pour caractériser une version d’un fichier seul (figure 1) ;
version (version) : plutôt employé pour parler d’une version du projet/module ou d’une version logicielle (figure 2) ;
dépôt (repository) : nom donné au répertoire d’accueil au niveau du serveur CVS ;
module (module) : nom caractérisant un projet/sous-projet disponible sur le serveur CVS.
D’autres termes techniques propres à CVS sont précisément décrits dans la référence [10].
F IG . 1 – Révisions d’un fichier. Les numéros de révision sont incrémentés automatiquement par CVS.
F IG . 2 – Version d’un projet.
3.3
Les interfaces graphiques
Par défaut CVS fonctionne en mode ”ligne de commandes” (sans interface graphique). Mais il existe un ensemble d’outils
graphiques dédiés à CVS (voir la sous-section 10.3 pour un ensemble de références). Parmi ceux-ci :
–
–
–
–
–
WinCvs : pour Windows [22] ;
Interface Emacs [19] ;
tkCVS : multi-plateformes (écrit en Tcl/Tk) [20] ;
Cervisia : pour Unix et Linux (écrit avec KDE) [17] ;
MacCvs : pour Mac [18] ;
etc.
4
3.4
Que lire ?
La documentation sur CVS est bien fournie. Une liste de références intéressantes est présentée dans la section 10.1.
Si CVS est installé sur votre machine, vous pouvez consulter la documentation en ligne en tapant :
$ info cvs
File: cvs.info,
Node: Top,
Next: Overview,
Up: (dir)
This info manual describes how to use and administer CVS version
1.11.2.
* Menu:
* Overview::
* Repository::
* Starting a new project::
* Revisions::
* Branching and merging::
* Recursive behavior::
(...)
4
An introduction to CVS
Where all your sources are stored
Starting a project with CVS
Numeric and symbolic names for revisions
Diverging/rejoining branches of development
CVS descends directories
Avant de commencer les choses sérieuses ...
Avant de passer au vif du sujet, quelques précautions s’imposent :
4.1
Version de CVS
Si vous disposez de CVS sur votre machine, vérifiez déjà que la version dont vous disposez est récente :
$ cvs -v
Concurrent Versions System (CVS) 1.11.2 (client/server)
(...)
Prenez en note avant de consulter un ouvrage sur CVS (par exemple, la référence [9] traite de CVS 1.10, ce qui peut expliquer
certains comportements différents).
4.2
Réglage de la date
CVS se sert de l’heure pour effectuer ses opérations. Lorsque les développeurs travaillent sur des machines différentes, il est
utile de synchroniser leur horloge avec, par exemple, le serveur sur lequel est installé le dépôt. Cette opération peut se faire
grâce à Network Time Protocol (voir section 9.2).
Dans notre cas, les horloges de bambou et ebenier ont été synchronisées par rapport à thuya.
4.3
Se placer dans le groupe de développement
Pour modifier le dépôt via les commandes cvs, il est impératif d’appartenir au groupe de développement ayant les permissions
adapatées sur ce répertoire.
Dans le cas de ce TP, vous devez donc vérifier que vous appartenez au groupe ada (et que vous êtes placés dans ce groupe
actuellement) :
$ groups
5
calcul admin ada
$ id -gn
ada
Reportez-vous à la section 9.1 pour plus de détails.
6
5 Du côté administrateur
5.1
Création du répertoire de dépôt
Dans un premier temps, l’administrateur doit déterminer le serveur sur lequel sera placé le dépôt et créer un répertoire. Ici,
l’administrateur oofe du groupe ada crée un répertoire DEPOT CVS sur thuya :
$ mkdir DEPOT_CVS
et note le chemin d’accès à ce répertoire :
$ cd DEPOT_CVS
$ pwd
/mnt/thuya/MSS/STR2/PERM/oofe/DEPOT_CVS
5.2
Initialisation du dépôt
L’administrateur renseigne ensuite sa variable d’environnement CVSROOT et initialise le dépôt :
$ setenv CVSROOT /mnt/thuya/MSS/STR2/PERM/oofe/DEPOT_CVS
$ cvs init
Remarque : utilisez setenv sous un shell csh, ou tcsh et export sous un shell compatible Bourne (bash, zsh...).
Une fois, le dépôt initialisé, un sous-répertoire nommé CVSROOT apparaı̂t dans celui-ci :
$ cd DEPOT_CVS/
$ ls -R
.:
CVSROOT
./CVSROOT:
checkoutlist
checkoutlist,v
commitinfo
commitinfo,v
config
config,v
cvswrappers
cvswrappers,v
editinfo
editinfo,v
Emptydir
history
loginfo
loginfo,v
modules
modules,v
notify
notify,v
rcsinfo
rcsinfo,v
taginfo
taginfo,v
val-tags
verifymsg
verifymsg,v
./CVSROOT/Emptydir:
Ce répertoire contient des fichiers d’administration CVS (voir les références [9, 8, 7] pour plus de détails).
Remarque : attention à ne pas confondre la variable d’environnement CVSROOT contenant le chemin du dépôt et le répertoire
CVSROOT.
5.3
Gestion des droits
Il convient maintenant de faire en sorte que le dépôt appartienne au groupe de développement et accorder à celui-ci les droits
en écriture :
$ cd
$ pwd
$ chgrp -R ada DEPOT_CVS/
$ chmod -R g+w DEPOT_CVS/
7
Il est important de noter à ce niveau que les utilisateurs ne doivent pas accéder directement au dépôt. Toute modification des sources présentes dans ce répertoire doit se faire par le biais de commandes cvs dont la forme générale est la suivante :
$ cvs [options] <commande> [options commande] [fichier ...]
Notez qu’en l’absence d’argument, la plupart des commandes ont un comportement récursif. Par ailleurs, toutes les commandes cvs existent sous des formes ”longues” et ”courtes” (voir section 9.3). Pour plus d’informations sur ces commandes,
utilisez l’aide en ligne :
$ cvs --help-options
$ cvs --help-commands
$ cvs -H <command name>
!
!
!
list of global options
list of commandans
command-specific help
8
6 Du côté utilisateurs
6.1
Accès au dépôt
CVS fonctionne principalement en mode client/serveur (depuis la version 1.5) : les données sont centralisées sur le serveur
et ordonnées en modules, et les développeurs peuvent extraire un ou plusieurs modules sur leur poste local pour faire des
modifications et demander au serveur de prendre en compte ces modifications en définissant de nouvelles révisions pour les
fichiers modifiés. On dénombre trois principales méthodes d’accès1 (voir figure 3) :
– l’accès direct
– l’accès en mode serveur (pserver)
– l’accès en mode rsh/ssh (ext)
La méthode rsh/ssh est souvent préférée à pserver car elle propose notamment le cryptage des informations qui transitent sur
le réseau. Au LMSSMat, nous emploierons les méthodes d’accés direct et ssh.
F IG . 3 – Accès au dépôt (accès direct, en mode serveur et rsh).
Remarquez toutefois que, quel que soit le mode d’accès utilisé, l’utilisateur doit disposer d’un compte sur le serveur.
Dans le cadre de ce TP, le dépôt sera placé sur thuya. Vous travaillerez donc en accès direct si vous vous logguez sur une des
machines de notre réseau (NIS).
6.2
Mise en place des variables CVS
Il faut maintenant renseigner quelques variables d’environnement.
La première variable à renseigner est CVSROOT. Elle permet notamment de dire à CVS où se trouve le dépôt (l’adresse du
server en cas d’accès de type pserver ou ssh etc, voir [8, 9] pour plus de détails).
En accès direct, la variable CVSROOT se réduit simplement à :
$ setenv CVSROOT /mnt/thuya/MSS/STR2/PERM/oofe/DEPOT_CVS
Rappel : utilisez setenv sous un shell csh, ou tcsh et export sous un shell compatible Bourne (bash, zsh...).
1 Il
en existe deux autres : l’accès en mode serveur GSSAPI (gserver) et l’accès en mode serveur kerberos (kserver).
9
Par ailleurs, certaines commandes vous imposent d’entrer un commentaire. Dans le cadre de ce TP, nous l’entrerons directement dans la ligne de commande grâce à l’option ”-m”. Dans le cas contraire, CVS ouvre l’éditeur par défaut (généralement
vi) et vous demande d’entrer un commentaire. Il est possible de changer cet éditeur par défaut en renseignant la variable
CVSEDITOR.
$ setenv CVSEDITOR vim
! inutile pour ce TP
Enfin, si vous travaillez en mode d’accès ssh, il faut positionner la variable CVS RSH à ssh :
$ setenv CVS_RSH ssh ! inutile pour ce TP
car CVS invoque rsh par défaut.
6.3
Mise en place des fichiers dans le dépôt
Supposons que le développeur U1 dispose d’un code Fortran (deux fichiers .f90, un Makefile et un fichier html dans un
sous-répertoire) dont il a testé le bon fonctionnement :
$ pwd
/mnt/(...)/mouronval/TP_CVS_U1/src_org
$ ls -R
.:
exo1.f90 exo2.exe exo2.f90 exo2.o HTML
Makefile
./HTML:
NOTE_DE_FIN.html
F IG . 4 – Principe de la commande import.
U1 souhaite continuer à développer ce code avec U2 et U3. Il veut donc placer les sources de son code dans le dépôt. Pour
cela, il se place dans le répertoire contenant ses sources et utilise la commande import (voir figure 4) dont la syntaxe est la
suivante :
$ cvs import -m "mon message" module vendor-tag release-tags
Le plus important là-dedans, c’est le paramètre module. C’est lui qui va créer un nouveau module sur le serveur CVS. vendortag (généralement le nom du concepteur du projet) et release-tag (tag identifiant la version du projet ; lors du premier import,
il s’agit d’une version initiale) sont des informations obligatoires mais pas très importantes.
Ainsi, pour placer son projet code f90 dans le dépôt, U1 doit entrer la commande suivante :
$ cvs import -m "enregistrement initial sous CVS" code_f90 U1 start
I code_f90/exo2.exe
N code_f90/exo2.f90
I code_f90/exo2.o
10
N code_f90/exo1.f90
N code_f90/Makefile
cvs import: Importing /mnt/(...)/oofe/DEPOT_CVS/code_f90/HTML
N code_f90/HTML/NOTE_DE_FIN.html
No conflicts created by this import
Vous pouvez voir que certains fichiers ont été ajoutés au dépôt (N pour ”New file”) alors que d’autres ont été ignorés (I pour
”Ignored”). Par défaut, les fichiers que CVS ne prend pas en compte sont :
–
–
–
–
–
–
–
–
–
RCS SCCS CVS CVS.adm
RCSLOG cvslog.*
tags TAGS
.make.state, .nse depinfo
* #* .#* ,* $* *$
*.old *.bak *.BAK *.orig *.rej .del-*
*.a *.olb *.o *.obj *.so *.exe
*.Z *.elc *.ln
core
En fait, il s’agit simplement des noms indiqués dans un fichier appelé ”cvsignore”. On peut donc facilement modifier ce
comportement par défaut (voir les références [8, 9]). Par exemple, on peut ajouter les ”*.mod” (générés à la compilation d’un
code F90) à cette liste ...
Une fois cette commande effectuée, le répertoire de dépôt DEPOT CVS, présent sur le compte de oofe, contient :
$ pwd
/mnt/(...)/oofe/DEPOT_CVS
$ ls -R
.:
code_f90 CVSROOT
./code_f90:
exo1.f90,v exo2.f90,v
HTML
Makefile,v
./code_f90/HTML:
NOTE_DE_FIN.html,v
./CVSROOT:
checkoutlist
checkoutlist,v
commitinfo
commitinfo,v
config
config,v
cvswrappers
cvswrappers,v
editinfo
editinfo,v
Emptydir
history
loginfo
loginfo,v
modules
modules,v
notify
notify,v
rcsinfo
rcsinfo,v
taginfo
taginfo,v
val-tags
verifymsg
verifymsg,v
./CVSROOT/Emptydir:
6.4
Obtenir une copie de travail
Les utilisateurs U1, U2 et U3 veulent maintenant récupérer une copie de travail. Pour cela, ils se placent dans leur répertoire
de travail (actuellement vide) :
$pwd
/mnt/(...)/mouronval/TP_CVS_U1/rep_de_travail
11
F IG . 5 – Principe de la commande checkout.
et invoquent la commande cvs checkout (figure 5) :
$ cvs checkout code_f90
cvs checkout: Updating code_f90
U code_f90/Makefile
U code_f90/exo1.f90
U code_f90/exo2.f90
cvs checkout: Updating code_f90/HTML
U code_f90/HTML/NOTE_DE_FIN.html
Le répertoire de travail des trois développeurs contient maintenant :
$ ls -R
.:
code_f90
./code_f90:
CVS exo1.f90
exo2.f90
./code_f90/CVS:
Entries Repository
HTML
Makefile
Root
./code_f90/HTML:
CVS NOTE_DE_FIN.html
./code_f90/HTML/CVS:
Entries Repository Root
Notez la présence d’un répertoire CVS par répertoire/sous-répertoire.
U1, U2 et U3 se placent maintenant dans leur répertoire code f90 et activent l’interface Tkcvs :
$ tkcvs &
6.5
Archiver ses modifications
L’utilisateur U1 décide de faire quelques changements dans le fichier exo2.f90 et le modifie grâce à son éditeur favori.
NB : Pour gagner du temps, les modification à faire aux sources durant ce TP ont déjà été réalisées, il suffit à l’utilisateur
concerné (ici U1) de les copier du répertoire modifications.
$pwd
/mnt/(...)/mouronval/TP_CVS_U1/rep_de_travail/code_f90
$ cp ../../modifications/modif1_g1_exo2.f90 exo2.f90
12
F IG . 6 – Tkcvs : état du répertoire de travail.
U1, U2 et U3 utilisent la commande cvs status à fin de connaı̂tre l’état de leur fichier local exo2.f90 par rapport au dépôt :
$ cvs status exo2.f90
Notez qu’il est aussi possible d’examiner le statut d’un fichier local grâce à Tkcvs (cliquez sur ”Re-read the current directory”
si besoin).
U1 obtient à l’ecran :
===================================================================
File: exo2.f90
Status: Locally Modified
Working revision:
Repository revision:
Sticky Tag:
Sticky Date:
Sticky Options:
1.1.1.1 Wed Nov 17 18:04:09 2004
1.1.1.1 /mnt/(...)/oofe/DEPOT_CVS/code_f90/exo2.f90,v
(none)
(none)
(none)
alors que U2 et U3 recoivent les informations suivantes :
===================================================================
File: exo2.f90
Status: Up-to-date
Working revision:
Sticky Tag:
Sticky Date:
Sticky Options:
1.1.1.1 Wed Nov 17 18:04:09 2004
(none)
(none)
(none)
13
Le fichier local de U1 est Locally Modified alors que ceux de U2 et U3 sont Up-to-date.
U1 archive maintenant sa modification dans le dépôt grâce à la commande commit (voir figure 7).
$ cvs commit -m "Ajout de Merci dans exo2" exo2.f90
Checking in exo2.f90;
/mnt/(...)/oofe/DEPOT_CVS/code_f90/exo2.f90,v
new revision: 1.2; previous revision: 1.1
done
<--
exo2.f90
Notez le passage de la révision 1.1 à 1.2 (numéro incrémenté automatiquement par CVS).
F IG . 7 – Principe de la commande commit.
U1, U2 et U3 examinent à nouveau l’état de leur fichier local exo2.f90 grâce à la commande cvs en ligne (ou à Tkcvs) :
Résultat pour U1 :
===================================================================
File: exo2.f90
Status: Up-to-date
Working revision:
Sticky Tag:
Sticky Date:
Sticky Options:
1.2
1.2
(none)
(none)
(none)
Thu Nov 18 09:53:06 2004
La copie de travail de U1 est à jour par rapport au dépôt.
Pour U2 et U3, la sortie écran est la suivante :
===================================================================
File: exo2.f90
Status: Needs Patch
Working revision:
Sticky Tag:
Sticky Date:
Sticky Options:
1.1.1.1 Wed Nov 17 18:04:09 2004
1.2
(none)
(none)
(none)
U2 et U3 ne sont plus Up-to-date car ils ne disposent que de la révision 1.1 de exo2.f90.
Needs patch indique que le fichier n’a pas été modifié localement mais que la révision du dépôt a changé.
Sous Tkcvs, il est possible de visualiser graphiquement les différentes versions du fichier dans le dépôt et votre position
(figure 8).
14
F IG . 8 – Arborescence de exo2.f90 dans le dépôt vue par U1 (à gauche) et U2 (ou U3) (à droite).
15
6.6
Consulter les logs
Pour en savoir plus sur les révisions des fichiers dans le dépôt, les utilisateurs peuvent consulter les ”logs” de ceux-ci. U1, U2
et U3 tapent donc :
$ cvs log exo2.f90
Le résultat de cette commande est le même pour U1, U2 et U3 :
RCS file: /mnt/(...)/oofe/DEPOT_CVS/code_f90/exo2.f90,v
Working file: exo2.f90
head: 1.2
branch:
locks: strict
access list:
symbolic names:
start: 1.1.1.1
U1: 1.1.1
keyword substitution: kv
total revisions: 3;
selected revisions: 3
description:
---------------------------revision 1.2
date: 2004/11/18 10:10:54; author: mouronval; state: Exp; lines: +1 -0
Ajout de Merci dans exo2
---------------------------revision 1.1
date: 2004/11/17 18:04:09; author: mouronval; state: Exp;
branches: 1.1.1;
Initial revision
---------------------------revision 1.1.1.1
date: 2004/11/17 18:04:09; author: mouronval; state: Exp; lines: +0 -0
enregistrement initial sous CVS
=============================================================================
6.7
Effectuer des comparaisons
U2 et U3 désirent voir les modifications apportées par U1 au fichier exo2.f90. Ils demandent donc à CVS de comparer le
fichier présent dans leur répertoire de travail avec la révision 1.2 du dépôt :
$ cvs -Q diff -c -r1.2 exo2.f90
Index: exo2.f90
===================================================================
retrieving revision 1.2
retrieving revision 1.1.1.1
diff -c -r1.2 -r1.1.1.1
*** exo2.f90
18 Nov 2004 10:10:54 -0000
1.2
--- exo2.f90
17 Nov 2004 18:04:09 -0000
1.1.1.1
***************
*** 13,19 ****
!
print *,"Entrez le nombre de lignes :"
read(*,*)n
16
-
print *,"Merci !"
print *,"Entrez le nombre de colonnes :"
read(*,*)m
!
--- 13,18 ---L’option ”-Q” est une option globale (car directement à droite de cvs) et indique à CVS d’être ”Quiet” alors que ”-c” est
une option de la commande diff permettant d’afficher la sortie écran au ”context diff format” (utilisable par l’outil patch).
Remarque : si U1 tape cette commande, il ne se passe rien puisque le fichier sur son répertoire de travail est identique à la
révision 1.2 du dépôt.
Les commandes diff et rdiff permettent faire de nombreux types de comparaison (utilisation de numéro de révision, de
la date etc). Pour plus d’exemples voir la documentation [9, 8].
6.8
Se mettre à jour par rapport au dépôt
6.8.1
Cas 1 : le fichier n’a pas été modifié localement
U2 désire récuperer la nouvelle révision (enregistrée par U1). Il tape la commande suivante :
$ cvs update exo2.f90
U exo2.f90
Comme vous l’avez sans doute déjà remarqué, CVS affiche des lettres (U, ?, A ...) dans ses messages de sortie. Voici leur
signification :
– U : le fichier a été créé dans votre répertoire de travail ou le fichier local (auquel vous n’avez fait aucune modification)
a été mis à jour ;
– A : le fichier est prévu pour être ajouté au dépôt et le sera après votre prochain archivage (commit) ;
– R : le fichier est prévu pour être supprimé du dépôt et le sera après votre prochain archivage (commit) ;
– M : le fichier a été modifié localement, il est possible que de nouveaux changements du dépôt aient été fusionnés.
– C : le fichier contient un conflit qui doit être réglé manuellement avant votre prochain archivage (commit) ;
– ? : le fichier local est inconnu du dépôt et il n’a pas été prévu de l’y ajouter.
U2 vérifie l’état de l’ensemble de ses fichiers locaux :
$ cvs status
cvs status: Examining .
===================================================================
File: Makefile
Status: Up-to-date
Working revision:
Sticky Tag:
Sticky Date:
Sticky Options:
1.1.1.1 Wed Nov 17 18:04:09 2004
1.1.1.1 /mnt/(...)/oofe/DEPOT_CVS/code_f90/Makefile,v
(none)
(none)
(none)
===================================================================
File: exo1.f90
Status: Up-to-date
(...)
===================================================================
File: exo2.f90
Status: Up-to-date
17
Working revision:
Sticky Tag:
Sticky Date:
Sticky Options:
1.2
1.2
(none)
(none)
(none)
Thu Nov 18 11:40:55 2004
cvs status: Examining HTML
===================================================================
File: NOTE_DE_FIN.html Status: Up-to-date
Working revision:
HTML/NOTE_DE_FIN.html,v
Sticky Tag:
Sticky Date:
Sticky Options:
1.1.1.1 Wed Nov 17 18:04:09 2004
1.1.1.1 /mnt/(...)/oofe/DEPOT_CVS/code_f90/
(none)
(none)
(none)
Notez le comportement récursif de la commande status lorsqu’aucun nom de fichier n’est précisé.
U2 modifie cette révision de exo2.f90 en y ajoutant une autre ligne :
$ pwd
/mnt/(...)/mouronval/TP_CVS_U2/rep_de_travail/code_f90
et l’archive :
$ cvs commit -m "Ajout d’un 2eme Merci dans exo2.f90"
ebenier[33] cvs commit -m "Ajout d’un 2eme Merci dans exo2.f90"
cvs commit: Examining .
cvs commit: Examining HTML
/mnt/(...)/oofe/DEPOT_CVS/code_f90/exo2.f90,v <-- exo2.f90
done
Remarque : notez le comportement récursif de la commande commit lorsqu’aucun nom de fichier n’est précisé.
Vous constatez maintenant que la dernière révision de exo2.f90 dans le dépôt est la 1.3.
6.8.2
Cas 2 : le fichier a été modifié localement mais les modifications ne sont pas en conflit avec les précédentes
Le fichier exo2.f90 présent dans son répertoire de travail de U3 est une copie de la révision 1.1 du dépôt. En effet, si U3
tape :
CVS lui indique :
===================================================================
File: exo2.f90
Status: Needs Patch
Working revision:
1.1.1.1 Wed Nov 17 18:04:09 2004
Repository revision: 1.3
(...)
18
Généralement, avant de commencer à modifier un fichier, il est souhaitable de faire un update pour récupérer sa dernière
révision présente sur le dépôt (ici la 1.3). U3 ne se rappelle pas de cette recommandation et rajoute une ligne loin de celles
ajoutées par les autres.
U3 veut enregistrer sa modification dans le dépôt. Que va-t-il se passer ?
$ cvs commit -m "Ajout de desole dans exo2.f90" exo2.f90
cvs commit: Up-to-date check failed for ‘exo2.f90’
cvs [commit aborted]: correct above errors first!
CVS refuse. U3 ne comprend pas et examine à nouveau l’état de son fichier :
===================================================================
File: exo2.f90
Status: Needs Merge
Working revision:
1.1.1.1 Wed Nov 17 18:04:09 2004
(...)
Needs Merge : la copie locale a été modifiée et le dépôt a changé entre temps.
La solution est alors de faire une mise-à-jour pour prendre en compte les modifications faites par les deux autres utilisateurs.
On suppose ici que U3 est d’accord avec les modifications faites par U1 et U2 (il a comparé son fichier avec la révision 1.3
de exo2.f90 présente dans le dépôt grâce à la commande diff) :
$ cvs -Q diff -c -r1.3 exo2.f90
(...)
$ cvs update exo2.f90
Merging differences between 1.1.1.1 and 1.3 into exo2.f90
M exo2.f90
Résultat : CVS a reussi à intégrer les modifications de U1 et U2 au fichier que U3 vient de modifier. Il ne reste à U3 qu’à
l’archiver dans le dépôt.
$ cvs commit -m "Ajout de desole dans exo2.f90" exo2.f90
done
Il est possible de revenir au fichier avant sa mise-à-jour car CVS en laisse une copie dans le répertoire local :
$ ls -altr
(...)
-rw-r-----rw-r--r-drwxr-x--drwxr-x---
1
1
4
2
oofe
oofe
oofe
oofe
ada
ada
ada
ada
1181
1227
4096
4096
19
Nov
Nov
Nov
Nov
18
18
18
18
14:02
14:06
14:06
14:07
.#exo2.f90.1.1.1.1
exo2.f90
.
CVS
6.8.3
Cas 3 : le fichier a été modifié localement et sa mise-à-jour provoque un conflit
U1 n’est pas à jour par rapport au dépôt (il en est encore à la révision 1.2 alors que le dépôt contient maintenant la révision
1.4). Lui aussi oublie de mettre à jour son fichier exo2.f90 avant d’y introduire des changements. Il modifie la même ligne
que U3 :
et demande à CVS d’archiver son fichier :
$ cvs commit -m "Ajout d’une ligne dans exo2.f90"
cvs commit: Up-to-date check failed for ‘exo2.f90’
cvs [commit aborted]: correct above errors first!
Il constate qu’il n’est pas à jour et tente de faire un update pour ajouter à son fichier les modifications faites par U2 et U3 :
$ cvs update
cvs update: Updating .
Merging differences between 1.2 and 1.4 into exo2.f90
rcsmerge: warning: conflicts during merge
cvs update: conflicts found in exo2.f90
C exo2.f90
cvs update: Updating HTML
Cette fois, CVS ne parvient pas à fusionner toutes les modifications (”C” = Conflit). U1 édite le fichier exo2.f90. Il voit
que la modif faite par U2 a bien été incorporée mais que celle faite par U3 a généré un conflit. Celui est indiqué par des
délimiteurs spéciaux :
print *,"Erreur d’allocation"
<<<<<<< exo2.f90
print *,"Verifier m et n"
=======
print *,"Desole"
>>>>>>> 1.4
stop 4
U1 doit procéder à une correction ”manuelle”, par exemple en remplaçant ces lignes par :
print *,"Desole, Verifier m et n"
stop 4
et faire un archivage :
$ cvs commit -m "Ajout d’une ligne dans exo2.f90"
/mnt/(...)/oofe/DEPOT_CVS/code_f90/exo2.f90,v <-new revision: 1.5; previous revision: 1.4
done
20
exo2.f90
Remarque : afin d’éviter ce genre de désagrément (conflits), mieux vaut effectuer de fréquentes mises-à-jour.
Avant de passer à la suite, tous les utilisateurs font un update.
$ cvs update
Au passage U1, U2 et U3 jettent un coup d’oeil à l’arborescence des révisions des fichiers grâce à Tkcvs (figure 9).
F IG . 9 – Tkcvs : arborescence de exo2.f90.
21
6.9
Gestion de versions
Le code obtenu satisfait tout les développeurs. U2 décide donc de faire une version du projet regroupant les dernières révisions
des différents fichiers présents dans son répertoire de travail :
$ cvs tag Version_a_diffuser
$ cvs tag Version_a_diffuser
cvs tag: Tagging .
T Makefile
T exo1.f90
T exo2.f90
cvs tag: Tagging HTML
T HTML/NOTE_DE_FIN.html
Les trois utilisateurs vérifient que l’étiquetage des fichier a bien eu lieu :
$ cvs status -v
===================================================================
File: Makefile
Status: Up-to-date
Working revision:
Sticky Tag:
Sticky Date:
Sticky Options:
1.1.1.1 Wed Nov 17 18:04:09 2004
1.1.1.1 /mnt/(...)/DEPOT_CVS/code_f90/Makefile,v
(none)
(none)
(none)
Existing Tags:
Version_a_diffuser
start
U1
(revision: 1.1.1.1)
(revision: 1.1.1.1)
(branch: 1.1.1)
===================================================================
File: exo1.f90
Status: Up-to-date
(...)
===================================================================
File: exo2.f90
Status: Up-to-date
Working revision:
Sticky Tag:
Sticky Date:
Sticky Options:
1.5
1.5
(none)
(none)
(none)
Existing Tags:
Version_a_diffuser
start
U1
Thu Nov 18 15:42:40 2004
(revision: 1.5)
(revision: 1.1.1.1)
(branch: 1.1.1)
===================================================================
Working revision:
1.1.1.1 Wed Nov 17 18:04:09 2004
22
NOTE_DE_FIN.html,v
Sticky Tag:
Sticky Date:
Sticky Options:
1.1.1.1 /mnt/(...)/oofe/DEPOT_CVS/code_f90/HTML/
(none)
(none)
(none)
Existing Tags:
Version_a_diffuser
start
U1
(revision: 1.1.1.1)
(revision: 1.1.1.1)
(branch: 1.1.1)
Remarquez bien que les numéros de révision des fichiers appartenant à une même version du projet ne sont pas obligatoirement identiques.
6.10
Utilisation des mots-clé
CVS permet d’indiquer quelques mots-clé dans les fichiers sources, voire dans les documentations ou pages html. Ces motsclé seront automatiquement ”développés” par CVS lors de la sauvegarde du fichier sur le dépôt.
Lorsque le fichier géré par CVS est un fichier source dans un langage particulier (C, fortran, html ...), les mots-clé de substitution doivent souvent être placés dans des zones où ils ne perturberont pas les compilateurs ou les interpréteurs : entre
commentaires, dans des chaı̂nes de caractères, ...
Le mot-clé le plus couramment utilisé est $Id$, dont ”l’expansion” indique :
1. le nom du fichier tel qu’il se présente sur le dépôt (d’où la présence du ,v additionnel) ;
2. le numéro de révision ;
3. la date et l’heure du dernier enregistrement (en temps universel coordonné) ;
4. l’identifiant (login) du dernier utilisateur qui a modifié le fichier ;
5. l’état assigné à la révision courante, par défaut Exp (pour ”expérimental”), mais aussi Stab (pour ”stable”), Rel (pour
released, ”publié”, voire toute autre expression) ;
6. enfin, le cas échéant, l’identifiant de l’utilisateur qui a ”verrouillé” la révision.
U1 décide de tester les mots-clé sur exo2.f90. Il l’édite et y ajoute en première ligne :
! $Id$
U2 fait de même pour exo1.f90 et U3 modifie le fichier NOTE DE FIN.html en y incluant la ligne suivante :

Tous les trois archivent leur modification.
$ cvs commit -m "Ajout d’un mot cle" exo2.f90
$ cvs commit -m "Ajout d’un mot cle" exo1.f90
$ cvs commit -m "Ajout d’un mot cle" NOTE_DE_FIN.html
! U1
! U2
! U3
Dès que l’archivage est terminé, chacun édite à nouveau son fichier et constate que CVS a ”développé” le mot-clé qui a été
inséré :
Pour exo2.f90 (U1) :
23
! $Id: exo2.f90,v 1.6 2004/11/19 16:40:49 mouronval Exp $
Pour exo1.f90 (U2) :
! $Id: exo1.f90,v 1.2 2004/11/19 16:46:26 mouronval Exp $
Pour NOTE DE FIN.html (U3) :

Avant de passer à la suite, tous les utilisateurs font un update (attention U3 doit remonter hors du répertoire HTML).
$ cvs update
6.11
Commande annotate
Une autre commande intéressante est annotate :
$ cvs annotate exo2.f90
CVS affiche à l’écran la dernière révision du fichier du dépôt et indique, pour chaque ligne, les modifications effectuées, le
numéro de révision, l’auteur ...
Annotations for exo2.f90
***************
1.6
(mouronva 19-Nov-04): ! $Id$
1.1
(mouronva 19-Nov-04): program ex02
(...)
1.1
(mouronva 19-Nov-04):
read(*,*)n
1.2
print *,"Merci !"
1.1
print *,"Entrez le nombre de colonnes :"
1.3
print *,"Merci aussi !"
1.1
read(*,*)m
(...)
1.1
if (err /= 0) then
1.1
1.5
print *,"Desole, Verifier m et n"
1.1
stop 4
(...)
1.1
(mouronva 19-Nov-04): end program ex02
24
6.12
Branches
Nous allons voir maintenant comment créer une nouvelle branche (figure 10) de développement (par exemple pour corriger
un bug sur une version de projet déjà distribuée).
F IG . 10 – Exemple de branche.
U3 définit une branche à partir de Version a diffuser (figure 11) :
$ cvs tag -b
-r
Version_a_diffuser CORRECTION_Version_a_diffuser
cvs tag: Tagging .
T Makefile
T exo1.f90
T exo2.f90
cvs tag: Tagging HTML
T HTML/NOTE_DE_FIN.html
Notez l’utilisation de la commande tag (ou rtag) avec l’option -b (branch).
U1, U2 et U3 examinent l’état de leur copie de travail :
$ cvs status -v
===================================================================
File: Makefile
Status: Up-to-date
(...)
===================================================================
File: exo1.f90
Status: Up-to-date
Working revision:
Sticky Tag:
Sticky Date:
Sticky Options:
1.2
1.2
(none)
(none)
(none)
Fri Nov 19 16:47:29 2004
Existing Tags:
CORRECTION_Version_a_diffuser
Version_a_diffuser
release-tags
vendor-tag
(branch: 1.1.1.1.2)
(revision: 1.1.1.1)
(revision: 1.1.1.1)
(branch: 1.1.1)
===================================================================
File: exo2.f90
Status: Up-to-date
25
Working revision:
1.6
(...)
Fri Nov 19 16:47:29 2004
Existing Tags:
Version_a_diffuser
release-tags
vendor-tag
(branch: 1.5.2)
(revision: 1.5)
(revision: 1.1.1.1)
(branch: 1.1.1)
===================================================================
Working revision:
1.2
(...)
Fri Nov 19 16:45:13 2004
/mnt/(...)/oofe/DEPOT_CVS/code_f90/HTML
Existing Tags:
Version_a_diffuser
release-tags
vendor-tag
(branch: 1.1.1.1.2)
(revision: 1.1.1.1)
(revision: 1.1.1.1)
(branch: 1.1.1)
F IG . 11 – Tkcvs : création d’une branche.
U1, U2 et U3 placent dans cette branche (figure 12) :
26
$ cvs update -r CORRECTION_Version_a_diffuser
U exo1.f90
U exo2.f90
U HTML/NOTE_DE_FIN.html
F IG . 12 – Tkcvs : après déplacement dans la nouvelle branche.
$ cvs status -v
===================================================================
File: Makefile
Status: Up-to-date
(...)
===================================================================
File: exo1.f90
Status: Up-to-date
Working revision:
Sticky Tag:
Sticky Date:
Sticky Options:
1.1.1.1 Fri Nov 19 17:00:27 2004
CORRECTION_Version_a_diffuser (branch: 1.1.1.1.2)
(none)
(none)
Existing Tags:
Version_a_diffuser
release-tags
vendor-tag
(branch: 1.1.1.1.2)
(revision: 1.1.1.1)
(revision: 1.1.1.1)
(branch: 1.1.1)
27
===================================================================
File: exo2.f90
Status: Up-to-date
Working revision:
Sticky Tag:
Sticky Date:
Sticky Options:
1.5
Fri Nov 19 17:00:27 2004
1.5
CORRECTION_Version_a_diffuser (branch: 1.5.2)
(none)
(none)
Existing Tags:
Version_a_diffuser
release-tags
vendor-tag
(branch: 1.5.2)
(revision: 1.5)
(revision: 1.1.1.1)
(branch: 1.1.1)
===================================================================
Working revision:
NOTE_DE_FIN.html,v
Sticky Tag:
Sticky Date:
Sticky Options:
1.1.1.1 Fri Nov 19 17:00:27 2004
1.1.1.1 /mnt/(...)/oofe/DEPOT_CVS/code_f90/HTML/
CORRECTION_Version_a_diffuser (branch: 1.1.1.1.2)
(none)
(none)
Existing Tags:
Version_a_diffuser
release-tags
vendor-tag
(branch: 1.1.1.1.2)
(revision: 1.1.1.1)
(revision: 1.1.1.1)
(branch: 1.1.1)
U2 souhaite corriger le bug de exo2.f90 :
cp ../../modifications/modif2_g2_exo2.f90 exo2.f90
et archiver sa correction dans la branche (figure 13) :
$ cvs commit -m "correction du bug"
new revision: 1.5.2.1; previous revision: 1.5
done
<--
exo2.f90
Il revient ensuite à la branche principale et vérifie que l’opération s’est bien passée :
$ cvs update -A
U exo1.f90
U exo2.f90
U HTML/NOTE_DE_FIN.html
28
F IG . 13 – Tkcvs : branche après correction du bug.
$ cvs status -v
===================================================================
File: Makefile
Status: Up-to-date
(...)
===================================================================
File: exo1.f90
Status: Up-to-date
(...)
===================================================================
File: exo2.f90
Status: Up-to-date
Working revision:
1.6
(...)
Sun Nov 21 15:08:12 2004
Existing Tags:
Version_a_diffuser
release-tags
vendor-tag
(branch: 1.5.2)
(revision: 1.5)
(revision: 1.1.1.1)
(branch: 1.1.1)
===================================================================
Working revision:
1.2
Sun Nov 21 15:08:12 2004
29
NOTE_DE_FIN.html,v
(...)
/mnt/(...)/oofe/DEPOT_CVS/code_f90/HTML/
Existing Tags:
Version_a_diffuser
release-tags
vendor-tag
(branch: 1.1.1.1.2)
(revision: 1.1.1.1)
(revision: 1.1.1.1)
(branch: 1.1.1)
L’option -A (=reset) permet de supprimer les ”labels collants” (sticky tags).
U2 compare la révision qu’il vient de récupérer à la dernière de la branche ”CORRECTION Version a diffuser” :
$ cvs -q diff -c -r CORRECTION_Version_a_diffuser exo2.f90
Index: exo2.f90
===================================================================
diff -c -r1.5.2.1 -r1.6
*** exo2.f90
19 Nov 2004 17:15:53 -0000
1.5.2.1
--- exo2.f90
19 Nov 2004 16:40:49 -0000
1.6
***************
*** 1,3 ****
--- 1,4 ---+ ! $Id: exo2.f90,v 1.6 2004/11/19 16:40:49 mouronval Exp $
program ex02
implicit none
!
***************
*** 44,49 ****
!
do i=1,n
print *,mat(i,:)
print *,"Suppression du bug grace a la branche"
enddo
end program ex02
--- 45,49 ---et incorpore les changements effectués dans la branche ”CORRECTION Version a diffuser” à la branche principale en
réalisant une fusion :
$ cvs update -j CORRECTION_Version_a_diffuser
Merging differences between 1.1 and 1.1.1.1 into exo1.f90
Merging differences between 1.5 and 1.5.2.1 into exo2.f90
30
RCS file: /mnt/(...)/oofe/DEPOT_CVS/code_f90/HTML/NOTE_DE_FIN.html,v
Merging differences between 1.1 and 1.1.1.1 into NOTE_DE_FIN.html
L’option -j (join) permet de réaliser la fusion entre deux branches.
Le fichier local est maintenant différent de la révision 1.6 du dépôt (car CVS vient d’incorporer les changements effectués
dans la branche ”CORRECTION Version a diffuser”)
$ cvs diff exo2.f90
Index: exo2.f90
===================================================================
diff -r1.6 exo2.f90
47a48
>
print *,"Suppression du bug grace a la branche"
Il ne reste qu’à l’archiver dans la branche principale (voir figure 14) :
$ cvs commit -m "Correction du bug par fusion avec branche CORRECTION"
done
31
F IG . 14 – Tkcvs : après retour à la branche principale et fusion de la branche de correction.
6.13
Fin des travaux
Vous avez terminé vos modifications. Votre copie de travail peut être effacée. Pour cela, placez-vous en amont du répertoire
code f90 :
$ pwd
/mnt/(...)/oofe/TP_CVS_U3/rep_de_travail
et tapez la commande :
$ cvs release -d code_f90
You have [0] altered files in this repository.
Are you sure you want to release (and delete) directory ‘code_f90’: yes
C’est plus sûr que d’utiliser la commande Unix rm car CVS vérifie que vous avez bien archivé toutes vos modifications avant
d’effacer le répertoire local.
6.14
Livraison d’une version
La commande export est en quelque sorte l’inverse de import : elle fournit une copie de distribution. Elle donne la même
chose que checkout, mais sans les informations de gestion interne de CVS. Cette copie, rangée dans le répertoire courant,
n’est donc pas destinée à être modifiée.
Testez la à partir de votre home par exemple :
$ cvs export -r Version_a_diffuser code_f90
32
cvs export: Updating code_f90
U code_f90/Makefile
U code_f90/exo1.f90
U code_f90/exo2.f90
cvs export: Updating code_f90/HTML
U code_f90/HTML/NOTE_DE_FIN.html
Un répertoire code f90 est créé dans le répertoire courant.
Notez que la syntaxe générale de cette commande est :
cvs export -r <tag> <nomDuProjet>
cvs export -D <date> <nomDuProjet>
Une des options -r <tag> ou -D <date> est obligatoire :
– -r <tag> indique la livraison que l’on souhaite récupérer, c’est la manière la plus simple et la plus sûre de récupérer
une version précise du logiciel.
– -D <date> indique qu’on veut les fichiers dans leurs révisions les plus récentes à la date indiquée (ex : 2001-05-29).
33
7 Conseils
La lecture du chapitre 2 de la référence [8] est conseillée.
7.1
Se familiariser avec CVS
Refaire le TP seul. Pour cela, récupérez les trois fichiers .tar présents sur le site web. Vous obtiendrez trois répertoires de
travail indépendants (ce qui sera équivalent à trois users différents). Suivez ensuite les instructions du tutorial.
7.2
Quand faire un update, commit ... ?
Règles de bon usage :
1. CVS ne dispense pas d’une communication active entre les membres de l’équipe.
2. Quand un membre commence à travailler sur le projet, il fait un checkout, et, sauf cas particulier, il n’en fera pas
d’autre.
3. Un commit ne devrait être fait que pour une nouvelle version testée et validée d’un fichier ou de plusieurs fichiers.
Souvenez-vous que si le commit échoue c’est qu’il est probablement nécessaire que vous fassiez d’abord un update.
4. A la suite d’un commit réussi, les autres membres de l’équipe devraient faire un update afin de récupérer les
dernières modifications.
34
8 Pour aller plus loin
8.1
Ajout/suppresion de fichier
Lorsque l’on souhaite inclure un nouvel élément dans un projet, il faut explicitement l’indiquer par :
cvs add -m "message" <nom_de_fichier>
CVS informe alors que la prise en compte du nouveau fichier ne sera effective qu’après le prochain commit :
$ cvs commit <nom_de_fichier>
De la même manière, la suppression d’un fichier ne sera effective qu’après le commit :
$ cvs remove <nom_de_fichier>
$ cvs commit <nom_de_fichier>
8.2
Mode pseudo-lock
CVS peut fonctionner en mode pseudo-lock (avec possibilité d’envoi de mails). Voir les commandes cvs edit, cvs
watch ...
8.3
Renommer un fichier
CVS ne permet pas de renommer directement un fichier. La méthode la plus simple est de déplacer le fichier avec mv, de faire
un cvs remove de l’ancien nom, et un cvs add du nouveau nom.
35
9 Annexes
9.1
Changer de groupe sous Unix/Linux
Pour connaı̂tre le(s) groupe(s) Unix au(x)quel(s) vous appartenez, entrez :
$ groups
calcul admin
Pour connaı̂tre le groupe dans lequel vous trouvez actuellement, tapez :
$ id -gn
calcul
Pour se mettre dans le groupe admin, utilisez la commande ”newpgroup” :
$ newgrp admin
$ id -gn
admin
9.2
NTPD : synchroniser son heure sous Linux/Unix
Exemple : Synchroniser l’horloge de bambou.mss.ecp.fr avec celle du serveur thuya.
Solution 1 (par l’interface graphique)
Allez dans System Settings - Date & Time et activer Enable Network Time Protocol en précisant comme
serveur thuya.
Solution 2 (par ligne de commande)
Tapez simplement :
$ ntpdate thuya
Pour plus de détails :
$ man ntpd
9.3
Formes courtes des commandes cvs
$ cvs
--help-synonyms
CVS command synonyms
add
admin
annotate
checkout
commit
diff
export
history
import
log
are:
ad new
adm rcs
ann
co get
ci com
di dif
exp ex
hi his
im imp
lo
36
login
rannotate
rdiff
release
remove
rlog
rtag
status
tag
update
version
logon lgn
rann ra
patch pa
re rel
rm delete
rl
rt rfreeze
st stat
ta freeze
up upd
ve ver
37
10 Références
10.1
CVS
[1] The CVS Client. http ://www.lincvs.org/.
[2] Site officiel de CVS. https ://www.cvshome.org/.
[3] Introduction à CVS, 2004. http ://ricky81.developpez.com/tutoriel/cvs/introduction/.
[4] A. Cadiou. CVS, Utilisation en mode server, 2003. Note Technique Codiciel-LMFA N2003-07,
http ://www.codiciel.fr/gestion/cvs/tex 2003/handbook.pdf.
[5] A. Cadiou. CVS, 2004. Cours et TP (en partie sous Cervisia) présentés à la journée CODICIEL,
http ://maply.univ-lyon1.fr/spip/article.php3 ?id article=20111, Niveau débutant.
[6] P. Durif. Utilisation de CVS, 2004. http ://www.lifl.fr/ durif/cvs/cvs.html.
[7] P. Cederqvist et al. Version Management with CVS for CVS 1.11.2. Par exemple, sur bambou dans /usr/share/doc/cvs1.11.2 : cvs.ps et d’autres, consultable aussi via la commande ”cvs info”, documentation complète mais difficile pour
débuter.
[8] K. Fogel and M. Bar. Open Source Development with CVS, chapitres 2 (An overview of CVS), 3 (CVS Repository
Administration), 4 (Advanced CVS), 5 (Tips and Troubleshooting) et 10 (Complete CVS Reference). 3rd Edition,
http ://cvsbook.red-bean.com/OSDevWithCVS 3E.pdf.
[9] F. Lepied. CVS configuration et mise en œuvre, 2000. Edition O’Reilly, pour CVS 1.10, un exemplaire au laboratoire,
un second bientôt à la bibliothèque ECP, Niveaux débutant et avancé.
[10] A. Lesné and O. Berger. Utilisation de CVS, 2000. http ://www.idealx.org/doc/cvs.fr.html.
[11] A. Pedrono. CVS : principales fonctionnalités. Transparents, http ://www.imft.fr/cutis/cvs/CVS.pdf.
10.2
Autres systèmes de contrôle
[12] Aegis, Arch, CVS, Subversion, SVK briefly compared. http ://wiki.gnuarch.org/moin.cgi/SubVersionAndCvsComparison.
[13] Arch. http ://regexps.srparish.net/www/.
[14] Meta-CVS. http ://users.footprints.net/ kaz/mcvs.html.
[15] Subversion. http ://subversion.tigris.org/.
[16] K. Fogel and M. Bar.
Open Source Development with CVS, chapitre 11.
bean.com/OSDevWithCVS 3E.pdf.
10.3
http ://cvsbook.red-
Interfaces graphiques
[17] Learning CVS using KDE’s Cervisia. http ://osnews.com/story.php ?news id=6096.
[18] MacCVS. http ://www.maccvs.org/.
[19] PCL-CVS. interface Emacs, http ://www.informatik.uni-hamburg.de/RZ/software/emacs/pcl-cvs/pcl-cvs toc.html.
[20] TkCVS. http ://www.twobarleycorns.net/tkcvs.html.
[21] Tortoise interface. plugin pour l’Explorer de Microsoft, http ://www.tortoisecvs.org/.
[22] WinCVS. Client graphique sous Windows, http ://www.wincvs.org/.
[23] K. Fogel and M. Bar. Open Source Development with CVS, chapitre 9 (third-party tools that work with cvs).
http ://cvsbook.red-bean.com/OSDevWithCVS 3E.pdf.
10.4
Outils annexes
[24] Patch. http ://www.softwarepatch.com/.
38

Initiation `a CVS - Mon site SPIP

Transcription

Documents pareils

Etape Infos n°45 Février 2013

Forum: CÃ¹ng suy ngáº«m, tháº£o luáº n

filtration et désembouage circuit chauffage à lalinde 24 dordogne

Les nouveaux Systèmes de Gestion de Version

immobilière - Notaires de France

STAGES planificateur CVSE 2015

UFFICIO FILATELICO E NUMISMATICO Dipartimento Finanze

Détail de l`offre : Chef de Secteur Caisse H/F Date

Ordre du jour | Agenda

Fiche examen 2

Mise en Page