Installation et utilisation des clients CVS

TridenT

Cet article vous expliquera ce qu'est CVS, pourquoi et comment l'utiliser. Il décrit aussi l'utilisation des clients WinCVS et TortoiseCVS (à venir), pour les actions classiques et les plus complexes également. ♪

- Titre : Installation et utilisation des clients CVS

- Auteur : TridenT

- Parution : 1 août 2005

- Licence : Copyright ® 2005 TridenT. Aucune reproduction, même partielle, ne peut être faite de ce site et de l'ensemble de son contenu : textes, documents, images, etc. sans l'autorisation expresse de l'auteur. Sinon vous encourez selon la loi jusqu'à trois ans de prison et jusqu'à 300 000 € de dommages et intérêts.

Sommaire

- I. Préambule

- I-A. But du document

- I-B. Mots clés

- I-C. Référence

- II. Introduction à CVS

- II-A. CVS, c'est quoi ?

- II-B. Intérêt de CVS

- III. Terminologie du versionning

- III-A. Repository

- III-B. Module / Projet

- III-C. Update

- III-D. Commit

- III-E. Checkout

- III-F. Add

- III-G. Remove

- III-H. Tag

- III-I. Export

- III-J. Import

- III-K. Versions d'un fichier (REVISION)

- III-L. Livraisons d'un projet (TAG)

- III-M. Version de tête (HEAD)

- III-N. TAG collant (Sticky TAG)

- IV. Architecture de principe - Fonctionnement général

- V. Installation du client

- V-A. WinCVS

- V-B. Tortoise

- VI. Configuration

- VI-A. Configuration WinCVS

- VI-B. Configuration complémentaire conseillée

- VII. Fonctionnement de base des clients

- VII-A. WinCVS

- VII-A-1. Connexion au serveur CVS - Login

- VII-A-2. Déconnexion du serveur CVS - Logout

- VII-A-3. Importer un projet - Import

- VII-A-4. Obtenir une copie locale d'un projet - Checkout

- VII-A-5. Mettre à jour sa copie locale - Update

- VII-A-6. Archiver - Commit

- VII-A-7. Obtenir une synthèse des versions d'un fichier - Log & Graph

- VII-A-8. Ajouter des éléments - Add

- VII-A-9. Supprimer des fichiers - Delete

- VII-A-10. Marquer une livraison - Tag

- VII-A-11. Voir les différences entre deux versions - Diff

- VII-A-12. Résoudre les conflits - Conflict

- VIII. Fonctionnalités étendues

- VIII-A. Renommer un répertoire

- VIII-B. Renommer un fichier

- VIII-C. Obtenir une copie propre - Export

- VIII-D. Simuler une commande Update - Query update

- VIII-E. Créer une branche - Branch

- VIII-F. Obtenir une copie locale d'une branche - Update

- VIII-G. Merger deux versions - Merge

- VIII-H. Merger plusieurs versions - Merge multiple

- VIII-I. Éditer un fichier - Edit

- VIII-J. Édition exclusive d'un fichier - Reserved Edit

- VIII-K. Récupérer une version précédente d'un fichier

- VIII-L. Masquer des fichiers à l'affichage - cvsignore

- IX. Méthode de travail

- IX-A. Travailler à plusieurs sur CVS

- IX-B. Archiver des fichiers binaires

- IX-B-1. Le problème des fichiers binaires

- IX-B-2. Travailler avec les fichiers binaires

- X. Annexes

- XI. Remerciements

I - Préambule

I-A - But du document

Ce document a pour objectif de :

- présenter rapidement l'outil de gestion de version CVS ;

- présenter les programmes clients associés à CVS ;

- aider à l'installation et à la configuration des clients ;

- expliquer les opérations classiques ;

- expliquer quelques opérations plus complexes.

Note de l'auteur : pour l'instant, seul CVS et le client WinCVS seront expliqués dans ce document. Il sera mis à jour plus tard pour intégrer un client alternatif TortoiseCVS.

I-B - Mots clés

CVS, versionning, gestion de version, update, commit, tag, projet, logiciel, conflit.

I-C - Référence

Le site de CVS : https://www.cvshome.org/

Le site de WinCVS : http://www.wincvs.org/

Le site de TortoiseCVS : http://www.tortoisecvs.org/

II - Introduction à CVS

