Initiation `a CVS - Mon site SPIP
Transcription
Initiation `a CVS - Mon site SPIP
Ecole Centrale Paris LABORATOIRE de MECANIQUE DES SOLS, STRUCTURES ET MATERIAUX CNRS UMR 8579 Initiation à CVS A.-S. Mouronval Version destinée au groupe Oofe Grande Voie des Vignes 92295 Châtenay-Malabry Tél : +33 (0) 141 13 13 38 Fax : +33 (0) 141 13 14 30 http ://www.mssmat.ecp.fr Décembre 2004 Table des matières 1 Avant-propos 3 2 Objectifs et déroulement du TP 3 3 CVS c’est quoi ? 3.1 Intê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 sérieuses ... 4.1 Version de CVS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.2 Réglage de la date . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4.3 Se placer dans le groupe de développement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 5 5 5 5 Du côté administrateur 5.1 Création du répertoire de dépôt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.2 Initialisation du dépôt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5.3 Gestion des droits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 7 7 7 6 Du côté utilisateurs 6.1 Accès au dépôt . . . . . . . . . . . . . 6.2 Mise en place des variables CVS . . . . 6.3 Mise en place des fichiers dans le dépô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 à jour par rapport au dépôt . . 6.9 Gestion de versions . . . . . . . . . . . 6.10 Utilisation des mots-clé . . . . . . . . . 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 Références 10.1 CVS . . . . . . . . . . . . . 10.2 Autres systèmes de contrôle 10.3 Interfaces graphiques . . . . 10.4 Outils annexes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38 38 38 38 38 1 Avant-propos Ce tutorial s’inspire de nombreuses références dont [11, 9, 8]. Les conventions d’écriture adoptées ici sont les suivantes : – le style de fonte "machine" est réservé aux noms de fichiers/répertoires, aux commandes Unix, cvs et aux sorties écran ; – une ligne de commande débute par ”$” ; – ”(...)” dans une sortie écran indique qu’une partie des informations a été supprimée afin de faciliter sa lecture. 2 Objectifs et déroulement du TP Les objectifs de cette session de travail sont les suivants : – se familiariser avec les commandes CVS ; – savoir où trouver les informations utiles pour éventuellement passer à un niveau avancé ; – avoir des notions de développement en groupe. Le TP consiste à développer un code à trois à l’aide de CVS. Pour cela, – Former trois binômes (correspondant à trois dé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 installés) ; – Récupérer l’archive adapté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 composées d’un répertoire vide (”rep travail”) dans lequel vous travaillerez, d’un repertoire "modifications" contenant les sources du code modifiées et enfin, pour U1, d’un répertoire "src org" contenant les sources initiales du projet sur lequel vous allez travailler ensemble ; – Récupérer le fichier ”commandes.txt” utilisable pour faire directement des ”copier-coller” des commandes à taper ; – Détarer l’archive dans votre /home. Mais avant de débuter, un peu de théorie ... 3 CVS c’est quoi ? CVS (Concurrent Versions System) est un outil permettant de travailler à plusieurs de manière concurrente sur un projet. Son principe est simple : les utilisateurs travaillent sur une copie locale du projet et ajoutent les modifications au dépôt, le répertoire qui contient toutes les révisions de tous les fichiers du projet. 3.1 Intêrets de CVS Avec CVS, vous pouvez notamment : – Travailler à plusieurs sur le même fichier (par exemple sur des fonctions différentes) : CVS permet de fusionner les modifications des différents intervenants ; – Consulter l’historique des modifications d’un fichier (qui a fait quoi, quand ?) ; – Consulter les différences entre deux versions d’un fichier ; 3 – Récupérer n’importe quelle version d’un projet ou d’un fichier. CVS est un logiciel libre et gratuit, distribué sous licence GNU GPL (voir le Site Officiel [2]). Il est disponible sous Linux, Unix et Windows. Remarque : il existe bien sûr d’autres systèmes de gestion de version comme Subversion [15] ou Arch [13] (voir les références de la section 10.2 pour plus de détails). 3.2 Un peu de vocabulaire ... Pour une bonne compréhension de la suite de ce tutorial, il est judicieux d’éclaircir tout d’abord quelques points de vocabulaire : – – – – révision (revision) : employé pour caractériser une version d’un fichier seul (figure 1) ; version (version) : plutôt employé pour parler d’une version du projet/module ou d’une version logicielle (figure 2) ; dépôt (repository) : nom donné au répertoire d’accueil au niveau du serveur CVS ; module (module) : nom caractérisant un projet/sous-projet disponible sur le serveur CVS. D’autres termes techniques propres à CVS sont précisément décrits dans la référence [10]. F IG . 1 – Révisions d’un fichier. Les numéros de révision sont incrémentés automatiquement par CVS. F IG . 2 – Version d’un projet. 3.3 Les interfaces graphiques Par défaut CVS fonctionne en mode ”ligne de commandes” (sans interface graphique). Mais il existe un ensemble d’outils graphiques dédiés à CVS (voir la sous-section 10.3 pour un ensemble de références). Parmi ceux-ci : – – – – – WinCvs : pour Windows [22] ; Interface Emacs [19] ; tkCVS : multi-plateformes (écrit en Tcl/Tk) [20] ; Cervisia : pour Unix et Linux (écrit avec KDE) [17] ; MacCvs : pour Mac [18] ; etc. 4 3.4 Que lire ? La documentation sur CVS est bien fournie. Une liste de références intéressantes est présentée dans la section 10.1. Si CVS est installé 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 sérieuses ... Avant de passer au vif du sujet, quelques précautions s’imposent : 4.1 Version de CVS Si vous disposez de CVS sur votre machine, vérifiez déjà que la version dont vous disposez est ré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 référence [9] traite de CVS 1.10, ce qui peut expliquer certains comportements différents). 4.2 Réglage de la date CVS se sert de l’heure pour effectuer ses opérations. Lorsque les développeurs travaillent sur des machines différentes, il est utile de synchroniser leur horloge avec, par exemple, le serveur sur lequel est installé le dépôt. Cette opération peut se faire grâce à Network Time Protocol (voir section 9.2). Dans notre cas, les horloges de bambou et ebenier ont été synchronisées par rapport à thuya. 4.3 Se placer dans le groupe de développement Pour modifier le dépôt via les commandes cvs, il est impératif d’appartenir au groupe de développement ayant les permissions adapatées sur ce répertoire. Dans le cas de ce TP, vous devez donc vérifier que vous appartenez au groupe ada (et que vous êtes placés dans ce groupe actuellement) : $ groups 5 calcul admin ada $ id -gn ada Reportez-vous à la section 9.1 pour plus de détails. 6 5 Du côté administrateur 5.1 Création du répertoire de dépôt Dans un premier temps, l’administrateur doit déterminer le serveur sur lequel sera placé le dépôt et créer un répertoire. Ici, l’administrateur oofe du groupe ada crée un répertoire DEPOT CVS sur thuya : $ mkdir DEPOT_CVS et note le chemin d’accès à ce répertoire : $ cd DEPOT_CVS $ pwd /mnt/thuya/MSS/STR2/PERM/oofe/DEPOT_CVS 5.2 Initialisation du dépôt L’administrateur renseigne ensuite sa variable d’environnement CVSROOT et initialise le dépô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 dépôt initialisé, un sous-répertoire nommé 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 répertoire contient des fichiers d’administration CVS (voir les références [9, 8, 7] pour plus de détails). Remarque : attention à ne pas confondre la variable d’environnement CVSROOT contenant le chemin du dépôt et le répertoire CVSROOT. 5.3 Gestion des droits Il convient maintenant de faire en sorte que le dépôt appartienne au groupe de développement et accorder à celui-ci les droits en écriture : $ cd $ pwd $ chgrp -R ada DEPOT_CVS/ $ chmod -R g+w DEPOT_CVS/ 7 Il est important de noter à ce niveau que les utilisateurs ne doivent pas accéder directement au dépôt. Toute modification des sources présentes dans ce répertoire doit se faire par le biais de commandes cvs dont la forme générale est la suivante : $ cvs [options] <commande> [options commande] [fichier ...] Notez qu’en l’absence d’argument, la plupart des commandes ont un comportement ré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 côté utilisateurs 6.1 Accès au dépôt CVS fonctionne principalement en mode client/serveur (depuis la version 1.5) : les données sont centralisées sur le serveur et ordonnées en modules, et les dé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 définissant de nouvelles révisions pour les fichiers modifiés. On dénombre trois principales méthodes d’accès1 (voir figure 3) : – l’accès direct – l’accès en mode serveur (pserver) – l’accès en mode rsh/ssh (ext) La méthode rsh/ssh est souvent préférée à pserver car elle propose notamment le cryptage des informations qui transitent sur le réseau. Au LMSSMat, nous emploierons les méthodes d’accés direct et ssh. F IG . 3 – Accès au dépôt (accès direct, en mode serveur et rsh). Remarquez toutefois que, quel que soit le mode d’accès utilisé, l’utilisateur doit disposer d’un compte sur le serveur. Dans le cadre de ce TP, le dépôt sera placé sur thuya. Vous travaillerez donc en accès direct si vous vous logguez sur une des machines de notre réseau (NIS). 6.2 Mise en place des variables CVS Il faut maintenant renseigner quelques variables d’environnement. La première variable à renseigner est CVSROOT. Elle permet notamment de dire à CVS où se trouve le dépôt (l’adresse du server en cas d’accès de type pserver ou ssh etc, voir [8, 9] pour plus de détails). En accès direct, la variable CVSROOT se réduit simplement à : $ 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’accès en mode serveur GSSAPI (gserver) et l’accè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 grâce à l’option ”-m”. Dans le cas contraire, CVS ouvre l’éditeur par défaut (généralement vi) et vous demande d’entrer un commentaire. Il est possible de changer cet éditeur par défaut en renseignant la variable CVSEDITOR. $ setenv CVSEDITOR vim ! inutile pour ce TP Enfin, si vous travaillez en mode d’accès ssh, il faut positionner la variable CVS RSH à ssh : $ setenv CVS_RSH ssh ! inutile pour ce TP car CVS invoque rsh par défaut. 6.3 Mise en place des fichiers dans le dépôt Supposons que le développeur U1 dispose d’un code Fortran (deux fichiers .f90, un Makefile et un fichier html dans un sous-répertoire) dont il a testé 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 à développer ce code avec U2 et U3. Il veut donc placer les sources de son code dans le dépôt. Pour cela, il se place dans le ré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 là-dedans, c’est le paramètre module. C’est lui qui va créer un nouveau module sur le serveur CVS. vendortag (géné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 très importantes. Ainsi, pour placer son projet code f90 dans le dépô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 été ajoutés au dépôt (N pour ”New file”) alors que d’autres ont été ignorés (I pour ”Ignored”). Par dé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 indiqués dans un fichier appelé ”cvsignore”. On peut donc facilement modifier ce comportement par défaut (voir les références [8, 9]). Par exemple, on peut ajouter les ”*.mod” (générés à la compilation d’un code F90) à cette liste ... Une fois cette commande effectuée, le répertoire de dépôt DEPOT CVS, pré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 récupérer une copie de travail. Pour cela, ils se placent dans leur ré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 répertoire de travail des trois dé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 présence d’un répertoire CVS par répertoire/sous-répertoire. U1, U2 et U3 se placent maintenant dans leur répertoire code f90 et activent l’interface Tkcvs : $ tkcvs & 6.5 Archiver ses modifications L’utilisateur U1 décide de faire quelques changements dans le fichier exo2.f90 et le modifie grâce à son éditeur favori. NB : Pour gagner du temps, les modification à faire aux sources durant ce TP ont déjà été réalisées, il suffit à l’utilisateur concerné (ici U1) de les copier du ré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 : état du répertoire de travail. U1, U2 et U3 utilisent la commande cvs status à fin de connaı̂tre l’état de leur fichier local exo2.f90 par rapport au dépôt : $ cvs status exo2.f90 Notez qu’il est aussi possible d’examiner le statut d’un fichier local grâce à Tkcvs (cliquez sur ”Re-read the current directory” si besoin). U1 obtient à 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: 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) 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 dépôt grâce à 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 révision 1.1 à 1.2 (numéro incrémenté automatiquement par CVS). F IG . 7 – Principe de la commande commit. U1, U2 et U3 examinent à nouveau l’état de leur fichier local exo2.f90 grâce à la commande cvs en ligne (ou à Tkcvs) : $ cvs status exo2.f90 Résultat pour U1 : =================================================================== File: exo2.f90 Status: Up-to-date Working revision: Repository revision: Sticky Tag: Sticky Date: Sticky Options: 1.2 1.2 (none) (none) (none) Thu Nov 18 09:53:06 2004 /mnt/(...)/oofe/DEPOT_CVS/code_f90/exo2.f90,v La copie de travail de U1 est à jour par rapport au dépôt. Pour U2 et U3, la sortie écran est la suivante : =================================================================== File: exo2.f90 Status: Needs Patch Working revision: Repository revision: Sticky Tag: Sticky Date: Sticky Options: 1.1.1.1 Wed Nov 17 18:04:09 2004 1.2 /mnt/(...)/oofe/DEPOT_CVS/code_f90/exo2.f90,v (none) (none) (none) U2 et U3 ne sont plus Up-to-date car ils ne disposent que de la révision 1.1 de exo2.f90. Needs patch indique que le fichier n’a pas été modifié localement mais que la révision du dépôt a changé. Sous Tkcvs, il est possible de visualiser graphiquement les différentes versions du fichier dans le dépôt et votre position (figure 8). 14 F IG . 8 – Arborescence de exo2.f90 dans le dépôt vue par U1 (à gauche) et U2 (ou U3) (à droite). 15 6.6 Consulter les logs Pour en savoir plus sur les révisions des fichiers dans le dépôt, les utilisateurs peuvent consulter les ”logs” de ceux-ci. U1, U2 et U3 tapent donc : $ cvs log exo2.f90 Le résultat de cette commande est le mê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 désirent voir les modifications apportées par U1 au fichier exo2.f90. Ils demandent donc à CVS de comparer le fichier présent dans leur répertoire de travail avec la révision 1.2 du dépôt : $ cvs -Q diff -c -r1.2 exo2.f90 Index: exo2.f90 =================================================================== RCS file: /mnt/(...)/oofe/DEPOT_CVS/code_f90/exo2.f90,v 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 à droite de cvs) et indique à CVS d’être ”Quiet” alors que ”-c” est une option de la commande diff permettant d’afficher la sortie é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 répertoire de travail est identique à la révision 1.2 du dépôt. Les commandes diff et rdiff permettent faire de nombreux types de comparaison (utilisation de numéro de révision, de la date etc). Pour plus d’exemples voir la documentation [9, 8]. 6.8 Se mettre à jour par rapport au dépôt 6.8.1 Cas 1 : le fichier n’a pas été modifié localement U2 désire récuperer la nouvelle révision (enregistrée par U1). Il tape la commande suivante : $ cvs update exo2.f90 U exo2.f90 Comme vous l’avez sans doute déjà remarqué, CVS affiche des lettres (U, ?, A ...) dans ses messages de sortie. Voici leur signification : – U : le fichier a été créé dans votre répertoire de travail ou le fichier local (auquel vous n’avez fait aucune modification) a été mis à jour ; – A : le fichier est prévu pour être ajouté au dépôt et le sera après votre prochain archivage (commit) ; – R : le fichier est prévu pour être supprimé du dépôt et le sera après votre prochain archivage (commit) ; – M : le fichier a été modifié localement, il est possible que de nouveaux changements du dépôt aient été fusionnés. – C : le fichier contient un conflit qui doit être réglé manuellement avant votre prochain archivage (commit) ; – ? : le fichier local est inconnu du dépôt et il n’a pas été prévu de l’y ajouter. U2 vérifie l’état de l’ensemble de ses fichiers locaux : $ cvs status cvs status: Examining . =================================================================== File: Makefile Status: Up-to-date 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/Makefile,v (none) (none) (none) =================================================================== File: exo1.f90 Status: Up-to-date (...) =================================================================== File: exo2.f90 Status: Up-to-date 17 Working revision: Repository revision: Sticky Tag: Sticky Date: Sticky Options: 1.2 1.2 (none) (none) (none) Thu Nov 18 11:40:55 2004 /mnt/(...)/oofe/DEPOT_CVS/code_f90/exo2.f90,v cvs status: Examining HTML =================================================================== File: NOTE_DE_FIN.html Status: Up-to-date Working revision: Repository 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 récursif de la commande status lorsqu’aucun nom de fichier n’est précisé. U2 modifie cette révision de exo2.f90 en y ajoutant une autre ligne : $ pwd /mnt/(...)/mouronval/TP_CVS_U2/rep_de_travail/code_f90 $ cp ../../modifications/modif1_g2_exo2.f90 exo2.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 Checking in exo2.f90; /mnt/(...)/oofe/DEPOT_CVS/code_f90/exo2.f90,v <-- exo2.f90 new revision: 1.3; previous revision: 1.2 done Remarque : notez le comportement récursif de la commande commit lorsqu’aucun nom de fichier n’est précisé. Vous constatez maintenant que la dernière révision de exo2.f90 dans le dépôt est la 1.3. 6.8.2 Cas 2 : le fichier a été modifié localement mais les modifications ne sont pas en conflit avec les précédentes Le fichier exo2.f90 présent dans son répertoire de travail de U3 est une copie de la révision 1.1 du dépôt. En effet, si U3 tape : $ cvs status exo2.f90 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 /mnt/(...)/oofe/DEPOT_CVS/code_f90/exo2.f90,v (...) 18 Généralement, avant de commencer à modifier un fichier, il est souhaitable de faire un update pour récupérer sa dernière révision présente sur le dépôt (ici la 1.3). U3 ne se rappelle pas de cette recommandation et rajoute une ligne loin de celles ajoutées par les autres. $ cp ../../modifications/modif1_g3_exo2.f90 exo2.f90 U3 veut enregistrer sa modification dans le dépô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 à nouveau l’état de son fichier : $ cvs status exo2.f90 =================================================================== File: exo2.f90 Status: Needs Merge Working revision: 1.1.1.1 Wed Nov 17 18:04:09 2004 Repository revision: 1.3 /mnt/(...)/oofe/DEPOT_CVS/code_f90/exo2.f90,v (...) Needs Merge : la copie locale a été modifiée et le dépôt a changé entre temps. La solution est alors de faire une mise-à-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 comparé son fichier avec la révision 1.3 de exo2.f90 présente dans le dépôt grâce à la commande diff) : $ cvs -Q diff -c -r1.3 exo2.f90 (...) $ cvs update exo2.f90 RCS file: /mnt/(...)/oofe/DEPOT_CVS/code_f90/exo2.f90,v retrieving revision 1.1.1.1 retrieving revision 1.3 Merging differences between 1.1.1.1 and 1.3 into exo2.f90 M exo2.f90 Résultat : CVS a reussi à intégrer les modifications de U1 et U2 au fichier que U3 vient de modifier. Il ne reste à U3 qu’à l’archiver dans le dépôt. $ cvs commit -m "Ajout de desole dans exo2.f90" exo2.f90 Checking in exo2.f90; /mnt/(...)/oofe/DEPOT_CVS/code_f90/exo2.f90,v <-- exo2.f90 new revision: 1.4; previous revision: 1.3 done Il est possible de revenir au fichier avant sa mise-à-jour car CVS en laisse une copie dans le ré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 été modifié localement et sa mise-à-jour provoque un conflit U1 n’est pas à jour par rapport au dépôt (il en est encore à la révision 1.2 alors que le dépôt contient maintenant la révision 1.4). Lui aussi oublie de mettre à jour son fichier exo2.f90 avant d’y introduire des changements. Il modifie la même ligne que U3 : $ cp ../../modifications/modif2_g1_exo2.f90 exo2.f90 et demande à CVS d’archiver son fichier : $ cvs commit -m "Ajout d’une ligne dans exo2.f90" cvs commit: Examining . cvs commit: Up-to-date check failed for ‘exo2.f90’ cvs commit: Examining HTML cvs [commit aborted]: correct above errors first! Il constate qu’il n’est pas à jour et tente de faire un update pour ajouter à son fichier les modifications faites par U2 et U3 : $ cvs update cvs update: Updating . RCS file: /mnt/(...)/oofe/DEPOT_CVS/code_f90/exo2.f90,v retrieving revision 1.2 retrieving revision 1.4 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 à fusionner toutes les modifications (”C” = Conflit). U1 édite le fichier exo2.f90. Il voit que la modif faite par U2 a bien été incorporée mais que celle faite par U3 a généré un conflit. Celui est indiqué par des délimiteurs spéciaux : print *,"Erreur d’allocation" <<<<<<< exo2.f90 print *,"Verifier m et n" ======= print *,"Desole" >>>>>>> 1.4 stop 4 U1 doit procéder à une correction ”manuelle”, par exemple en remplaçant ces lignes par : print *,"Erreur d’allocation" print *,"Desole, Verifier m et n" stop 4 et faire un archivage : $ cvs commit -m "Ajout d’une ligne dans exo2.f90" cvs commit: Examining . cvs commit: Examining HTML Checking in 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’éviter ce genre de désagrément (conflits), mieux vaut effectuer de fréquentes mises-à-jour. Avant de passer à la suite, tous les utilisateurs font un update. $ cvs update Au passage U1, U2 et U3 jettent un coup d’oeil à l’arborescence des révisions des fichiers grâce à Tkcvs (figure 9). F IG . 9 – Tkcvs : arborescence de exo2.f90. 21 6.9 Gestion de versions Le code obtenu satisfait tout les développeurs. U2 décide donc de faire une version du projet regroupant les dernières révisions des différents fichiers présents dans son ré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 vérifient que l’étiquetage des fichier a bien eu lieu : $ cvs status -v cvs status: Examining . =================================================================== File: Makefile Status: Up-to-date 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/(...)/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: Repository 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 /mnt/(...)/oofe/DEPOT_CVS/code_f90/exo2.f90,v (revision: 1.5) (revision: 1.1.1.1) (branch: 1.1.1) cvs status: Examining HTML =================================================================== File: NOTE_DE_FIN.html Status: Up-to-date Working revision: 1.1.1.1 Wed Nov 17 18:04:09 2004 22 Repository revision: 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 numéros de révision des fichiers appartenant à une même version du projet ne sont pas obligatoirement identiques. 6.10 Utilisation des mots-clé CVS permet d’indiquer quelques mots-clé dans les fichiers sources, voire dans les documentations ou pages html. Ces motsclé seront automatiquement ”développés” par CVS lors de la sauvegarde du fichier sur le dépôt. Lorsque le fichier géré par CVS est un fichier source dans un langage particulier (C, fortran, html ...), les mots-clé de substitution doivent souvent être placés dans des zones où ils ne perturberont pas les compilateurs ou les interpréteurs : entre commentaires, dans des chaı̂nes de caractères, ... Le mot-clé le plus couramment utilisé est $Id$, dont ”l’expansion” indique : 1. le nom du fichier tel qu’il se présente sur le dépôt (d’où la présence du ,v additionnel) ; 2. le numéro de révision ; 3. la date et l’heure du dernier enregistrement (en temps universel coordonné) ; 4. l’identifiant (login) du dernier utilisateur qui a modifié le fichier ; 5. l’état assigné à la révision courante, par défaut Exp (pour ”expérimental”), mais aussi Stab (pour ”stable”), Rel (pour released, ”publié”, voire toute autre expression) ; 6. enfin, le cas échéant, l’identifiant de l’utilisateur qui a ”verrouillé” la révision. U1 décide de tester les mots-clé sur exo2.f90. Il l’édite et y ajoute en première ligne : ! $Id$ U2 fait de même pour exo1.f90 et U3 modifie le fichier NOTE DE FIN.html en y incluant la ligne suivante : <!-- $Id$ --> 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 Dès que l’archivage est terminé, chacun édite à nouveau son fichier et constate que CVS a ”développé” le mot-clé qui a été inséré : 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) : <!-- $Id: NOTE_DE_FIN.html,v 1.2 2004/11/19 16:45:13 oofe Exp $ --> Avant de passer à la suite, tous les utilisateurs font un update (attention U3 doit remonter hors du répertoire HTML). $ cvs update 6.11 Commande annotate Une autre commande intéressante est annotate : $ cvs annotate exo2.f90 CVS affiche à l’écran la dernière révision du fichier du dépôt et indique, pour chaque ligne, les modifications effectuées, le numéro de ré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 (mouronva 19-Nov-04): print *,"Merci !" 1.1 (mouronva 19-Nov-04): print *,"Entrez le nombre de colonnes :" 1.3 (mouronva 19-Nov-04): print *,"Merci aussi !" 1.1 (mouronva 19-Nov-04): read(*,*)m (...) 1.1 (mouronva 19-Nov-04): if (err /= 0) then 1.1 (mouronva 19-Nov-04): print *,"Erreur d’allocation" 1.5 (mouronva 19-Nov-04): print *,"Desole, Verifier m et n" 1.1 (mouronva 19-Nov-04): stop 4 (...) 1.1 (mouronva 19-Nov-04): end program ex02 24 6.12 Branches Nous allons voir maintenant comment créer une nouvelle branche (figure 10) de développement (par exemple pour corriger un bug sur une version de projet déjà distribuée). F IG . 10 – Exemple de branche. U3 définit une branche à 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’état de leur copie de travail : $ cvs status -v cvs status: Examining . =================================================================== File: Makefile Status: Up-to-date (...) =================================================================== File: exo1.f90 Status: Up-to-date Working revision: Repository revision: Sticky Tag: Sticky Date: Sticky Options: 1.2 1.2 (none) (none) (none) Fri Nov 19 16:47:29 2004 /mnt/(...)/oofe/DEPOT_CVS/code_f90/exo1.f90,v 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 Repository revision: 1.6 (...) Fri Nov 19 16:47:29 2004 /mnt/(...)/oofe/DEPOT_CVS/code_f90/exo2.f90,v Existing Tags: CORRECTION_Version_a_diffuser Version_a_diffuser release-tags vendor-tag (branch: 1.5.2) (revision: 1.5) (revision: 1.1.1.1) (branch: 1.1.1) cvs status: Examining HTML =================================================================== File: NOTE_DE_FIN.html Status: Up-to-date Working revision: 1.2 Repository revision: 1.2 (...) Fri Nov 19 16:45:13 2004 /mnt/(...)/oofe/DEPOT_CVS/code_f90/HTML 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) F IG . 11 – Tkcvs : création d’une branche. U1, U2 et U3 placent dans cette branche (figure 12) : 26 $ cvs update -r CORRECTION_Version_a_diffuser cvs update: Updating . U exo1.f90 U exo2.f90 cvs update: Updating HTML U HTML/NOTE_DE_FIN.html F IG . 12 – Tkcvs : après déplacement dans la nouvelle branche. $ cvs status -v cvs status: Examining . =================================================================== File: Makefile Status: Up-to-date (...) =================================================================== File: exo1.f90 Status: Up-to-date Working revision: Repository revision: 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/exo1.f90,v CORRECTION_Version_a_diffuser (branch: 1.1.1.1.2) (none) (none) 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) 27 =================================================================== File: exo2.f90 Status: Up-to-date Working revision: Repository revision: Sticky Tag: Sticky Date: Sticky Options: 1.5 Fri Nov 19 17:00:27 2004 1.5 /mnt/(...)/oofe/DEPOT_CVS/code_f90/exo2.f90,v CORRECTION_Version_a_diffuser (branch: 1.5.2) (none) (none) Existing Tags: CORRECTION_Version_a_diffuser Version_a_diffuser release-tags vendor-tag (branch: 1.5.2) (revision: 1.5) (revision: 1.1.1.1) (branch: 1.1.1) cvs status: Examining HTML =================================================================== File: NOTE_DE_FIN.html Status: Up-to-date Working revision: Repository 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: 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) 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" cvs commit: Examining . cvs commit: Examining HTML Checking in exo2.f90; /mnt/(...)/oofe/DEPOT_CVS/code_f90/exo2.f90,v new revision: 1.5.2.1; previous revision: 1.5 done <-- exo2.f90 Il revient ensuite à la branche principale et vérifie que l’opération s’est bien passée : $ cvs update -A cvs update: Updating . U exo1.f90 U exo2.f90 cvs update: Updating HTML U HTML/NOTE_DE_FIN.html 28 F IG . 13 – Tkcvs : branche après correction du bug. $ cvs status -v cvs status: Examining . =================================================================== File: Makefile Status: Up-to-date (...) =================================================================== File: exo1.f90 Status: Up-to-date (...) =================================================================== File: exo2.f90 Status: Up-to-date Working revision: 1.6 Repository revision: 1.6 (...) Sun Nov 21 15:08:12 2004 /mnt/(...)/oofe/DEPOT_CVS/code_f90/exo2.f90,v Existing Tags: CORRECTION_Version_a_diffuser Version_a_diffuser release-tags vendor-tag (branch: 1.5.2) (revision: 1.5) (revision: 1.1.1.1) (branch: 1.1.1) cvs status: Examining HTML =================================================================== File: NOTE_DE_FIN.html Status: Up-to-date Working revision: 1.2 Sun Nov 21 15:08:12 2004 29 Repository revision: 1.2 NOTE_DE_FIN.html,v (...) /mnt/(...)/oofe/DEPOT_CVS/code_f90/HTML/ 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) L’option -A (=reset) permet de supprimer les ”labels collants” (sticky tags). U2 compare la révision qu’il vient de récupérer à la dernière de la branche ”CORRECTION Version a diffuser” : $ cvs -q diff -c -r CORRECTION_Version_a_diffuser exo2.f90 Index: exo2.f90 =================================================================== RCS file: /mnt/(...)/oofe/DEPOT_CVS/code_f90/exo2.f90,v retrieving revision 1.5.2.1 retrieving revision 1.6 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 effectués dans la branche ”CORRECTION Version a diffuser” à la branche principale en réalisant une fusion : $ cvs update -j CORRECTION_Version_a_diffuser cvs update: Updating . RCS file: /mnt/(...)/oofe/DEPOT_CVS/code_f90/exo1.f90,v retrieving revision 1.1 retrieving revision 1.1.1.1 Merging differences between 1.1 and 1.1.1.1 into exo1.f90 RCS file: /mnt/(...)/oofe/DEPOT_CVS/code_f90/exo2.f90,v retrieving revision 1.5 retrieving revision 1.5.2.1 Merging differences between 1.5 and 1.5.2.1 into exo2.f90 cvs update: Updating HTML 30 RCS file: /mnt/(...)/oofe/DEPOT_CVS/code_f90/HTML/NOTE_DE_FIN.html,v retrieving revision 1.1 retrieving revision 1.1.1.1 Merging differences between 1.1 and 1.1.1.1 into NOTE_DE_FIN.html L’option -j (join) permet de réaliser la fusion entre deux branches. Le fichier local est maintenant différent de la révision 1.6 du dépôt (car CVS vient d’incorporer les changements effectués dans la branche ”CORRECTION Version a diffuser”) $ cvs diff exo2.f90 Index: exo2.f90 =================================================================== RCS file: /mnt/(...)/oofe/DEPOT_CVS/code_f90/exo2.f90,v retrieving revision 1.6 diff -r1.6 exo2.f90 47a48 > print *,"Suppression du bug grace a la branche" Il ne reste qu’à l’archiver dans la branche principale (voir figure 14) : $ cvs commit -m "Correction du bug par fusion avec branche CORRECTION" cvs commit: Examining . cvs commit: Examining HTML Checking in exo2.f90; /mnt/(...)/oofe/DEPOT_CVS/code_f90/exo2.f90,v <-- exo2.f90 new revision: 1.7; previous revision: 1.6 done 31 F IG . 14 – Tkcvs : après retour à la branche principale et fusion de la branche de correction. 6.13 Fin des travaux Vous avez terminé vos modifications. Votre copie de travail peut être effacée. Pour cela, placez-vous en amont du ré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 sûr que d’utiliser la commande Unix rm car CVS vérifie que vous avez bien archivé toutes vos modifications avant d’effacer le ré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 même chose que checkout, mais sans les informations de gestion interne de CVS. Cette copie, rangée dans le répertoire courant, n’est donc pas destinée à être modifiée. Testez la à 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 répertoire code f90 est créé dans le répertoire courant. Notez que la syntaxe géné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 récupérer, c’est la manière la plus simple et la plus sûre de récupérer une version précise du logiciel. – -D <date> indique qu’on veut les fichiers dans leurs révisions les plus récentes à la date indiquée (ex : 2001-05-29). 33 7 Conseils La lecture du chapitre 2 de la référence [8] est conseillée. 7.1 Se familiariser avec CVS Refaire le TP seul. Pour cela, récupérez les trois fichiers .tar présents sur le site web. Vous obtiendrez trois répertoires de travail indépendants (ce qui sera équivalent à trois users différents). Suivez ensuite les instructions du tutorial. 7.2 Quand faire un update, commit ... ? Règles de bon usage : 1. CVS ne dispense pas d’une communication active entre les membres de l’équipe. 2. Quand un membre commence à travailler sur le projet, il fait un checkout, et, sauf cas particulier, il n’en fera pas d’autre. 3. Un commit ne devrait être fait que pour une nouvelle version testée et validée d’un fichier ou de plusieurs fichiers. Souvenez-vous que si le commit échoue c’est qu’il est probablement nécessaire que vous fassiez d’abord un update. 4. A la suite d’un commit réussi, les autres membres de l’équipe devraient faire un update afin de récupérer les dernières modifications. 34 8 Pour aller plus loin 8.1 Ajout/suppresion de fichier Lorsque l’on souhaite inclure un nouvel élé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’après le prochain commit : $ cvs commit <nom_de_fichier> De la même manière, la suppression d’un fichier ne sera effective qu’aprè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 possibilité 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 méthode la plus simple est de dé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 précisant comme serveur thuya. Solution 2 (par ligne de commande) Tapez simplement : $ ntpdate thuya Pour plus de dé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 Références 10.1 CVS [1] The CVS Client. http ://www.lincvs.org/. [2] Site officiel de CVS. https ://www.cvshome.org/. [3] Introduction à 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) présentés à la journée CODICIEL, http ://maply.univ-lyon1.fr/spip/article.php3 ?id article=20111, Niveau dé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 complète mais difficile pour dé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 bientôt à la bibliothèque ECP, Niveaux débutant et avancé. [10] A. Lesné and O. Berger. Utilisation de CVS, 2000. http ://www.idealx.org/doc/cvs.fr.html. [11] A. Pedrono. CVS : principales fonctionnalités. Transparents, http ://www.imft.fr/cutis/cvs/CVS.pdf. 10.2 Autres systèmes de contrô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