The GIMP
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.
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
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 ...