Objectif : comprendre dans les grandes lignes ce qu'est CVS.

II-A - CVS, c'est quoi ?

CVS (Concurrent Versions System) est un logiciel 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 Repository, le répertoire qui contient toutes les versions de tous les fichiers du projet.

CVS est un logiciel libre et gratuit, distribué sous licence GNU GPL. Il est disponible sous GNU/Linux, Unix, et Windows.

II-B - Intérêt de CVS

- Travailler à plusieurs sur le même projet.

- Travailler à plusieurs sur le même fichier (par exemple sur des fonctions différentes).

- Fusion automatique des modifications (sans conflit).

- Consulter l'historique des modifications d'un fichier (qui a fait quoi, quand, dans quelle version ?).

- Consulter les différences entre deux versions d'un fichier.

- Récupérer n'importe quelle version d'un projet ou d'un fichier.

- Gérer différentes versions d'un projet (par des branches).

III - Terminologie du versionning

Objectif : comprendre les termes utilisés dans ce document.

III-A - Repository

Le Repository désigne le système logique où sont archivés les fichiers des différents projets, ainsi que les informations relatives à chaque version.

III-B - Module / Projet

Nom caractérisant un projet/sous-projet disponible sur le serveur CVS.

III-C - Update

La commande update permet de synchroniser votre copie locale (working copy) avec le repository. Il s'agit de prendre en compte dans votre copie locale les modifications que d'autres ont pu valider entre-temps dans le repository.

III-D - Commit

La commande commit permet de mettre à jour le Repository avec les modifications faites en local.

III-E - Checkout

La commande checkout permet d'obtenir une copie locale (working copy) de la version la plus récente des fichiers du module dans votre répertoire courant

III-F - Add

Add est une commande qui permet d'ajouter des éléments. Elle est purement locale et n'a pas d'incidence immédiate sur le repository. Elle est généralement suivie d'une commit pour que la synchronisation avec le repository soit faite.

III-G - Remove

Pour indiquer qu'un ou plusieurs fichiers ne doivent plus être pris en compte dans le repository. Attention, remove est, comme add, une commande purement locale, on ne peut donc pas se passer du commit qui suit.

III-H - Tag

À certaines étapes du développement, il est utile de poser un jalon qui permettra, plus tard, de retrouver l'ensemble des fichiers figés dans un état précis (en terme de version). Ceci correspond à créer une livraison. Une livraison est créée en posant un tag (ou identificateur de livraison).

III-I - Export

Cette commande est en quelque sorte l'inverse de import : elle fournit une copie de distribution et donne la même chose que checkout, mais sans les informations de gestion interne de CVS. Cette copie n'est donc pas destinée à être modifiée.

III-J - Import

Cette commande permet d'importer un nouveau projet dans le repository. C'est la première opération à effectuer pour initialiser un projet.

III-K - Versions d'un fichier (REVISION)

CVS mémorise chaque version successive d'un même fichier. On peut retrouver une version précise d'un fichier grâce à son numéro de version. Les numéros de versions des fichiers (et leurs contenus) sont gérés implicitement par CVS. Ce sont des numéros du genre 1.1 ou 2.1.3.4. À chaque commit d'un fichier une nouvelle version est créée (seulement si le fichier a été réellement modifié). Par défaut les commandes d'extraction checkout et export donnent la version la plus récente d'un fichier.

III-L - Livraisons d'un projet (TAG)

En général, on ne manipule pas un fichier individuellement, mais plutôt l'ensemble des fichiers constituant un projet. Pour cela, CVS permet de gérer les livraisons successives d'un même projet. Une livraison est identifiée par un tag du genre appli_v1_0 qui doit être posé explicitement avec la commande tag. Une livraison est un ensemble de couples (fichier, numéro de version). Les différents fichiers d'une livraison n'ont pas forcément le même numéro de version. Par exemple la livraison appli_v1_0 pourrait correspondre aux fichiers « util.h, 1.1 », « util.c, 1.3 » et « main.c, 1.2 ». Un tag devrait avoir une forme standard définie clairement par l'équipe projet. Par défaut les commandes d'extraction checkout et export donnent la livraison la plus récente.

III-M - Version de tête (HEAD)

La version de tête désigne la version la plus récente dans le tronc principal d'un projet.

III-N - TAG collant (Sticky TAG)

