Petit cours sur CVS (par Marc Poinot)

Je me permets (excusez...) de faire quelques rappels sur CVS. V'la un p'tit cours (donne' en DESS). Les experts CVS peuvent s'affranchir de la lecture, ou encore faire des commentaires. Je viens de lire la page de IDEALX, elle est tres bien et elle est en francais (Olivier va m'inviter au resto ;)

Elle decrit les commandes de bases et la discussion ci-dessous essaie plutot de donner des idees globales sur l'outil. Et puis, ca m'a bien detendu d'ecrire des trucs comme ca !

Note: Tout ce qui est ecrit est parfaitement libre d'utilisation.

Enfin, en conclusion: sauter en parachute necessite un parachute. Le parachute est un outil et son utilisation necessite une procedure. Pour utiliser CVS il *faut* des procedures. Par exemple: tirer sur l'anneau d'ouverture avant de lire 3 metres sur l'altimetre ;)

-- CVS est un outil de developpement dont la fonction est de gerer les sources(1). Il archive les sources, il gere les deltas entre les evolutions d'un fichier source(2), il propose un serveur pour les acces simultannes. La particularite de CVS est d'etre particulierement simple et souple, de plus il est tres bien adapte au travail parallele, et il est libre d'utilisation.

Le fonctionnement est le suivant:

Une base commune de fichiers est archivee sur un site unique, un serveur se charge de tous les acces a cette base (aussi connue comme repository).
Chaque utilisateur demande une copie local de l'arbre des sources. Il utilise un client CVS qui tourne sur la machine locale et reconstruit l'arbre des sources. Il ajoute egalement des repertoires
Tant que vous ne faites aucune commande CVS, votre arbre local ne connait pas le repository.
Quand vous faites une commande, le client interroge le serveur pour lui demander son avis. Les grandes commandes sont: * Le client demande une mise a jour de son arbre local -> Copie complete de l'arbre en local -> checkout -> mise a jour de copie existante -> update * Le client demande une modification dans le repository global -> Integration complete d'un arbre de source -> import - > integration des modifs sur une copie existante -> commit -> Etiquetage d'un ensemble de sources -> rtag * Le client demande des informations sans aucune modification ni locale, ni dans le repository. -> identification des origines des copies -> status * Le client modifie localement la structure de la copie -> Ajout de fichier/repertoires -> add -> suppression -> remove

Gestion des conflits

Etant donne que CVS autorise le travail concurrent sur le fichiers, il est possible que deux modifications soient effectuees en parallele. Dans ce cas, la premiere des deux modifications qui arrive dans le repository est prise en compte. La seconde modification qui est dans un espace de travail local n'est pas autorisee a etre placee dans le repository tant que l'utilisateur n'a pas resolu les conflits. Une fois les conflits resolus (apres demande de mise a jour de la copie locale depuis le repository), la nouvelle modification peut etre acceptee dans le repository.

Versions et etiquettes

La numerotation de CVS est compliquee et pas toujours coherente, de plus, connaitre ces numeros n'apporte pas grand chose. Il faut prendre un numero de version comme un identificateur unique d'une occurence d'un fichier donne dans le repository.
CVS utilise son propre systeme de notation pour les versions. Il faut donc simuler, si besoin est, une numerotation specifique par les tags (e.g. v2-3-2, ou Integration-004)
L'identification d'un element precis dans le repository (et donc l'identification de l'origine de votre copie dans votre espace de travail local) se fait par un numero associe a votre fichier.
L'identification d'un ensemble coherent de fichiers a un instant precis se fait par les tags (ce sont des configurations). Il n'est pas possible de faire des tags de tags. Il n'est pas possible de gerer les tags en versions.

Les branches

Les branches sont des variantes de l'arbre des sources. On distingue habituellement deux types de branches, les variantes dites temporelles (excusez la pedance) et les variantes spatiales. Une variante temporelle, c'est une branche creer pour une phase de developpement par exemple. Une branche pour l'integration, une branche pour le test, une branche pour la maintenance. Une variante spatiale, c'est une branche qui permet de gerer les differences pour (par exemple) differents types de machines, d'algorithmes, voire... differents types de langages ;)
Une branche est un tag, c'est une etiquette. Le client CVS garde cette etiquette dans votre copie locale de sources et si vous modifiez un source, la nouvelle version de fichier apparaitra sur la branche et non pas sur le tronc commun. Les autres fichiers restent sur le tronc commun, il y a un phenomene de masquage. - Vous pouvez synchroniser votre branche par rapport a une autre branche ou bien par rapport au tronc commun.
Vous pouvez synchroniser le tronc commun par rapport a une branche. - Dans les deux cas, la synchronisation se fait par la mise a jour de votre espace de travail local. Une fois la synchronisation verifiee, il faut explicitement recopier votre espace dans le repository.
La synchronisation entre branches est delicate, il faut penser a tagger les synchros de part et d'autre. Ceci, comme le reste, montre bien que CVS est un outil, et que ce qui est important ce sont les procedures qui se servent de l'outil.
--------


--- 1 Ce n'est pas donc, aproprement parle un outil de gestion de configuration du logiciel, car il ne permet PAS de gerer les dependances. Or ces dependances sont essentielles pour, par exemple, la production. Les dependances ce sont les liens du type A utilise B ( -lstdlib est une dependance au moment de l'edition de liens, system("ls -al") est une dependance a l'execution, "voir Chapitre 2 p.234" est une dependance de reference, etc...) Un outil de GCL doit etre capable de faire ce qu'on appelle une analyse d'impact. C'est a dire etre capable de donner la liste des fichiers touches par la modification d'un autre fichier. C'est ce que fait Make, mais en se basant sur les dates. Or, sur un systeme repartit sur des machines diverses, la date ne peut pas etre un critere d'obsolescence.

2 CVS ne sait pas gerer en version les repertoires. Cela signifie que il ne sait pas tracer l'evolution du contenu d'un repertoire au cours du temps. Si un repertoire contient un fichier, puis deux, il y a deux versions de repertoires. CVS ne les connait pas. Il est possible de simuler cela avec des tags (etiquette, label). Mais les tags n'ont pas d'ordre chronologique et leur syntaxe et leur semantique n'est pas prise en compte par CVS (tag branche, tag de tag, tag de livraison, tag read-only, etc...)

 
 

[ Sommaire ]



Python