Gestion de version/CVS

Attention ! Ne pas confondre CVS et CSV

CVS, acronyme de Concurrent Versions System, est un logiciel libre (licence GPL) de gestion de version.

CVS est documenté ici car il est le système de gestion de version le plus utilisé de par son ancienneté. Ses défauts de conception ont donné naissance à Subversion (SVN), ainsi qu'à Darcs : tout deux également libres.

Release : Supprimer proprement son espace de travail

On peut faire autant de checkouts qu'on veut, et parfois on se retrouve avec beaucoup d'espaces de travail qui ne servent plus. Mais avant de supprimer un tel répertoire, il faut faire attention à ne pas perdre de travail. La commande suivante vérifie si le répertoire ne contient pas de travaux non sauvegardés :

$ cvs release monprojet

Un résumé des éventuelles différences avec le repository apparaît. Si aucune de celles-ci n'est intéressante, supprimer le répertoire.

Renommer ou déplacer un répertoire ou un fichier

On ne peut pas. C'est une limitation conceptuelle de CVS. Il faut supprimer puis recréer. Dans le cas d'un répertoire à renommer, il faut créer un nouveau répertoire et déplacer les fichiers qui s'y trouvaient. Il ne faut pas supprimer l'ancien répertoire, sous peine de perdre son historique, donc de perdre les versions antérieures ! Ce n'est pas grave de garder ce répertoire car s’il est vide il ne sera pas créé lors des checkouts suivants.

Consulter une vieille version d'un fichier

Restaurer une version précédente d'un fichier

En principe, on n'a jamais besoin de le faire, mais ça peut arriver de vouloir annuler les modifications du dernier ou des derniers commit. Dans ce cas, bien identifier la version à restaurer (par exemple 1.14) et taper les commandes :

$ cvs -Q update -p -r 1.14 fichier.c > fichier.c
$ cvs commit fichier.c

Convention : Dans le commentaire du commit, il peut être bon de placer la phrase « Reverted to 1.14 » pour se rappeler d'où ça vient.

Ressusciter un fichier supprimé du repository

Après un « cvs rm -f fichier.c » un peu trop expéditif, on peut toujours faire renaître le fichier, dans le repository et dans son répertoire local. Il faut se souvenir du nom et de l'emplacement du fichier. Dans le répertoire où il se trouvait, taper la commande suivante :

$ cvs status fichier.c

Bien qu'il n'existe plus localement, cvs nous donne l'identifiant de la dernière version du fichier sur le tronc commun :

$ File: no file fichier.c		Status: Up-to-date
$    Working revision:	No entry for fichier.c
$    Repository revision:	1.6	/tests/proj/d/Attic/fichier.c,v

L'information que nous recherchons est « Repository revision », qui a ici pour valeur « 1.6 ». Utiliser cette valeur dans l'incantation suivante :

$ cvs -Q update -p -r 1.6 fichier.c > fichier.c

Le fichier est maintenant dans le répertoire local. Il ne reste plus qu'à l'ajouter (add) puis engager la mise à jour du repository (commit) :

$ cvs add fichier.c
$ cvs commit

Dans le commentaire du commit, il peut être bon de placer la phrase « Resurrected from 1.6 » pour se rappeler d'où ça vient.

History : Voir les dernières actions effectuées sur le repository

Quelqu'un a "commité" du code faux, et ça ne compile pas ? Pour connaître le nom du coupable, utilisez la commande suivante qui donne les liste des modifications sur le repository pendant les 3 derniers jours :

$ cvs history -ca -D "3 days ago"

Cette commande donne toutes les opérations de lecture/écriture sur le repository pour le module monprojet :

$ cvs history ae -m monprojet

Diff : Différence entre un fichier local et sa version du repository

On peut parfois oublier quelles modifications on a apporté à un fichier depuis le dernier commit. Pour connaître les différences entre sa version locale modifiée et la version du repository, on peut utiliser la commande suivante :

$ cvs diff fichier.c

Voir les différences entre plusieurs versions d'un fichier

$ cvs diff -r revision1 -r revision2 fichier

Restaurer la version du repository pour un fichier

Après avoir fait des tests en modifiant un fichier, on peut vouloir annuler ces modifications. Pour revenir à la version du repository, sans prendre en compte les modifications, il faut d'abord effacer le fichier local, puis l'updater :

$ rm fichier.c
$ cvs update fichier.c

Import : Intégrer un projet dans CVS

Nettoyer les fichiers temporaires.
Bien identifier les parties qui sont communes à plusieurs projets pour définir les modules. Dans le cas d'un projet de petite taille, tout peut aller dans un seul module.
Pour chaque module :
1. Se mettre dans le répertoire où sont les sources et répertoires.
2. Taper : “cvs import <nom-module> d1 d2”. d1 et d2 sont des textes bidons, utiles seulement dans des cas particuliers.
3. Remonter d'un répertoire, et renommer le répertoire dans lequel on était avec un nom qui fasse comprendre qu'on ne doit plus y toucher (exemple: monprojet.original). Éventuellement le mettre en lecture seule.
Créer d'éventuels alias de modules.
Et voilà. Pour commencer à travailler, il ne reste plus aux développeurs qu'à faire un checkout.