Il est parfois utile de vouloir bloquer un fichier à une révision particulière (ancienne) dans sa copie locale, sans qu'il soit remplacé par une version plus récente. Cette opération s'appelle mettre un TAG collant sur un fichier. Un update classique ne modifiera jamais ce fichier. Pour supprimer un TAG collant, il faut demander un update en cochant « Remove any sticky TAG ».

IV - Architecture de principe - Fonctionnement général

Objectif : expliquer le fonctionnement global de CVS.

CVS maintient un ensemble de fichiers dans un répertoire qu'on appelle repository. Toutes les versions successives d'un fichier sont stockées dans le repository (rien ne se perd) et chaque version d'un fichier est étiquetée avec un numéro de version.

Un utilisateur autorisé peut obtenir auprès du serveur CVS une copie locale (working copy) de ces fichiers dans son espace de travail (working space) par la commande checkout. Par défaut, la copie locale contient la version la plus récente des fichiers.

Il peut ensuite modifier (par exemple, avec un éditeur de texte) ces fichiers puis mettre à jour le repository par la commande commit. Lors du commit, chaque fichier réellement modifié fait l'objet d'une nouvelle version. Par exemple, si une copie locale d'un fichier est obtenue en version 1.4, que cette copie est ensuite modifiée, puis réintroduite dans le repository, une nouvelle version de ce fichier est stockée avec le numéro de version 1.5 (la version 1.4 existe toujours ! ).

Il peut aussi mettre à jour sa copie locale avec les nouvelles modifications incorporées dans le repository par d'autres développeurs, grâce à la commande update.

Enfin il peut poser un tag sur le module afin d'identifier la livraison correspondant à l'état courant des fichiers.

Voici un schéma indiquant le sens des transferts d'informations entre le Repository et les copies locales des utilisateurs :

V - Installation du client

Objectif : guider l'utilisateur dans l'installation des clients CVS.

V-A - WinCVS

Le fichier d'installation de la dernière version de WinCVS se trouve à cette adresse : http://sourceforge.net/project/showfiles.php?group_id=10072&package_id=12664

Seule exception, pour Windows 95, il faut utiliser celui-ci : http://prdownloads.sourceforge.net/cvsgui/WinCvs120.zip?download

Utiliser les options d'installation par défaut (Full installation, Create contextual menu)

V-B - Tortoise

Le fichier d'installation de la dernière version de Tortoise se trouve à cette adresse : http://www.tortoisecvs.org/download.shtml

VI - Configuration

Objectif : Guider l'utilisateur à configurer pas à pas son client CVS

Seuls les champs à modifier ou importants pour la configuration seront renseignés ci-dessous. Pour les autres champs, se fier aux copies d'écran, ou à la documentation en ligne du logiciel pour les explications.

VI-A - Configuration WinCVS

Suit une illustration du Menu Admin > Preference, onglet par onglet

Onglet General

Authentication : Sélectionner le mode du serveur CVS
Path : Chemin vers votre projet
Host Adress : le serveur hôte
User Name : indiquer votre login
CVSROOT : Cette ligne se remplit automatiquement avec les informations rentrées précédemment. Ne pas modifier

Onglet Globals

Checkout ReadOnly :
Normalement, il est préférable de récupérer les fichiers avec l'attribut
READ_ONLY. Cela évite de modifier un fichier accidentellement.

Onglet CVS Setup

Home : Sélectionner un répertoire de sauvegarde des fichiers de configuration de WinCVS.

Onglet WinCVS

External Diff : Cocher cette option et sélectionner le chemin de l'outil de comparaison. Il est conseillé d'utiliser Compare&Merge (voir Annexe Outils) Default editor : Sélectionner le chemin de l'éditeur de fichier qui sera utilisé par défaut. Il est conseillé d'utiliser PsPAD (voir Annexe Outils)
Settings : Sélectionner un répertoire où enregistrer la configuration des différents projets (un sous répertoire du HOME précédemment configuré par exemple).

VI-B - Configuration complémentaire conseillée

En travaillant avec WinCVS, il est intéressant d'avoir une vue rapide des fichiers nouveaux et modifiés en local depuis le dernier commit. Pour cela, voici les quelques options à activer :

View > File Filter > Show all commitable files only : permet de ne voir que les fichiers « commitable », ceux qui ont été modifiés par rapport au repository ;

