CVS peut vous aider dans de nombreux cas, mais il ne
peut pas régler tous les problèmes.
- CVS n'est pas un système de fabrication.
Bien que la structure de votre référentiel influe sur
les mécanismes de génération d'objets (ex
`Makefile's), ces deux systèmes restent
indépendants.
CVS n'impose pas une méthode particulière pour
générer les objets. En fait il se contente de stocker
les sources dans une arborescence de répertoires que vous
êtes libres de concevoir.
CVS n'impose pas non plus de contraintes pour
l'utilisation de l'espace disque dans les répertoires de
travail (ceux ou résident vos versions de checkout d'un
projet). Si vous utilisez des `Makefile's ou des
scripts trop na@"{i}fs cela peut vous obliger à
extraire l'intégralité du projet pour pouvoir y
travailler.
Par contre si vous concevez une organisation bien modulaire
il devient possible de partager des fichiers (en utilisant
par exemple des liens, des mounts, ou des VPATH in
`Makefile's, etc.).
Mais gardez à l'esprit que tout systéme de ce
type est délicat à mettre au point et nécéssitera
de la maintenance. À vous de décider si l'économie
d'un peu d'espace disque justifie cet effort. En tous cas
CVS ne propose aucun mécanisme pour partager les
fichiers.
Vous pouvez bien sur utiliser CVS pour gérer les
versions des scripts, `Makefile's, etc utilisés pour
effectuer le partage des fichiers.
CVS ne se charge pas non plus de la détection des
dépendances de génération entres fichiers. En
général les utilisateurs de CVS s'appuient sur
make pour la génération et sur d'autres
outils automatiques pour la détection des dépendances
(make depend par exemple)
See 14. How your build system interacts with CVS, for more information on doing builds
in conjunction with CVS.
- CVS ne remplace pas l'encadrement.
Vos managers et chefs de projets sont supposés vous tenir
ingormés des plannings, des fusions de code, du nom des
branches et des dates de release. Si ce n'est pas le cas,
CVS ne peut rien y faire!
- CVS ne remplace pas la communication entre développeurs.
Les développeurs sont en général capables de
résoudre des conflits localisés à un fichier. Mais la
définition de «conflit» recouvre aussi des problèmes
plus complexes qui ne peuvent être traités sans une
bonne communication entre les membres de l'équipe.
CVS ne peut pas déterminer quand des modifications
simultannées (sur un ou plusieurs fichiers) entrainent un
conflit logique. Par exemple lorsque des modifications
incompatibles entrainent un comportement anormal du projet
(sans forcement en empecher la compilation). La conception
que CVS a des conflits est purement textuelle et
elle se base sur la détection modification spatialement
assez proches pour déclencher un «merge»
(diff3).
CVS ne pretend pas vous aider à detecter ce types de
conflits logiques.
Par exemple: Supposons que vous changiez les arguments de
la fonction X definie dans le fichier `A'. Au
même instant quelqun d'autre édite le fichier `B',
en rajoutant des appels à la fonction X en
utilisant les vieux arguments. Vous dépassez déjà
les compétences de CVS.
Apprenez à lire attentivement les spécification et à
discuter avec vos collègues.
- CVS n'a pas de suivi des tâches
Le suivi des tâche recouvre trois notions. Tout d'abord
ce peut être le suivi des anomalies qui permet
d'associer dans une base de données un rapport d'anomalie
et l'état des corrections (Bug corrigé? Dans quelle
release? Le client admet-il que la correction est
valable...). Pour interfacer CVS avec un système de
suivi des anomalies externe se référer ayx fichiers
`rcsinfo' et `verifymsg' ( C. Reference manual for Administrative files).
Le deuxième interêt du suivi de tâche est de pouvoir
regrouper les modifications effectuées sur plusieur
fichiers et de les associer à une tache logique de plus
haut niveau. Même si vous effectuez un «check in» de
plusieurs fichiers en une seule commande cvs commit,
CVS ne le m'emorisera pas. Seul leur message de log
identique lie ces différences modifications ensembles. Un
fichier du type GNU `ChangeLog' peu tout de
même remplir une partie de cette focntion.
Le dernier aspect du suivi de tâche (du moins dans
certains systèmes) est de pouvoir contrôler le flot de
développement. Des modifications sont faites par un
développeur puis testées par un deuxième et ainsi de
suite. En général avec CVS ces étapes sont
effectuées grâce à la commande cvs diff (or
diff). La modification est extraite par le
développeur et envoyée par email à celui qui va
l'appliquer (avec la commande patch). Ce système
est très souple mais s'appuie sur des outils externes à
CVS.
- CVS n'est pas une plate-forme de test automatique
Il doit être possible de forcer l'execution d'une
campagne de tests de non régression avant tout «check
in» grâce au fichier `commitinfo'. Toutefois je
n'ai pas eu de rapport d'équipes ayant appliqué cette
méthode.
- CVS n'intègre pas de modèle de développement
- Certains sytèmes permettent d'imposer un cycle de
développement particulier. Par exemple, en forcant le
passage des modifications par plusieurs phases de tests
avec des approbateurs différents. En général et avec
un peu de travail, CVS permet de simuler ce genre de
comportements en utilisant les fichiers `commitinfo',
`loginfo', `rcsinfo', ou `verifymsg'. Pensez
aussi que des concepts natifs de CVS (comme les
branches ou les tags) facilitent certaines tâches (par
exemple pour travailler à plusieurs sur une version de
dévelopement avant de fusionner les changements validés
avec le tronc commun stable).
