Développer via CVS
Travailler à plusieurs
Pages 1
| 2 | 3 | 4
Statut d'un fichier CVS
Prenons l'exemple de deux développeurs (travaillant dans
deux répertoires différents, donc, et peut-être
de façon simultanée). Appelons-les A et B. A peut
avoir effectué des modifications au fichier main.c (et les
avoir fait prendre en compte par des cvs commit) postérieures
au "checkout " de B. Si ce dernier veut, à son
tour, effectuer des modifications (ou s'il les a déjà
effectuées), il peut tenir compte des éventuels changements
apportés à main.c en écrivant:
cvs status main.c
qui renvoie "l'état" du fichier main.c, à
savoir (quelques exemples parmi d'autres):
- Up-to-date: le fichier est identique à la copie
locale.
- Locally Modified: la copie locale a été modifiée,
mais ces modifications n'ont pas été rapportées
à CVS par un cvs commit.
- Needs Checkout: un autre développeur (ici A) a fait
prendre en compte ses propres modifications. Il est nécessaire
que B écrive alors:
cvs update main.c
alors les modifications de A seront "fusionnées"
localement (dans le répertoire de B, donc) à
celles de B. Notons qu'un cvs update est sans danger au sens où
si A n'a fait aucune modification, rien ne changera dans la copie
de main.c située dans le répertoire de B.
- Needs Merge: un autre développeur (ici A) a fait
prendre en compte ses propres modifications, et B a lui-même
modifié sa copie locale. Un cvs update est là aussi
nécessaire, mais la "fusion" peut cette fois entraîner
un conflit (voir plus bas).
- Unresolved Conflict: cet état provient d'un cvs
update sur un fichier dans l'état "Needs Merge",
sous certaines conditions. Il doit être résolu.
Conflits
Si le développeur A modifie main.c par un printf("Copyright
2001\n"); et si, de manière quasi-simultanée,
B modifie main.c par un printf("Tous droits réservés\n");
Que va-t'il se passer? Lors du cvs update main.c de B, CVS avertira
d'un conflit. Si B regarde alors le code (sous CVS) dans main.c,
il verra quelque chose comme:
<<<<<<< main.c
printf("Tous droits réservés\n");
=======
printf("Copyright 2001\n");
>>>>>>> 1.2
Le numéro final étant le numéro de "révision"
de main.c sous CVS. B travaillait donc sur une copie locale d'une
révision antérieure. Ses modifications apparaissent
entre <<<<<<< main.c et =======, tandis que
celles de A apparaissent entre ======= et >>>>>>>
1.2.
B doit, si le besoin s'en fait sentir, corriger manuellement
les éventuels problèmes issus du conflit, en effaçant
les lignes additionnelles rajoutées par CVS. Cela donnera
finalement:
printf("Copyright 2001\n");
printf("Tous droits réservés\n");
Avant que B puisse informer CVS de sa modification:
cvs commit -m "Ajout de TOUS DROITS RESERVES"
main.c
Notons que le problème ne se poserait pas
si les modifications de A et de B n'avaient pas été
effectuées quasi-simultanément, mais avec un certain
intervalle de temps.
Branches
Par ailleurs, CVS permet de "figer" (symboliquement)
l'état du développement à une date donnée:
à partir de cette version, plusieurs "branches"
peuvent se ramifier.
"Figer" l'état du développement est assuré
par l'instruction "tag". Si nous souhaitons que
tous les fichiers sous CVS soient ansi "marqués"
par une identification du type "version-1", on écrira,
dans le répertoire du développeur (par exemple
B) ayant effectué un cvs checkout projet, puis les cvs update
éventuellement nécessaires:
cvs tag version-1 .
Ce numéro de version ne correspond pas aux numéros
de révision dévrits plus haut. A un numéro
(symbolique) de version correspondront certainement plusieurs numéros
de révision.
Le développeur A pourra récupérer l'ensemble
des fichiers de la version 1, et non les plus récents (s'il
y en a), en utilisant l'option -r de cvs checkout:
cvs checkout -r version-1 projet
Créer une branche est assuré par l'instruction "rtag
-b ". On pourra écrire ainsi, dans le
répertoire des sources CVS définit par CVSROOT
(et non plus une copie locale):
cvs rtag -b -r version-1 version-1-branche
projet
La branche est créée à partir
de la version 1, et s'appelle version-1-branche. L'option -b permet
effectivement de créer une branche, et non d'appliquer un
marquage purement symbolique.
Récupérer une copie locale des sources de cette branche
s'effectue, dans le répertoire du développeur, par:
cvs checkout -r version-1-branche projet
Il devient ainsi possible, si une version 1 a été
"marquée" (correspondant par exemple à une
première sortie du logiciel), tandis que le développement
de la version 2 est déjà en route, et qu'un bogue
est découvert dans la version 1, de créer une branche
de développement à partir de la version 1, et distincte
de la version 2.
Une fois le bogue corrigé dans le fichier correspondant,
et cette modification communiquée à CVS par un cvs
commit, il convient de "fusionner" la branche avec la
version 1. Pour cela, trois étapes:
- Effacer la copie locale de la branche: cvs
release -d projet
- Fusionner en copie locale: cvs checkout
-j version-1-branche projet (notez l'option -j)
- Corriger manuellement les éventuels conflits et informer
CVS de la fusion:
cvs commit -m "Fusion de la branche"
Article suivant: Se connecter
à distance
Pages 1
| 2 | 3 | 4
[Jérôme
Morlon 26
avril 2001 , JDNet]
|