View > File Filter > Show Missing only : permet d'afficher les fichiers effacés en local, mais encore présents dans le répository. Cette vue permet de vérifier qu'un fichier n'a pas été effacé par erreur dans la copie locale ;

View > File Filter > Show Unknown only : affiche les fichiers inconnus de CVS, qui ne sont pas dans le repository. Cela représente éventuellement des fichiers nouveaux à intégrer au repository.

Note : il est aussi possible de masquer à l'affichage certains types de fichiers par extension, ou des répertoires, à l'aide de la commande CVSIGNORE.

Menu > View > Flat view : permet d'avoir une vue récursive du répertoire courant, c'est-à-dire incluant les fichiers de tous les sous répertoires.

VII - Fonctionnement de base des clients

Objectif : expliquer les commandes de base de CVS à travers les différents clients.

VII-A - WinCVS

Nous admettrons que WinCVS est en cours d'exécution.
La plupart des commandes du menu sont disponibles en cliquant simplement sur le bouton droit de la souris après avoir sélectionné un élément.

VII-A-1 - Connexion au serveur CVS - Login

Pour effectuer des opérations sur le serveur CVS, il faut être identifié par la commande login. Une fois identifié, le couple login/mot de passe est stocké en cache et il n'y a plus besoin de s'identifier (sauf en cas de déconnexion).

VII-A-2 - Déconnexion du serveur CVS - Logout

La commande logout permet de se déconnecter de l'identité en cours. Il n'y a aucun intérêt à demander une telle opération, sauf pour s'identifier sous un nom différent.

VII-A-3 - Importer un projet - Import

Objectif : Créer la version de base du projet dans le repository
Prérequis : Disposer d'une version du projet en local.

Menu > View > Browse Location > Change : Indiquer la racine du répertoire du projet

Dans l'explorateur de gauche, sélectionner le projet et Menu > Remote > Import Module

Une fenêtre de confirmation apparaît. Elle présente tous les types de fichiers trouvés, et le format dans lequel ils seront archivés : TEXT ou BINARY. Vérifier et ajuster les formats. Généralement, WinCVS se débrouille plutôt bien, et il suffit de le laisser faire.

WinCVS demande ensuite quelques informations concernant le projet à importer.

Onglet Import settingsRepository path : donner le nom du projet comme chemin
Don't create vendor branch or release tags : Cocher pour ne pas créer de branche initiale (recommandé)
Fenêtre Log message : Entrer les informations du projet qui vous semblent utiles.

WinCVS envoie les fichiers dans le repository. La fenêtre de résultat doit normalement nous dire que tout s'est bien passé.

No conflicts created by this import
***** CVS exited normally with code 0 *****

Il ne reste plus qu'à vérifier que le projet est bien archivé en se reportant à la section « Récupérer un projet -Checkout ».

VII-A-4 - Obtenir une copie locale d'un projet - Checkout

Objectif : récupérer un projet archivé.
Prérequis : disposer d'une version du projet dans le repository.

Il est préférable d'avoir un répertoire de destination vide. Si le projet précédent l'import se trouve encore dans le répertoire, il vaut mieux le déplacer ou le renommer avant d'effectuer cette opération.

Menu > Remote > Checkout Module

Onglet Checkout settings

Module name : Donner le nom du module à récupérer
Local folder to check out : Indiquer le nom du répertoire de travail sans le nom du projet (un sous répertoire sera créé).
Valider par OK.

WinCVS va donc récupérer la version en cours (HEAD) du projet sélectionné.
La fenêtre de gauche présente l'arborescence créée, ainsi que la liste des fichiers du projet.
La petite coche dans le répertoire symbolise l'appartenance du répertoire au repository CVS.
La version est donc présente en local. Si vous venez de faire un import, vous pouvez vérifier par une comparaison que la version importée est identique à celle récupérée.

VII-A-5 - Mettre à jour sa copie locale - Update

Objectif : mettre à jour la copie locale du module avec d'éventuelles modifications faites par d'autres personnes.
Prérequis : disposer d'une version du projet dans le repository, et disposer d'une version en local.

Dans tous les cas, l'update est sans danger pour vos fichiers locaux, c'est-à-dire qu'aucune modification ne sera perdue.

