1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
212
213
214
215
216
217
218
219
220
221
222
223
224
225
226
227
228
229
230
231
232
233
234
235
236
237
238
239
240
241
242
243
244
245
246
247
248
249
250
251
252
253
254
255
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282
283
284
285
286
287
288
289
290
291
292
293
294
295
296
297
298
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338
339
340
341
342
343
344
345
346
347
348
349
350
351
352
353
354
355
356
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382
383
384
385
386
387
388
389
390
391
392
393
394
395
396
397
398
399
400
401
402
403
404
405
406
407
408
409
410
411
412
413
414
415
416
417
418
419
420
421
422
423
424
425
426
427
428
429
430
431
432
433
434
435
436
437
438
439
440
441
442
443
444
445
446
447
448
449
450
451
452
453
454
455
456
457
458
459
460
461
462
463
464
465
466
467
468
469
470
471
472
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492
493
494
495
496
497
498
499
500
501
502
503
504
505
506
507
508
509
510
511
512
513
514
515
516
517
518
519
520
521
522
523
524
525
526
527
528
529
530
531
532
533
534
535
536
537
538
539
540
541
542
543
544
545
546
547
548
549
550
551
552
553
554
555
556
557
558
559
560
561
562
563
564
565
566
567
568
569
570
571
572
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602
603
604
605
606
607
608
609
610
611
612
613
614
615
616
617
618
619
620
621
622
623
624
625
626
627
628
629
630
631
632
633
634
635
636
637
638
639
640
641
642
643
644
645
646
647
648
649
650
651
652
653
654
655
656
657
658
659
660
661
662
663
664
665
666
667
668
669
670
671
672
673
674
675
676
677
678
679
680
681
682
683
684
685
686
687
688
689
690
691
692
693
694
695
696
697
698
699
700
701
702
703
704
705
706
707
708
709
710
711
712
713
714
715
716
717
718
719
720
721
722
723
724
725
726
727
728
729
730
731
732
733
734
735
736
737
738
739
740
741
742
743
744
745
746
747
748
749
750
751
752
753
754
755
756
757
758
759
760
761
762
763
764
765
766
767
768
769
770
771
772
773
774
775
776
777
778
779
780
781
782
783
784
785
786
787
788
789
790
791
792
793
794
795
796
797
798
799
800
801
802
803
804
805
806
807
808
809
810
811
812
813
814
815
816
817
818
819
820
821
822
823
824
825
826
827
828
829
830
831
832
833
834
835
836
837
838
839
840
841
842
843
844
845
846
847
848
849
850
851
852
853
854
855
856
857
858
859
860
861
862
863
864
865
866
867
868
869
870
871
872
873
874
875
876
877
878
879
880
881
882
883
884
885
886
887
888
889
890
891
892
893
894
895
896
897
898
899
900
901
902
903
904
905
906
907
908
909
910
911
912
|
<?xml version='1.0' encoding="UTF-8"?>
<!DOCTYPE guide SYSTEM "/dtd/guide.dtd">
<guide link="/doc/fr/cvs-tutorial.xml" lang="fr">
<title>Tutoriel CVS de Gentoo Linux</title>
<author title="Chief Architect"> <mail link="drobbins@gentoo.org">Daniel Robbins</mail></author>
<author title="Traducteur"> <mail link="pierre.habouzit@m4x.org">Pierre Habouzit</mail></author>
<author title="Traducteur"> <mail link="cam@cameuh.net">Camille Huot</mail></author>
<author title="Traducteur"> <mail link="neysx@gentoo.org">Xavier Neys</mail></author>
<license/>
<version>1.4</version>
<date>4 février 2004</date>
<abstract>
Ce tutoriel va présenter le système CVS (Concurrent Versions System) aux
lecteurs. CVS est utilisé par beaucoup de développeurs de par le monde pour
développer des logiciels de façon collaborative dans un environnement souple.
Destiné aux utilisateurs débutants de CVS, ce tutoriel va permettre à la fois
aux utilisateurs occasionnels et aux nouveaux développeurs de travailler
beaucoup plus efficacement. Que vous désiriez utiliser CVS pour faire un "check
out" des dernières sources d'un logiciel donné ou que vous l'utilisiez en tant
que développeur expérimenté, ce tutoriel est fait pour vous.
</abstract>
<chapter>
<title>Introduction</title>
<section>
<title>Organisation du Tutoriel</title>
<body>
<p>
Ce tutoriel est découpé en deux parties. La première explique comment utiliser CVS
lorsqu'on n'est
pas développeur, c'est-à-dire comment récupérer des sources CVS et les garder à jour.
La seconde partie vous présente comment utiliser CVS pour développer en vous montrant
comment modifier, ajouter, retirer des fichiers sur CVS, ainsi que comment réaliser plein
d'autres tâches de développeurs.
Si vous ne connaissez rien à CVS, il est recommandé de commencer par lire la première partie,
puis la seconde ; si vous avez une petite expérience de CVS, mais que vous allez l'utiliser
en tant que véritable développeur pour la première fois, vous trouverez votre bohneur
dans la seconde partie (mais vous pouvez aussi avoir envie de parcourir rapidement
la première partie).
</p>
</body>
</section>
<section>
<title>Qu'est ce que CVS et qu'est ce que ça fait ?</title>
<body>
<p>
CVS est un système client/serveur qui permet aux développeurs de conserver
leurs projets sur un serveur central appelé repository. En utilisant les
clients cvs et les outils associés, les développeurs peuvent faire des modifications
du contenu sur le serveur. En fait, le repository cvs conserve chaque changement
fait sur chaque fichier créant ainsi un historique complet de toute l'évolution
du développement du projet. Les développeurs peuvent demander des versions antérieures
d'un fichier particulier, regarder un historique des modifications et réaliser au besoin
plusieurs autres actions utiles.
</p>
</body>
</section>
<section>
<title>Le rôle de CVS</title>
<body>
<p>
Un nombre conséquent de projets ont leur propre serveur CVS qui est utilisé
par les développeurs du projet comme répertoire central pour tous leurs travaux.
Les développeurs apportent quotidiennement des améliorations aux sources dans le repository CVS.
Souvent, ces développeurs sont dispersés dans le monde entier; CVS leur fournit ainsi
les mécanismes nécessaires pour unifier leur projet dans une structure centralisée
et cohérente. CVS crée le "liant organisationnel" qui permet à ces développeurs
d'améliorer leur code sans se marcher sur les pieds, sans perdre des données importantes
ou sans être bloqués par l'impossiblité de mettre à jour certains fichiers critiques.
</p>
</body>
</section>
<section>
<title>CVS -- les dernières sources du programmeur</title>
<body>
<p>
Quand les programmeurs sont prêts, ils archivent la version actuelle de leur travail
sur CVS dans un fichier tar.gz et publient celui-ci comme une nouvelle version
de leur logiciel. Pourtant, parfois, la dernière version officielle n'est
pas assez récente pour vous pour diverses raisons. Dans la première partie
de ce tutoriel, je vais vous montrer comment utiliser CVS dans ce but : récupérer
la version de développement la plus récente et la plus complète des sources
pour votre usage personnel.
</p>
</body>
</section>
<section>
<title>CVS -- l'avez vous ?</title>
<body>
<p>
Avant que vous ne puissiez utiliser CVS, vous devez l'installer sur votre système.
Le moyen le plus simple de vérifier si cvs est installé chez vous est de taper :
</p>
<pre>
# <i>cvs</i>
</pre>
<p>
Si la commande cvs est trouvée, alors c'est bon. Sinon, vous devez soit récupérer
un paquet de binaires pour votre distribution, soit l'installer depuis les sources.
Installer CVS depuis les sources est plutôt simple et je vous montre comment le
faire ci-dessous.
</p>
</body>
</section>
<section>
<title>Installer CVS depuis les sources</title>
<body>
<p>
Installer CVS depuis les sources est facile. Tout d'abord, récupérez le tarball
cvs-1.11.tar.gz depuis <uri>ftp://ftp.cvshome.org/pub/cvs-1.11/cvs-1.11.tar.gz</uri>
(si il y a une version plus récente répertoriée <uri link="ftp://ftp.cvshome.org/pub/">ici</uri>,
vous pouvez aussi bien récupérer la nouvelle à la place). Ensuite, procédez comme suit (la sortie
standard a été omise) :
</p>
<pre>
# <i>tar xzvf cvs-1.11.tar.gz</i>
# <i>cd cvs-1.11</i>
# <i>./configure</i>
# <i>make</i>
# <i>make install</i>
</pre>
<p>
Maintenant, vous êtes prêt à travailler.
</p>
</body>
</section>
<section>
<title>Installer CVS avec un système de gestion de paquets</title>
<body>
<p>
Beaucoup de distributions offrent une méthode facile pour installer des
logiciels. Par exemple, Gentoo offre la commande <c>emerge</c>. Pour installer
CVS, tapez simplement <c>emerge cvs</c> :
</p>
<pre caption="Installer CVS avec emerge">
# <i>emerge cvs</i>
</pre>
</body>
</section>
<section>
<title>Le CVSROOT</title>
<body>
<p>
Avant de commencer, il y a quelques fondamentaux à connaître. Le premier est que
pour se connecter sur un repository CVS, vous devez tout d'abord renseigner un chemin
appelé le CVSROOT (la racine CVS). CVSROOT est une chaîne de caractères, un peu comme
une URL, qui dit à la commande cvs où se trouve le repository distante et comment
on aimerait s'y connecter. Juste pour rendre les choses plus intéressantes, CVS supporte
de nombreux formats pour CVSROOT, dépendant du fait que le repository soit local ou
distant, et dépendant de la méthode utilisée pour s'y connecter. Voici quelques
exemples de CVSROOT avec des explications ...
</p>
</body>
</section>
<section>
<title>Une racine CVS locale</title>
<body>
<pre>CVSROOT=/home/cvsroot</pre>
<p>
C'est un exemple de chemin pour une racine CVS locale. Vous devriez utiliser
une telle variable si vous voulez vous connecter à un repository local
situé en /home/cvsroot; ou bien, vous pouvez aussi avoir un repository local
monté via NFS en /home/cvsroot.
</p>
</body>
</section>
<section>
<title>Une racine CVS pour un pserver distant (serveur avec mot de passe)</title>
<body>
<pre>CVSROOT=:pserver:cvs@foo.bar.com:/home/cvsroot</pre>
<p>
Ceci est un exemple de CVSROOT pour un repository existant sur l'hôte
foo.bar.com et qui réside dans le /home/cvsroot de cette machine.
La partie ":pserver:" indique à notre client qu'il doit se connecter
à cette machine distante en utilisant le protocole pserver, un
protocole incorporé à CVS. Typiquement, les répertoires CVS publics
utilisent des pserver pour autoriser l'accès à des utilisateurs anonymes.
</p>
</body>
</section>
<section>
<title>Une racine CVS avec accès distant par rsh/ssh</title>
<body>
<pre>CVSROOT=drobbins@foo.bar.com:/data/cvs</pre>
<p>
Ceci est un exemple de CVSROOT qui utilise le protocole RSH ou SSH.
Dans cet exemple, le CVS va accéder au repository sur
foo.bar.com via le compte drobbins. Si la variable d'environnement
est positionnée à "ssh", le client cvs va utiliser ssh pour se connecter,
sinon, rsh est utilisé par défaut. L'accès par ssh est plus populaire chez
ceux qui aiment la sécurité, mais ni rsh, ni ssh ne permettent l'accès
anonyme aux sources. Pour utiliser cette méthode, il faut absolument
avoir un compte sur foo.bar.com.
</p>
</body>
</section>
<section>
<title>Quelques précisions...</title>
<body>
<p>
En plus de la racine CVS, vous allez avoir besoin du nom du module
(groupe de sources) que vous voulez récupérer ainsi que le mot de passe
anonyme que vous devez utiliser pour vous connecter au serveur CVS.
À l'inverse des ftp anonymes, il n'y a pas de format "standard"
pour les mots de passe anonymes, il faudra donc récupérer les mots de passe
spécifiques publiés sur le site web du développeur ou le demander aux développeurs
eux-mêmes. Avec ces informations, vous êtes prêt à commencer.
</p>
</body>
</section>
<section>
<title>Utiliser CVS, Partie 1</title>
<body>
<p>
Récupérer des sources se fait en deux temps. Tout d'abord, il faut se connecter
au pserver. Ensuite, on récupère les sources avec la commande <c>checkout</c>.
Voici un exemple des commandes que l'on peut lancer pour faire un "checkout"
des dernières sources de Samba :
</p>
<pre>
# <i>export CVSROOT=:pserver:cvs@pserver.samba.org:/cvsroot</i>
</pre>
<p>
Cette première commande positionne la variable d'environnement CVSROOT.
Si vous ne le faites pas, il faudra faire suivre, à chaque fois, la commande <c>cvs</c>
par l'option suivante : <c>-d :pserver:cvs@pserver.samba.org:/cvsroot</c>.
Exporter la variable CVSROOT permet d'éviter de l'encoder à chaque fois.
</p>
</body>
</section>
<section>
<title>Uiliser CVS, partie 2</title>
<body>
<p>
Voici les commandes utiles pour récupérer une copie à jour des sources
de développement. Vous pouvez sauter le panneau suivant pour lire l'explication
de ces commandes, et revenir ensuite :
</p>
<pre>
# <i>cvs login</i>
(Logging in to cvs@pserver.samba.org)
CVS password: <comment>(taper le mot de passe ici)</comment>
# <i>cvs -z5 co samba</i>
U samba/COPYING
U samba/Manifest
U samba/README
U samba/Read-Manifest-Now
U samba/Roadmap
U samba/WHATSNEW.txt
<comment>(c'est juste une partie de la sortie complète de la commande cvs co output)</comment>
</pre>
</body>
</section>
<section>
<title>Utiliser CVS -- l'explication</title>
<body>
<p>
La première commande cvs (ci-dessus) nous connecte au le pserver et la seconde
demande à notre client de faire un checkout ("co") du module samba en utilisant
une compression de type gzip de niveau 5 ("-z5") pour accélérer la transmission
sur une connexion lente. Pour chaque nouveau fichier créé localement, cvs affiche
"U [fichier]", ce qui indique que ce fichier a bien été mis à jour sur le disque
(Updated).
</p>
</body>
</section>
<section>
<title>Fin du checkout</title>
<body>
<p>
Une fois le checkout terminé, vous aurez un répertoire "samba" dans votre
répertoire courant. Remarquez d'ailleurs que chaque répertoire contient
un nouveau répertoire "CVS" -- CVS y stocke plusieurs informations qui
peuvent être ignorées sans problème ici. A partir de maintenant,
nous n'avons plus à nous inquiéter que la variable CVSROOT soit positionnée
ou non, parce que les informations sur le repository sont stockées dans
ces fameux répertoires "CVS" supplémentaires. A savoir : CVSROOT n'est à
définir que pour la première connexion et le premier "checkout".
</p>
</body>
</section>
<section>
<title>Mettre les sources à jour</title>
<body>
<p>
Quand vous en êtes là, vos sources sont récentes. Vous pouvez
les compiler et les installer, les parcourir et en faire tout ce que vous voulez.
</p>
<p>
De temps en temps, vous pouvez avoir envie de synchroniser vos sources déjà récupérées
avec la version actuelle sur CVS. Pour ce faire, vous n'avez pas besoin de vous connecter
à nouveau au pserver; vos informations d'authentification sont mises en cache par cvs
dans les répertoires "CVS" dont j'ai parlé. Il suffit d'entrer dans le répertoire
principal des sources (dans notre cas "samba") et de taper :
</p>
<pre>
# <i>cvs update -dP</i>
</pre>
</body>
</section>
<section>
<title>"cvs update" en bref, partie 1</title>
<body>
<p>
Si il y a des nouveaux fichiers, cvs va afficher une ligne "U [fichier]"
pour chaque fichier qu'il met à jour. Si vous avez déjà compilé les
sources une fois, vous allez sans doute voir apparaître beaucoup de lignes
"? [fichier]" ; ce sont des fichiers que cvs signale qu'ils ne sont pas sur le
repository distant.
</p>
</body>
</section>
<section>
<title>"cvs update" en bref, partie 2</title>
<body>
<p>
Remarquez d'ailleurs les deux options utilisées pour faire un "cvs update".
"-d" demande à cvs de créer chez vous les nouveaux répertoires qui ont pu être
ajoutés au repository (ce qui n'est pas le comportement par défaut), et "-P"
sert à supprimer tous les répertoires vides de votre copie locale des sources.
"-P" est une bonne idée puisque cvs a tendance à récupérer un bon nombre
de répertoires vides (utilisés à une époque, puis abandonnés).
</p>
<p>
Lorsqu'il s'agit juste de récupérer les sources les plus récentes, c'est à peu près
tout ce qu'il suffit de savoir sur cvs. La suite concerne plutôt les développeurs.
</p>
</body>
</section>
</chapter>
<chapter>
<title>CVS pour les developpeurs</title>
<section>
<title>Modifier des fichiers</title>
<body>
<p>
En tant que développeur, vous devrez modifier des fichiers sur le serveur CVS. Pour ceci,
commencez par faire les changements désirés sur votre copie du repository.
Ces changements ne sont bien entendu pas répercutés sur le repository distant tant
que vous n'avez pas explicitement demandé à cvs de faire un "commit" de vos
modifications. Lorsque vous avez suffisamment testé toutes vos modifications,
que vous êtes sûr que tout fonctionne parfaitement, alors vous êtes prêt
à envoyer vos modifications sur le repository distant. Suivez bien les deux
étapes. En premier lieu, mettez vos sources à jour, par la commande suivante :
</p>
<pre>
# <i>cvs update -dP</i>
</pre>
</body>
</section>
<section>
<title>CVS fusionne les modifications des autres</title>
<body>
<p>
Comme on l'a vu plus tôt, "cvs update" va synchroniser vos sources avec
celles du repository distant. Mais que va-t-il se passer pour vos
modifications ? Rassurez-vous, elles ne seront pas perdues ! Si un autre
développeur a modifié un fichier que vous n'avez pas modifié, votre fichier
local sera mis à jour, et ainsi, tous les fichiers que vous n'aurez
pas touchés seront synchrones avec les fichiers du repository CVS.
</p>
<p>
De plus, si vous avez modifié les lignes 1 à 10 d'un fichier en local, et qu'un autre
développeur a supprimé les lignes 40 à 50, ajouté 12 lignes à la fin de ce fichier,
puis réalisé un "commit" avant vous, alors cvs va réaliser une fusion intelligente
des modifications réalisées par l'autre développeur sur votre copie, et ainsi,
aucun travail n'est perdu. Cela permet à deux développeurs de travailler sur
des parties distinctes d'un même fichier en même temps.
</p>
</body>
</section>
<section>
<title>La fusion n'est pas parfaite</title>
<body>
<p>
Pourtant, si deux développeurs ou plus ont fait des modifications
sur la <i>même partie du même fichier</i>, alors les choses se compliquent
un tout petit peu. Si cela arrive, alors cvs va vous prévenir qu'il y a un
conflit. Aucun travail n'est perdu, mais une intervention de votre part va
être requise. En effet, cvs a besoin que vous lui indiquiez comment
fusionner les changements.
</p>
</body>
</section>
<section>
<title>Le "commit"</title>
<body>
<p>
Nous allons nous intéresser à la résolution des conflits un peu plus loin.
Mais pour l'instant, supposons qu'il n'y a pas eu de conflits à la sortie de
la commande "cvs update -dP" (ce qui est souvent le cas). Dans ce cas, vos
sources locales sont à jour (up-to-date) et vous êtes alors prêt à réaliser
le "commit" de vos sources. Il suffit de taper la commande suivante dans le
répertoire principal de vos sources :
</p>
<pre>
# <i>cvs commit</i>
</pre>
</body>
</section>
<section>
<title>Ce que fait le "commit"</title>
<body>
<p>
"cvs commit" ne fait <i>pas qu'appliquer</i> vos modifications sur le repository
distant. Avant de vraiment envoyer vos sources, cvs va ouvrir votre éditeur par
défaut pour que vous puissiez écrire une courte description des changements réalisés.
Une fois ce commentaire saisi, enregistrez le fichier et quittez l'éditeur, vos
changements (et les commentaires associés) vont être appliqués au repository distant
et vont être disponibles pour les autres développeurs de l'équipe.
</p>
</body>
</section>
<section>
<title>Consulter les logs</title>
<body>
<p>
Il est vraiment très facile de consulter l'historique complet d'un fichier
donné avec tous les commentaires que les développeurs (dont vous) ont pu
faire lorsqu'ils ont fait des "commit". Pour accéder à ces informations, faites :
</p>
<pre>
# <i>cvs log myfile.c</i>
</pre>
<p>
"cvs log" est une commande récursive, donc pour consulter le log complet de toute
une arborescence d'un répertoire, allez dans le répertoire en question, et tapez :
</p>
<pre>
# <i>cvs log | less</i>
</pre>
</body>
</section>
<section>
<title>Les options du "commit"</title>
<body>
<p>
Vous pourriez avoir envie d'utiliser un autre éditeur que celui que cvs utilise par défaut
lorsque vous faites un "cvs commit". Si c'est le cas, positionnez la variable d'environnement
EDITOR sur le nom de votre éditeur favori. Mettre une telle ligne dans votre ~/.bashrc peut
être une bonne idée :
</p>
<pre>
export EDITOR=jpico
</pre>
<p>
Vous pouvez aussi spécifier le commentaire dans la ligne de commande de sorte que
cvs n'ait pas à ouvrir un éditeur de texte :
</p>
<pre>
# <i>cvs commit -m 'Ceci doit être un commentaire intelligent'</i>
</pre>
</body>
</section>
<section>
<title>Le fichier .cvsrc</title>
<body>
<p>
Avant de continuer de découvrir d'autres commandes cvs, je vous recommande de créer
un fichier ~/.cvsrc. En le créant dans votre "home directory", vous pouvez dire à cvs
d'utiliser des options par défaut pour chaque commande cvs, et ainsi, vous n'avez pas
à vous rappeler de les taper à chaque fois. Voici un exemple de fichier .cvsrc :
</p>
<pre>
cvs -q
diff -u -b -B
checkout -P
update -d -P
</pre>
</body>
</section>
<section>
<title>Le fichier .cvsrc, suite</title>
<body>
<p>
En plus de pouvoir spécifier plein d'options utiles pour un grand nombre de
commandes cvs, la première ligne du .cvsrc force le mode silencieux de cvs, ce qui
a comme première conséquence de rendre la sortie de "cvs update" beaucoup plus
concise et lisible. Une fois ce fichier en place, il vous suffit de taper
"cvs update" au lieu de "cvs update -dP" (par exemple).
</p>
</body>
</section>
<section>
<title>Ajouter un fichier au repository</title>
<body>
<p>
Il est vraiment facile d'ajouter un fichier source au CVS. En premier lieu,
vous devez créer le fichier en question, puis taper la commande suivante :
</p>
<pre>
# <i>cvs add myfile.c</i>
cvs server: use 'cvs commit' to add this file permanently
</pre>
<p>
Ceci va dire à cvs d'ajouter ce fichier au repository la prochaine fois
que vous ferez un "cvs commit". Jusqu'à ce moment, les autres développeurs
ne pourront pas le voir.
</p>
</body>
</section>
<section>
<title>Ajouter un répertoire au repository</title>
<body>
<p>
Pour ajouter un répertoire, la procédure est similaire :
</p>
<pre>
# <i>mkdir foo</i>
# <i>cvs add foo</i>
Directory /home/cvsroot/mycode/foo added to the repository
</pre>
<p>
A la différence d'un ajout de fichier, lorsque vous ajoutez un répertoire,
il apparaît immédiatement dans le repository, le "commit" n'est pas requis.
Une fois le répertoire local ajouté au repository, vous allez remarquer
qu'un répertoire "CVS" y est créé pour y stocker les informations CVS.
Ainsi, vous pouvez facilement savoir si un répertoire a été
ajouté à cvs en regardant si il contient un répertoire "CVS".
</p>
</body>
</section>
<section>
<title>Remarques sur "cvs add"</title>
<body>
<p>
Comme vous pouvez le deviner, avant d'ajouter un fichier ou un répertoire
au repository, vous devez bien vérifier que son répertoire parent lui
a déjà été ajouté. Sinon, vous aurez l'erreur suivante :
</p>
<pre>
# <i>cvs add myfile.c</i>
cvs add: cannot open CVS/Entries for reading: No such file or directory
cvs [add aborted]: no repository
</pre>
</body>
</section>
<section>
<title>Se familiariser avec "cvs update", partie 1</title>
<body>
<p>
Avant de s'occuper de la résolution des conflits, familiarisons-nous avec
les sorties de la commande "cvs update". Si vous créez un fichier ~/.cvsrc
qui contient la ligne "cvs -q", vous allez trouver les sorties de "cvs update"
beaucoup plus faciles à lire. "cvs update" vous informe de ce qu'il fait,
représentant ses actions par un caractère, un espace et un nom de fichier.
Par exemple :
</p><pre>
# <i>cvs update -dP</i>
? distfiles
? packages
? profiles
</pre>
</body>
</section>
<section>
<title>Se familiariser avec "cvs update", partie 2</title>
<body>
<p>
"cvs update" utilise le caractère "?" pour vous signifier qu'il ne sait rien
sur ce fichier là, fichier qu'il trouve dans votre copie locale, mais pas
sur le repository. Ces fichiers ne font pas partie du repository distant,
et n'ont pas non plus été prévus pour être ajoutés au repository.
Voici une liste de tous les messages possibles que CVS utilise :
</p>
<pre>
U [path]
</pre>
<p>
Utilisé lorsqu'un fichier est créé dans votre copie locale, ou si un fichier
que vous n'avez pas touché est mis à jour.
</p>
<pre>
A [path]
</pre>
<p>
L'ajout de ce fichier au repository a été programmé et sera officiellement ajouté
quand vous ferez un "cvs commit".
</p>
</body>
</section>
<section>
<title>Se familiariser avec "cvs update", partie 3</title>
<body>
<pre>
R [path]
</pre>
<p>
A l'image de "A", "R" vous indique que la suppression de ce fichier a été prévue.
Ce fichier sera effectivement retiré dès que vous aurez fait un "cvs commit".
</p>
<pre>
M [path]
</pre>
<p>
Cela signifie que ce fichier a été modifié par vous. Il est possible
que des modifications aient été fusionnées dans ce fichier sans conflits.
</p>
<pre>
C [path]
</pre>
<p>
Le caractère "C" indique que ce fichier présente des conflits et nécessite une
intervention manuelle avant de réaliser votre "commit".
</p>
</body>
</section>
<section>
<title>Résoudre les conflits, introduction</title>
<body>
<p>
Désormais, occupons-nous de résoudre ces conflits. Je suis assez impliqué dans
le projet Gentoo-Linux et nous avons notre propre serveur cvs configuré
sur cvs.gentoo.org. Nous autres, développeurs, passons la majorité de notre
temps à hacker les sources du module "gentoo-x86" et nous avons ajouté un fichier
appelé "ChangeLog" qui contient (vous l'aurez deviné) les modifications majeures
que nous avons faites sur le repository.
</p>
</body>
</section>
<section>
<title>Un exemple de conflit</title>
<body>
<p>
Puisque ce ficher est modifié à peu près à chaque fois qu'un changement majeur
est réalisé sur CVS, c'est notre plus grande source de conflits. En voici un
exemple. Imaginons que j'ai ajouté les lignes suivantes au début du fichier
de ChangeLog :
</p>
<pre>
date 25 Feb 2001
J'ai ajouté ce commentaire
</pre>
<p>
Imaginons qu'avant que je ne fasse un "commit" de ces trois nouvelles lignes,
un développeur avait déja ajouté les lignes suivantes au début du Changelog et
envoyé ses modifications :
</p>
<pre>
date 25 Feb 2001
Un autre développeur a ajouté ce commentaire
</pre>
</body>
</section>
<section>
<title>Une exemple de conflit, suite</title>
<body>
<p>
Maintenant, lorsque je fais un "cvs update -dP" (comme il faut le faire avant
chaque commit), cvs n'est pas capable de fusionner ces modifications sur ma
copie locale du ChangeLog parce que nous avons tous les deux ajouté des lignes
dans la même partie du fichier. Cvs ne sait alors pas quelle partie utiliser.
Ainsi, j'ai l'erreur suivante :
</p>
<pre>
RCS file: /home/cvsroot/gentoo-x86/ChangeLog,v
retrieving revision 1.362
retrieving revision 1.363
Merging differences between 1.362 and 1.363 into ChangeLog
rcsmerge: warning: conflicts during merge
cvs server: conflicts found in ChangeLog
C ChangeLog
</pre>
</body>
</section>
<section>
<title>Résolution de conflit, partie 1</title>
<body>
<p>
Ahhh, un conflit ! Heureusement, résoudre un conflit est facile. Si je lance
mon éditeur favori, je vois le texte suivant au début du fichier "ChangeLog" :
</p>
<pre>
<<<<<<< ChangeLog
date 25 Feb 2001
J'ai ajouté ce commentaire
=======
date 25 Feb 2001
Un autre développeur a ajouté ce commentaire
>>>>>>> 1.363
</pre>
</body>
</section>
<section>
<title>Résolution de conflit, partie 2</title>
<body>
<p>
Au lieu de choisir une version ou l'autre, cvs ajoute les deux versions
au fichier ChangeLog et les entoure de caractères spéciaux pour marquer
clairement les régions qui posent problème. Maintenant, c'est à moi de
remplacer ces régions par les textes qui <i>devraient</i> apparaître dans
le ChangeLog; dans ce cas, le texte de remplacement n'est ni l'une,
ni l'autre des versions, mais une combinaison des deux :
</p>
<pre>
date 25 Feb 2001
This is the thing I added myself
This is the part added by another developer
</pre>
<p>
Maintenant que j'ai remplacé les régions conflictuelles du fichier avec le texte
approprié (et supprimé les "=======" et autres marqueurs), je peux faire
un "commit" sans aucun problème.
</p>
</body>
</section>
<section>
<title>Astuces pour résoudre les conflits</title>
<body>
<p>
A chaque fois que vous avez besoin d'éditer un fichier pour régler
des conflits, vérifiez que vous avez bien parcouru tout le fichier
de telle manière que vous n'ayez rien oublié. Sinon, cvs n'autorisera
pas votre "commit" et ce jusqu'à ce que le conflit soit résolu.
Il est donc très important d'enlever les marqueurs spéciaux que
cvs a ajoutés aux fichiers conflictueux. Autre astuce : si vous avez
fait une erreur en essayant de résoudre un conflit et que
vous avez accidentellement enregistré vos modifications, vous pouvez retrouver la copie
originale du fichier dans le fichier ".#nom_du_fichier.version".
</p>
</body>
</section>
<section>
<title>Supprimer un fichier</title>
<body>
<p>
Maintenant, il est temps de découvrir notre dernière commande cvs : supprimer un
fichier du repository. Supprimer un fichier se fait en deux étapes. Il
faut commencer par supprimer le fichier de votre copie des sources, puis
exécuter la commande "cvs remove" sur ce fichier :
</p>
<pre>
# <i>rm myoldfile.c</i>
# <i>cvs remove myoldfile.c</i>
</pre>
</body>
</section>
<section>
<title>Supprimer un fichier, suite</title>
<body>
<p>
La suppression du fichier est alors prévue par cvs et sera effective
lors de votre prochain "commit". Une fois le "commit" réalisé, le fichier
sera officiellement supprimé du repository distant. Pourtant, cvs
ne va pas faire disparaître ce fichier et va garder un enregistrement
complet de son contenu et de son historique au cas où vous en auriez
besoin dans le futur. C'est juste un des nombreux moyens utilisés par cvs
pour protéger votre code.
</p>
<p>
"cvs remove" est récursif, ce qui signifie que vous pouvez supprimer
un paquet de fichiers et lancer la commande "cvs remove" sans autre argument
depuis un répertoire parent. Ceci va marquer tous les fichiers supprimés
comme "à supprimer" lors du prochain "commit".
</p>
</body>
</section>
<section>
<title>Supprimer un répertoire</title>
<body>
<p>
Si vous voulez supprimer un répertoire complet, je vous recommande la méthode
suivante. Tout d'abord supprimez chaque fichier du répertoire et faites un
"cvs remove" :
</p>
<pre>
# <i>rm *.c</i>
# <i>cvs remove</i>
</pre>
</body>
</section>
<section>
<title>Supprimer un répertoire, suite</title>
<body>
<p>
Ensuite, faites un "commit" :
</p>
<pre>
# cvs commit
</pre>
<p>
Et là, astuce : exécutez les commandes suivantes pour supprimer le répertoire :
</p>
<pre>
# <i>cd ..</i>
# <i>cvs remove mydir</i>
# <i>rm -rf mydir</i>
</pre>
<p>
Remarquez que supprimer un répertoire ne nécessite pas un autre "commit". L'ajout
et la suppression de répertoires sur le repository distant se font en temps réel.
</p>
</body>
</section>
<section>
<title>C'est terminé !</title>
<body>
<p>
Votre introduction à CVS est terminée. J'espère que ce tutoriel vous a été utile.
Il y a bien d'autres choses à savoir sur CVS, que je n'ai pu couvrir dans cette
introduction, mais heureusement, les nombreuses documentations disponibles
vous aideront à étendre vos connaissances sur CVS :
</p>
<p>
<ul>
<li><uri>http://www.cvshome.org</uri> est la page principale du développement de CVS
et offre une foule de documentation sur CVS, en particulier la
<uri link="http://www.cvshome.org/docs/manual">documentation officielle de CVS "online"</uri>.
</li>
<li>Le site <uri link="http://www.durak.org/cvswebsites/">"CVS Version Control for Web Site Projects"</uri>
propose de bonnes informations sur comment utiliser CVS pour développer des sites Web.
</li>
<li>Karl Fogel a écrit un livre intitulé <uri link="http://cvsbook.red-bean.com/">Open Source Development with CVS</uri>.
Certains chapitres de ce livre sont disponibles sur le site.
</li>
<li><uri link="http://www.freebsd.org/projects/cvsweb.html">cvsweb</uri> est un script
CGI merveilleux qui fournit une interface web vers votre repository. Excellent pour le parcours rapide.
</li>
<li>Le site <uri link="http://www.loria.fr/~molli/cvs-index.html">CVS Bubbles</uri>
propose aussi de nombreuses informations dont "CVS FAQ-o-matic".
</li>
</ul>
</p>
</body>
</section>
<section>
<title>À propos de ce document</title>
<body>
<p>
La version originale de cet article a été publiée sur le site developerWorks
d'IBM et est la propriété de Westtech Information Services. Ce document est
une mise à jour de l'article original et contient diverses améliorations faites
par l'équipe de documentation de Gentoo.
</p>
</body>
</section>
</chapter>
</guide>
|
GitWeb