Aller voir ce qui se trouve dans le repository

Il est possible d'aller consulter directement le repository, mais les fichiers y sont stockés dans un format spécifique. Le plus simple et le plus confortable est de naviguer en utilisant par exemple le logiciel CvsWeb. Attention : On pourrait parfois être tenté de modifier directement le repository global. Il n'y a jamais besoin de le faire ! Ce serait un moyen très facile de perdre tout l'historique, ce qui aurait notamment pour conséquence l'impossibilité de faire des corrections dans les versions releasées.

Tag : Marquer des versions de fichiers

Il est parfois utile de marquer une version particulière d'un ou plusieurs fichiers, par exemple pour marquer le périmètre d'une amélioration. Par exemple, si je viens d'améliorer fichier1.c et fichier2.c pour corriger le bug BUG_6845, il peut être judicieux de taper la commande : cvs tag BUG_6845 fichier1.c fichier2.c S’il s'agit de tagger toute une arborescence, utiliser dans la commande : cvs rtag BUG_6845 monprojet

Tag -b : Créer une branche

Créer une branche MONPROJET_7_1_1_1 permet, plus tard, de récupérer cette version livrée en faisant un checkout avec l'option “-r”. Rien n'est dupliqué dans le repository, cette commande ajoute simplement un tag à tous les fichiers dans l'état où ils sont. Il faut d'abord se mettre dans son répertoire de développement, faire un cvs update pour vérifier que tout est à jour :

$ cvs update

Vérifier une dernière fois que tout est ok, packager le logiciel, faire la sortie officielle de cette version, puis tagger avec l'option -b :

$ cvs tag MONPROJET_7_1_1_1-trunk
$ cvs tag -b MONPROJET_7_1_1_1

Ensuite, les développeurs qui le souhaitent pourront travailler séparément sur le tronc commun, ou sur la branche. Cette commande crée deux espaces de travail, un pour la version de développement et un pour la version livrée 7.1.1.1 :

$ cvs checkout monprojet
$ mv monprojet monprojet_dev
$ cvs checkout -r MONPROJET_7_1_1_1 monprojet
$ mv monprojet monprojet_7111

Le tag MONPROJET_7_1_1_1-trunk n'est généralement pas utile, mais on peut en avoir besoin dans la situation bien particulière où on voudrait récupérer l'image du tronc commun tel qu'il était au moment de la création de la branche.

Reporter les améliorations d'une branche vers le tronc

Tout d'abord, se mettre dans une copie locale de la branche et tagger les fichiers dans lesquels se trouvent les améliorations (ou tout si c'est justifié) :

branche$ cvs tag mergeto_trunk_FIX1016 fichiers ...

Convention : J'ai pris l'exemple de FIX1016 mais on peut prendre n'importe quel identifiant qui soit unique au repository entier. Se mettre dans une copie locale du tronc et lancer cette commande :

tronc$ cvs update -j mergeto_trunk_FIX1016

Il y aura probablement de nombreux conflits à résoudre. Une fois que c'est fait, commiter et tagger:

tronc$ cvs commit fichiers ...
tronc$ cvs tag mergefrom_DEL_CAS_7_1_1_1_FIX1016 fichiers ...

MONPROJET_7_1_1_1 est un exemple qui correspond au nom exact de la branche.

Reporter les améliorations du tronc vers une branche

Tout d'abord, se mettre dans une copie locale du tronc et tagger les fichiers dans lesquels se trouvent les améliorations (ou tout si c'est justifié) :

tronc$ cvs tag mergeto_MONPROJET_7_1_1_1_AMELIORATION756 fichiers ...

Se mettre dans une copie locale de la branche et lancer cette commande :

branche$ cvs update -j mergeto_DEL_CAS_7_1_1_1_AMELIORATION756

Il y aura probablement de nombreux conflits à résoudre. Une fois que c'est fait, commiter et tagger :

branche$ cvs commit fichiers ...
branche$ cvs tag mergefrom_trunk_AMELIORATION1016 fichiers ...

Liens externes

(anglais) Site officiel (texte)
(français) Tutoriel CVS
(français) Labo-Linux : Utilisation de CVS
(français) Révisions, Versions et Branches sous Eclipse CVS
(français) APRIL PhpWiki - Cvs Howto : Très court, explique rapidement comment utiliser cvs checkout et cvs commit
(anglais) Red Bean CVS Book : Plus approfondi que la documentation officielle
(anglais) CvsGui : Site de WinCVS, une interface graphique pour Windows
(anglais) TortoiseCVS : Une autre et excellente interface graphique pour Windows, libre de surcroît !
(anglais) TkCVS : Une interface libre pour Unix/Linux, Windows, et MacOSX
(anglais) Collab.net — Tigris.org : Création d'une zone d'échange serveur
(anglais) Freepository.com : Création d'une zone d'échange serveur
(anglais) Wiki de la société Ximbiot