Sélectionner l'élément à mettre à jour (module, dossier ou fichier) Menu > Modify > Update Selection

Create missing directories that exist in the repository : Crée les répertoires qui existent dans le repository, mais pas en local. Il faut cocher cette option, elle est utile lorsque d'autres personnes ont créé des répertoires de leur côté.

La copie locale est mise à jour.

VII-A-6 - Archiver - Commit

Objectif : archiver des modifications faites en local.
Prérequis : disposer d'une version du projet dans le repository, et d'une copie locale modifiée.

Généralement, avant tout commit, il est important de faire un update avant pour s'assurer d'avoir la dernière version en cours. Dans WinCVS, les fichiers modifiés en local apparaissent en rouge avec un état « modified ».

Pour intégrer ces modifications dans le repository, il suffit de sélectionner un élément (généralement le répertoire racine) et de lancer la commande commit.

Menu > Modify > Commit

Onglet Commit settings :

Log message : Entrer le commentaire associé aux modifications effectuées.

Confirmer par OK.

Les modifications vont être intégrées au repository. Le numéro de révision des fichiers modifiés sera incrémenté d'une unité.

VII-A-7 - Obtenir une synthèse des versions d'un fichier - Log & Graph

Objectif : obtenir des informations sur la vie d'un fichier
Prérequis : disposer d'une version du projet dans le repository et d'une copie locale.

Il y a deux façons d'obtenir des renseignements sur un fichier : le log, purement textuel, et son équivalent visuel le graph.

LOG

Sélectionner un élément, puis Menu > Query > Log
WinCVS affiche alors l'historique des versions du fichier dans la fenêtre de statut.

----------------------------
Revision : 1.21
Date : 2005/5/25 21:7:58
Author : 'trident'
State : 'Exp'
Lines : +5 -3
Description :
Added Conditional defines option
Fixed parsing of conditional defines inside source code
Fixed parsing error on an ELSEIF directive (Tracker 1203034)
----------------------------
Revision : 1.20
Date : 2005/4/25 21:38:27
Author : 'trident'
State : 'Exp'
Lines : +4 -2
Description :
Fixed Library issue (memory leak)
Added a new nice wizard
Added list of include and exclude files/folders in project configuration (Tracker
971492)

Graph

Sélectionner un élément, puis Menu > Query > Graph

WinCVS affiche alors un arbre des versions avec les TAG associés. En cliquant sur une révision ou un TAG, WinCVS donne plus de détails comme la fonction de LOG précédente.

VII-A-8 - Ajouter des éléments - Add

Objectif : ajouter des éléments au repository.
Prérequis : disposer d'une version du projet dans le repository, d'une copie locale et de nouveaux éléments, fichier(s) et/ou dossier(s).

Si les fichiers à ajouter sont dans un nouveau répertoire, il faut d'abord ajouter le répertoire au repository, et ensuite les fichiers.

Nouveau fichier

Dans WinCVS, le nouveau fichier sera marqué comme « Unknown »

Sélectionner le fichier, puis Menu > Modify > Add selection Si le fichier est de type binaire, il est préférable d'utiliser « Add binary ». Dans le cas d'un fichier unicode, utiliser « Add Unicode ».
Le fichier est maintenant marqué comme « Modified » avec une icône « A » pour Added.

Pour l'intégrer définitivement au repository, il faut lancer la commande commit.

Nouveau répertoire

Dans WinCVS, le nouveau répertoire aura une icône non cochée. Cela indique qu'il n'appartient pas au repository.

Sélectionner le répertoire.
Menu > Modify > Add selection

Le répertoire est maintenant marqué avec une coche, et sera donc inclus dans le repository.
Il est maintenant possible d'ajouter les nouveaux fichiers du répertoire comme indiqué plus haut.

VII-A-9 - Supprimer des fichiers - Delete

Objectif : supprimer un élément du projet dans le repository Prérequis : Disposer d'une version du projet dans le repository, d'une copie locale, et d'un élément à effacer.

Le fichier ne sera pas vraiment effacé du repository, mais marqué comme tel dans les révisions suivantes.
Ainsi, il sera toujours possible de récupérer une version ancienne avec ce fichier.

Sélectionner l'élément à supprimer.
Menu > Modify > Remove

Le fichier est alors noté en rouge avec comme état « Removed ».

Le fichier sera marqué comme effacé dans le repository lors du prochain commit.
Note : si l'élément a déjà été physiquement effacé du répertoire de travail, il sera toujours présent dans la liste, mais noté comme « missing ». La procédure pour l'effacer du repository reste la même.

VII-A-10 - Marquer une livraison - Tag

Objectif : poser un jalon sur une version
Prérequis : disposer d'une version du projet dans le repository que l'on veut marquer.

Il est possible de marquer un module complet, ou seulement une sélection (et son contenu). La pratique la plus courante est de marquer un répertoire racine.

Sélectionner l'élément à marquer, puis Menu > Modify > Create a tag on selection

New tag name : écrire le nom du tag à ajouter.
Attention ! CVS n'autorise pas les caractères ‘.', ni ‘,'. Les remplacer par des underscores ‘_'.
L'élément sélectionné et son contenu sont marqués du tag dans le repository.

VII-A-11 - Voir les différences entre deux versions - Diff

Objectif : comparer deux versions de fichiers
Prérequis : disposer d'une version du projet dans le repository.

Sélectionner un élément, puis Menu > query > Diff selection Plusieurs cas se posent, selon la révision des fichiers à comparer.

Comparaison entre copie locale et repository

Cela permet de voir quelles modifications ont été apportées depuis le fichier original

Comparaison entre copie locale et version spécifique du repository

Indiquer le TAG, la banche, ou la date de la révision à comparer à la copie locale.

Comparaison entre deux versions spécifiques du repository

Indiquer le TAG, la branche, ou la date des révisions à comparer.

VII-A-12 - Résoudre les conflits - Conflict

Objectif : résoudre le conflit provoqué par la modification du même fichier par plusieurs personnes.
Prérequis : disposer d'une version du projet dans le repository, d'une copie locale, et d'un fichier en conflit.

Un conflit peut se produire lorsqu'une personne demande un update d'un fichier modifié par lui-même, mais modifié aussi dans le repository depuis son dernier update.

CVS se débrouille généralement pour fusionner automatiquement les modifications lors d'un update, sauf lorsque les mêmes portions d'un fichier ont évolué.

Le fichier est alors noté en rouge dans WinCVS avec comme état « Conflict ».

Le fichier est alors annoté par CVS en encadrant les zones de conflit.
Il faut donc éditer le fichier et résoudre le conflit (éventuellement par un Diff si les conflits sont nombreux).
Ensuite, il faudra faire un commit pour intégrer ces modifications.

Attention : merger des fichiers binaires n'est pas toujours possible, il faut donc limiter au maximum le risque de conflit sur ces fichiers. Pour résoudre ce problème, voir la section Gestion des demandes d'édition.

VIII - Fonctionnalités étendues

Objectif : expliquer les commandes plus complexes de CVS à travers les différents clients

WinCVS/Tortoise.

VIII-A - Renommer un répertoire

Objectif : changer le nom d'un répertoire déjà archivé.
Prérequis : disposer d'une version du projet dans le repository et d'un répertoire.

Aujourd'hui, avec la version actuelle de CVS, il n'est pas possible de renommer directement un répertoire et d'en garder l'historique. Cette opération se résume donc à une suppression du répertoire actuel (remove), suivie de la création du nouveau répertoire (add). L'historique n'est pas gardé comme on le voudrait, mais il est toujours possible de récupérer une ancienne version.

VIII-B - Renommer un fichier

Objectif : Changer le nom d'un fichier déjà archivé.Prérequis : Disposer d'une version du projet dans le repository et d'un fichier.

Comme pour les répertoires, il n'est pas possible avec la version actuelle de CVS de renommer directement un fichier. Il faut donc supprimer le fichier actuel (remove) puis ajouter le fichier avec le nouveau nom (add).
L'historique n'est pas gardé comme on le voudrait, mais il est toujours possible de récupérer une ancienne version.

VIII-C - Obtenir une copie propre - Export

Objectif : obtenir une version livrable d'un module.
Prérequis : disposer d'une version du projet dans le repository.

Le terme « copie propre » signifie en fait une copie sans données d'archivage.
Un checkout sert à avoir une copie locale de travail, donc avec les répertoires CVS, un export sert à livrer une version sans ces répertoires CVS.

Onglet Checkout settings

Module name : Donner le nom du module à récupérer

Local folder to check out : Indiquer le nom du répertoire de travail sans le nom du projet (un sous répertoire sera créé).

Onglet Checkout options

Do not create CVS administrative directories : à cocher pour demander l'export. Valider par OK.

VIII-D - Simuler une commande Update - Query update

Objectif : voir ce que donnerait une commande Update sans la lancer.Prérequis : Disposer d'une version du projet dans le repository.

L'intérêt de simuler un Update sans le réaliser permet de ne pas modifier les fichiers en local. Sélectionner le répertoire ou le module impacté, puis Menu > Query > Query Update

Le résultat est visible dans la fenêtre de messages :

cvs -n update -P (in directory D:\Projets\Ex\DelphiCodeToDoc\Test\)
? .cvsignore
? TestCases.todo
? UnitaryTests
? TestCases/WarnWhenEmptyTag/WarnWhenEmptyTAG.out
cvs update: Updating .
cvs update: Updating IntegrationTests
A IntegrationTests/ThingsAfterEnd.pas
cvs update: Updating IntegrationTests/DotNETSyntax
A IntegrationTests/DotNETSyntax/DelphiNetClass.pas
cvs update: Updating IntegrationTests/Options
cvs update: Updating IntegrationTests/Tags
cvs update: Updating TestCases

Les répertoires et fichiers sont scannés, préfixés du code lettre correspondant. Voir Annexe CODE_LETTRE

VIII-E - Créer une branche - Branch

Objectif : créer une version en parallèle du tronc commun .
Prérequis : disposer d'une version du projet dans le repository.

À venir …

VIII-F - Obtenir une copie locale d'une branche - Update

Objectif : récupérer une version spécifique en local.
Prérequis : disposer d'une version du projet dans le repository et d'une branche existante.

À venir …

VIII-G - Merger deux versions - Merge

Objectif : fusionner les modifications de deux versions.
Prérequis : disposer de deux versions d'un module dans le repository.

À venir …

VIII-H - Merger plusieurs versions - Merge multiple

Objectif : fusionner les modifications de plusieurs versions.Prérequis : Disposer de plusieurs versions d'un module dans le repository.

À venir …

VIII-I - Éditer un fichier - Edit

Objectif : gérer la modification des fichiers.
Prérequis : disposer d'une version du projet dans le repository.

Généralement, lors d'un checkout ou après un commit, les fichiers du module passent en lecture-seule. Il faut donc demander pour chaque fichier à passer en lecture-écriture . Cette méthode permet de verrouiller les fichiers qui n'ont pas à évoluer et d'éviter une modification accidentelle.

Pour modifier l'attribut de lecture-seule d'un fichier, il existe deux méthodes :

- dans WinCVS par la commande Edit ;

- dans l'explorateur ou tout autre éditeur.

- Par WinCVS, cette commande permet de notifier au serveur CVS qu'une personne édite ce fichier, et permet de voir la liste des éditeurs par exemple.

- Par l'explorateur, le serveur CVS ne sera pas au courant de la modification du fichier, et ne pourra donner d'information à ce sujet.

Conseil d'utilisation : il est recommandé de n'utiliser que la commande Reserved Edit pour certains types de fichiers. La commande Edit ne présente pas forcément davantage dans le cas de fichier texte mergeable.

VIII-J - Édition exclusive d'un fichier - Reserved Edit

Objectif : gérer la réservation des fichiers.
Prérequis : disposer d'une version du projet dans le repository.

Il est parfois utile de savoir si une personne édite un fichier avant de l'éditer soi-même. Dans le cas des fichiers binaires, cette information est vitale pour éviter des conflits difficiles à gérer. Une des solutions est donc d'utiliser la commande d'édition réservée. Cette commande vérifie si une personne a déjà demandé une édition, par un Edit ou Reserved Edit, et autorise la modification dans le cas contraire.

Menu > Trace > Reserved Edit

Si un fichier est déjà en cours d'édition, CVS renverra une erreur en donnant des informations sur l'éditeur, comme le nom, la date et l'heure de la demande d'édition :

cvs edit -c "Serveur.doc" (in directory D:\PreDev\WinCVS\DocumentsOutils\)
Serveur.doc trident Tue Oct 5 13:24:32 2004 GMT pc-dev
D:\PreDev\WinCVS\Copie de DocumentsOutils
cvs [edit aborted]: Files being edited!
***** CVS exited normally with code 1 *****

VIII-K - Récupérer une version précédente d'un fichier

Objectif : voir ce que donnerait une commande Update sans la lancer.
Prérequis : disposer d'une version du projet dans le repository.

À venir …

VIII-L - Masquer des fichiers à l'affichage - cvsignore

Objectif : masquer des fichiers dans l'explorateur de WinCVS.Prérequis : Disposer d'une version du projet dans le repository.

IX - Méthode de travail

Objectif : acquérir une méthode pour travailler à plusieurs développeurs sur CVS, en réduisant les risques de conflit.
Prérequis : disposer d'une version du projet dans le repository.

IX-A - Travailler à plusieurs sur CVS

Objectif : voir ce que donnerait une commande Update sans la lancer.
Prérequis : disposer d'une version du projet dans le repository.

IX-B - Archiver des fichiers binaires

Objectif : voir ce que donnerait une commande Update sans la lancer.
Prérequis : disposer d'une version du projet dans le repository.

L'utilisation la plus commune de CVS est d'archiver des fichiers texte. Avec ce genre de fichiers, CVS peut fusionner des révisions, afficher les différences entre les révisions visuellement. Cependant CVS a aussi la capacité d'archiver les fichiers binaires. Par exemple, on pourrait archiver dans CVS un site Web comprenant des fichiers texte et des images binaires.

IX-B-1 - Le problème des fichiers binaires

Une fonction de base de CVS est de montrer les différences entre deux révisions de fichier. Par exemple, si une personne archive une nouvelle version d'un fichier, une autre peut vouloir regarder le delta et déterminer si les changements sont bons.
Pour des fichiers texte, CVS fournit cette fonctionnalité par l'intermédiaire de la commande de diff. Pour les fichiers binaires, il peut être possible d'extraire les deux révisions et puis de les comparer avec un outil externe (par exemple, un logiciel de traitement de texte a souvent un tel dispositif).

S'il n'existe pas un tel outil, on doit tracer les changements par l'intermédiaire d'autres mécanismes, tels que pousser des personnes à rédiger des messages de log complet, et espérer qu'ils reflètent les changements réels.

Une autre fonctionnalité de CVS est sa capacité à fusionner deux révisions. Ceci se produit dans deux contextes :

- le premier est quand les utilisateurs font des changements dans leur copie locale, et font un commit ;

- le second est lorsqu'un utilisateur demande explicitement un merge par la commande update-merge.

Dans le cas des fichiers textes, CVS peut fusionner les changements indépendants, et signale un conflit le cas échéant. Avec les fichiers binaires, le meilleur que CVS puisse faire est de présenter les deux copies du fichier, et laisser le soin à l'utilisateur de résoudre le conflit. L'utilisateur peut choisir une copie ou l'autre, ou peut exécuter un outil externe de merge qui reconnaît ce format. Noter que ce genre de merge est laissé à l'appréciation de l'utilisateur, et comporte donc un risque d'erreur (comparé à un merge automatique).

Ce processus est actuellement indésirable, et le meilleur choix est de l'éviter au maximum. Voici une méthode permettant d'éviter au mieux les risques :

IX-B-2 - Travailler avec les fichiers binaires

Voici quelques règles qui permettent de s'affranchir des problèmes de fichiers non mergeables.

- Tout fichier non mergeable doit être importé au départ au format binaire.

- Avant de modifier un fichier binaire en local on réalise un update pour être sûr d'avoir la dernière version.

- Pour modifier un fichier binaire, on demande une édition réservée (Reserved Edit) pour être le seul à le modifier.

- Une fois le fichier binaire modifié et testé dans le reste du module, il est intéressant d'appliquer un commit au plus tôt.

RAPPEL : plus les couples update/commit sont fait rapidement, moins il y a de risques d'avoir des conflits dans les fichiers.

X - Annexes

Code lettre d'action CVS

Code lettre

Signification

Description

U

Updated

Le fichier a été modifié, mais ne présente pas de conflit

C

Conflict

Ce fichier présente un conflit

M

Merged

Ce fichier a été mergé automatiquement par CVS

XI - Remerciements

Merci à Bestiol d'avoir relu (et corrigé) mes vilaines fautes un peu partout.