<note important> Cette page n'est plus valide. Capsis a été transferer sur un serveur subversion depuis le 19/01/09

La nouvelle procédure est consultable ici </note>

Erreurs CVS et résolution

Version : F. de Coligny - 26.11.2004 - jib 18.1.2006 - §4.10, 4.11, 27.3.2006 - 20.4.2006 : smartcvs sur web - 17.10.2008

Lien direct résolution erreurs

1. Introduction

CVS (Concurrent Versions System) est un sytème de gestion de versions concurrentes de fichiers. Un dépôt (repository) contient la version de référence des fichiers à gérer. On accède à ce dépôt au travers d'un serveur CVS sur une machine serveur (ex: capsis.cirad.fr contient le dépôt pour le projet capsis4). Ce serveur accepte des requêtes d'un client CVS (ex: SmartCVS) qui permet d'obtenir et de gérer des copies locales sur la machine des développeurs.

Du côté du développeur, le système permet tout d'abord d'obtenir une copie locale du projet (opération: checkout), puis de travailler sur cette copie comme si CVS n'existait pas (ajouts de sources, modifications, suppressions, recompilation, tests).

A tout moment, le développeur peut mettre à jour sa copie locale (opération: update) avec une version plus récente du dépôt, remontée entre temps par un autre développeur. La mise à jour déclenche la fusion automatique par CVS des fichiers sources modifiés localement et sur le serveur. Cette fusion est opérée dans la copie locale.

Il peut arriver qu'il y ait conflit pendant une fusion si la version du serveur et la copie locale ont été modifiée au même endroit (ex: modification de la même méthode). Le serveur CVS indiquera ce conflit au client et le développeur devra le résoudre en local, en utilisant un utilitaire (opération: diff) montrant les différences entre les deux versions et un éditeur, peut-être aussi en contactant l'autre développeur. L'opération update peut être effectuée pour la totalité du projet CVS (ex: capsis4) ou bien pour l'un des sous répertoires (ex: mountain). Après update, il convient de recompiler et retester le projet concerné (ex: resp. capsis4 ou mountain).

Quand le développeur dispose d'une version stable (update suivi de recompilation et tests concluants), il peut la remonter (opération: commit) dans le dépôt. Le commit peut s'interrompre en donnant un message d'erreur, notamment si le développeur n'a pas les droits d'accès nécessaire dans le dépôt sur certains des fichiers (ex: courbaud fait un commit sur capsis/kernel) ou si le serveur contient une version plus récente que celle qu'il éssaie de remonter (cf. 4.).

Conseil : dans la pratique, le modélisateur Capsis fera souvent des update sur des répertoires entiers pour récupérer des versions consistantes (et même très souvent sur tout le projet : capsis4/) et des commit sur les parties plus fines dont il est propriétaire (un module ou un extracteur de données, ou un fichier communautaire comme capsis.extensions).

2. Opérations usuelles...

2.1 Obtenir une copie locale de capsis4/

Avec SmartCVS, récupérer par checkout sur le serveur CVS une copie locale du projet capsis4.

Cette opération est effectuée une seule fois. La copie locale contient toute l'arborescence capsis y compris son répertoire d'installation conventionnellement nommé capsis4/. Choisissez une localisation sur votre disque dur pour y installer capsis4/. Une fois l'opération effectuée, vous travaillez dans la copie locale que vous pouvez mettre à jour (update) pour récupérer les nouveautés du dépôt. Quand vous disposez en local d'une version stable (compilée et testée), vous pouvez remonter vos modifications dans le dépôt (commit).

2.2 Mettre à jour la copie locale à partir du dépôt

Avec SmartCVS, désigner le répertoire à mettre à jour dans l'arborescence de la copie locale, puis faire update.

Cette opération est effectuée chaque fois que vous souhaitez récupérer des modifications qui ont été répercutées dans le dépôt par d'autres utilisateurs. Update effectue une fusion automatique (merge) des versions locale et du dépôt chaque fois que nécessaire. Il est possible de désigner pour l'opération un fichier (sélection, puis update par le menu contextuel), un ensemble de fichiers sélectionnés (idem) ou un répertoire entier (désigner le répertoire sélectionne récursivement tous les fichiers qu'il contient). Ainsi, il est possible de faire update sur le répertoire capsis4/ et de mettre à jour localement toute votre plate-forme. Les fichiers .class ne sont pas répertoriés dans le dépôt et sont ignorés par cvs, il faut recompiler (avec jib, cf. 3.6) et tester la version locale après chaque update pour s'assurer qu'il ne manque rien et que tout est cohérent (il peut arriver qu'un collègue oublie de mettre un fichier sur le dépôt ou valide malencontreusement une version instable).

2.3 Régler les conflits quand ils apparaissent

Pendant un update, un conflit peut apparaitre sur l'un des fichiers concernés : une même portion de code a été modifiée localement par vous et dans le dépôt par un autre utilisateur, interdisant la fusion automatique par CVS : il faut régler le conflit, puis faire commit (cf 4.4).

CVS ne peut pas effectuer la fusion de deux blocs d'un fichier source s'ils se chevauchent. Vous devez inspecter le code en cause (par exemple avec l'option compare de SmartCVS) puis résoudre le conflit dans un éditeur et enfin faire commit. Il est vraisemblable que vous ayez à contacter l'auteur de la modification validée dans le dépôt pour vous mettre d'accord (n'hésitez jamais à vous concerter).

2.4 Remonter son travail local dans le dépôt

Avec SmartCVS, valider la remontée des fichiers localement modifiés, ajoutés ou supprimés par commit.

Les fichiers nouveaux de la copie locale (une nouvelle classe, un nouveau fichier d'aide...) doivent préalablement être ajoutés dans le dépôt explicitement par add. De même, les fichiers localement supprimés (un fichier qui n'est plus utilisé) doivent être supprimés explicitement du dépôt par remove. La commande commit est ensuite nécessaire pour valider dans le dépôt les ajouts, suppressions et modifications locale.

Cette opération peut être effectuée quand votre copie locale est dans un état stable (entièrement compilée par jib et testée avec succès). Ne remontez pas votre travail dans un état instable car les autres utilisateurs en hériteraient lors de leur prochain update de leur copie locale. Vous pouvez remonter votre travail régulièrement pour minimiser l'apparition de conflits dus à des modifications par d'autres utilisateurs des mêmes portions de codes.

3. Plus de détails...

3.1 Le serveur CVS

Le serveur cvs est la machine capsis.cirad.fr, accessible depuis internet. Il contient la version de référence du projet, sous le nom "capsis4". Cette copie a été initialement remontée sur le serveur par la commande import dont vous n'aurez pas l'usage. Le serveur est accessible par réseau et répond aux requêtes (checkout, add, remove, commit...) que vous lui formulez au travers du client CVS : SmartCVS (cf 3.3). L'adresse du dépôt sur le serveur est la suivante :

:pserver:votreUser@capsis.cirad.fr:/opt/cvs

Pour accéder au serveur, demandez un user/motDePasse à l'administrateur du projet.

3.2 La copie de référence dans le dépôt

C'est au départ une copie de la version capsis4.1.2 présentée lors de la journée Capsis du 12 juin 2003 à Montpellier. Les fichiers .class ne font pas partie de la copie de référence, vous n'avez pas à vous en soucier lors des commit.

Après un checkout, ou un update de la copie locale, il faut recompiler le projet (à l'aide de jib, cf. 3.6). La copie de référence commence au répertoire d'installation de capsis, conventionnellement nommé capsis4/ (inclus). Ce dernier contient les répertoires de l'arborescence (bin/, etc/, data/, ext/...) qui contiennent toute la plate-forme : le noyau (capsis.kernel, capsis.util), les pilotes (capsis.gui, capsis.script), les extensions (capsis.extension.*), les bibliothèques (capsis.lib.*), les modules (ex: mountain, fagacees, pp3), ainsi que tous les fichiers de paramètres (etc/capsis.properties, etc/capsis.extensions...).

3.3 SmartCVS

SmartCVS est un client pour CVS en java, avec une version communautaire libre. Toutes les requêtes CVS nécessaires seront faites au travers de ce logiciel.

Récupérez la dernière version de SmartCVS sur le site web de smartcvs (chercher dans goolge) et installez le ou vous voulez sur votre disque dur (il fonctionne avec java tout comme capsis).

Pour le lancer, utiliser le script run du répertoire SmartCVS/bin/ (run.bat, run.sh pour Linux).

Note pour Windows : run.bat nécessite que la variable d'environnement JAVA_HOME contienne le répertoire d'installation de java (ex: c:\j2sdk1.5.0\).

Checkout : à la première utilisation, récupérez votre copie locale par checkout en suivant les instructions de SmartCVS :

Repository : (Manage > Add > Enter CVS Location) ":pserver:votreUser@capsis.cirad.fr:/opt/cvs"
Module (le nom du projet cvs) : capsis4
Local directory : choisir le répertoire ou sera créé le répertoire capsis4/, contenant toute l'arborescence capsis (ex, si vous avez l'habitude de travailler dans c:/capsis4/bin, faites checkout dans c:/).
Kind of revision to get : Default
Confirmez.

La copie locale est créée sur votre disque. Particularité : chaque répertoire de l'arborescence contient un répertoire nommé CVS/, ne vous en occupez pas.

Pour les opérations suivantes dans SmartCVS, si vous utilisez un bouton de la barre d'outils, le contexte de l'opération est la sélection courante en bleu (répertoire sur la partie gauche ou fichiers sur la partie droite).

Update : quand vous voulez fusionner les modifications du dépôt dans votre copie locale, sélectionnez les fichiers concernés (un ou plusieurs fichiers, un répertoire entier, le répertoire racine de l'arborescence) et faites update (menu contextuel ou bouton de la barre d'outil).

Commit : pour remonter vos modifications vers le dépôt (après avoir ajouté (add) les fichiers nouvellement créés et supprimé (remove) les fichiers localement supprimés), sélectionnez les fichiers / répertoires concernés et faites commit (spécifier un descriptif court mais significatif des modifications apportées, en anglais).

Refresh : Cette commande n'est pas une commande CVS : SmartCVS raffraîchit sa liste de fichiers en rescannant la copie locale : il mets à jour les statuts locaux de chaque fichier par rapport au dernier checkout / update : Up-to-date (inchangé), modified (modifié localement), non-cvs (faire un add dans le dépôt si nécessaire), localy removed (faire un remove du dépôt si nécessaire)... A faire avant d'envisager update / commit.

Status (Show the repository status of the file) : Montre le statut des fichiers sélectionnés par rapport au dépôt (Up-to-date, Needs-checkout/update). Dans la version communautaire, cette commande répond dans la zone console en bas de la fenêtre principale de SmartCVS. Elle n'est pas indispensable.

En jouant sur les options du menu View, on peut montrer ou cacher les fichiers ayant un statut "à jour" ou "non-cvs". En combinant avec des tris ascendant / descendants des colonnes de la liste de fichiers (cliquez à plusieurs reprise sur les entetes de colonnes), on peut :

Détecter les fichier à ajouter dans le dépôt : View non-cvs files et tri sur extensions de fichiers : beaucoup de .class à ignorer et les fichiers localement ajoutés et pas encore dans le dépôt -> faire des add, puis commit.
Avoir la liste des fichiers modifiés localement, en cours d'ajout ou de modification : ne rien cocher dans le menu View : les fichiers apparaissent dans la liste (s'il y en a). Après un commit : liste vide.
Voir la liste des fichiers "à jour" (+ les modifiés localement) : View unchanged files.

SmartCVS offre d'autres possibilités non développées ici, consultez l'aide en ligne en cas de besoin.

3.4 La copie locale sur votre disque dur

C'est l'arborescence complète capsis, depuis le répertoire capsis4/. Lors du checkout initial, vous pouvez la disposer ou vous voulez sur votre disque local (ex : c:\, d:\courbaud\, /home/pichot/java/). Gardez à l'esprit que pour compiler capsis, la variable d'environnement classpath doit contenir le chemin d'accès ..../capsis4/bin/.

Une fois la copie récupérée par checkout la première fois ou mise en conformité avec le dépôt par update, il vous faut recompiler la plate-forme et les modules en utilisant jib (cf. 3.6). Vous pouvez ensuite :

Lancer depuis capsis4/bin/ les scripts install, puis capsis pour lancer capsis
Travailler comme avant dans votre copie locale.

3.5 Les états possibles d'un fichier sous cvs

Le développement d'un projet par plusieurs développeurs génère logiquement des conflits. Pour gérer les versions, les conflits et les mises à jour nécessaires, cvs attribue un état aux fichiers (voir figure, d'après G. Mariano).

Les états possibles des fichiers sous cvs

3.6 Recompilation de projets avec jib

Pour recompiler toute la plate-forme ou certains modules, placez vous dans capsis4/bin/ et lancez jib(./jib.sh sous Linux, jib.bat sous windows).

Utilisation dans un terminal : jib commande (ex: jib kernel_clean, jib kernel, jib kernel_force).

Quelques commandes utiles (help -> jib -list donne la liste des commandes lues dans le makefile.jib) :

all : pour recompiler tout ce qu'il y a à recompiler dans la plate-forme (les .java sans .class ou avec une date de modification ultérieure à leur celle de leur .class)
kernel : recompile les classes du noyau
modules : recompile les modules
extensions : recompile toutes les extensions
..._clean : efface tous les .class d'un projet, (ex: kernel_clean, modules_clean, all_clean)
..._force : force la recompilation des classes en effacant les .class avant de lancer la compilation (ex: kernel_force lance successivement kernel_clean puis kernel)

Après un checkout initial ou un update, recompilez tous les projets de la plate-forme : jib all_force.

4. Erreurs CVS et résolution

4.1 Récupérer un fichier perdu ou abimé en local

Fichier perdu : dans SmartCVS, sélectionner le fichier seul et faire update. La version du serveur est redescendue dans votre copie locale.

Fichier abimé : si vous voulez écraser des modifications locales et récupérer une copie propre du dépôt, sélectionner l'option "Get clean copy" de l'onglet "Advanced options" du dialogue "update".

4.2 Problème sur commit - droits d'accès

cvs [server aborted] could not open lock file '/opt/cvs/capsis4/someFileInTheRepository” Permission denied

Si lors d'un commit, vous obtenez un message d'erreur de ce type, c'est que l'administrateur du dépôt a spécifié que vous n'aviez pas le droit de modifier ce fichier (vous pouvez contester le cas échéant).

Les droits d'accès sont fixés par groupes de travail au niveau des répertoires. Ainsi par exemple, le répertoire laricio/ et ses sous répertoires sont accédables en écritures par les seuls membres du groupe laricio qui contient les utilisateurs meredieu et coligny. Les autres utilisateurs ne peuvent pas faire commit dans ces répertoires.

De façon générale, les modélisateurs ont les droits ouverts sur les répertoires de leurs projets (ex pour ancelin : capsis/lib/biomechanics/ et sous répertoires éventuels, par le biais d'un groupe biomechanics dont il fait partie), ainsi que sur les répertoires (et sous répertoires) communautaires : capsis/extension/, capsis/util/methodprovider/, capsis4/etc/, etc. Des répertoires sont accessibles seulement au groupe des développeurs (ex : capsis.kernel, capsis.gui, capsis.util...).

Note : Comme les autorisations ne sont pas fixées au niveau fichier, l'ouverture de capsis4/bin à tous les membres du groupe cvs (tous les modélisateurs et développeurs en font partie) pour leur permettre de modifier makefile.jib leur permet également de modifier les autres fichiers de bin/. La discipline est donc de rigueur (ne modifiez pas par mégarde install.bat ou licence_fr.html...).

Remarque : Si vous notez des anomalies quant aux droits d'accès, prévenez l'administrateur cvs pour vérifications / modifications.

4.3 Problème sur commit - version plus récente dans le dépôt

cvs server: Up-to-date check failed for 'model/IdCard.java'

Si lors d'un commit vous obtenez un message de ce type, cela signifie que quelqu'un d'autre a fait commit avant vous sur le(s) fichiers concernés. Vous devez d'abord faire update pour prendre en compte aussi ses modifications, puis recompiler et tester en local, avant de recommencer votre opération commit.

4.4 Problème sur update - conflit lors d'une fusion

cvs server: conflicts found in model/IdCard.java

Ce message indique qu'une fusion entre la version du dépôt et la version locale du fichier n'a pas pu se faire automatiquement.

Il faut fusionner manuellement dans la copie locale (voir section suivante) avant de faire commit. Pour visualiser les lignes en conflit dans SmartCVS, utiliser la commande compare (ex: Compare... Local file with same revision (What was changed locally ?)). Un diff permet de visualiser les lignes différentes.

Vous pouvez choisir l'une des deux versions de remplacement ou bien décider que les deux approches ont échoué et réécrire un passage complet. Tant que vous n'aurez pas fait une correction, vous ne devriez pas pouvoir faire commit. Faites les corrections dans votre copie locale (qui contiendra des messages pour marquer les blocs en cause) avec un éditeur, faites refresh dans SmartCVS, puis remontez la version corrigée dans le dépôt.

4.5 Résolution manuelle de conflits

La résolution manuelle de conflit se base sur le fichier local résultant de l'opération update, qui contient les blocs "non fusionables" des deux versions (locale, puis dépôt) entourés de marqueurs (voir exemple ci dessous).

<<<<<<<< filename
// ce bloc 1 dans la copie locale
========
// n'est pas fusionnable avec ce bloc 2 du dépôt
>>>>>>>> 1.2

Pour chaque bloc conflictuel, choisir le bloc 1 ou le bloc 2, ou bien suivant les cas, faire une fusion des deux, puis enlever tous les marqueurs (<<<<<<<<========>>>>>>>>).

CVS refusera tout tentative de commit tant que le fichier n'aura pas été édité et sauvé.

Note : Comme la fusion n'a pas pu ne faire automatiquement, une copie de sauvegarde de votre version locale a été faite dans le même répertoire avant l'update dans un fichier portant le même nom, précédé de ".#".

Note : Pour aider les fusions conflictuelles, il est possible d'utiliser jmingle. Cet utilitaire permet de passer en revue les blocs en conflits un par un et pour chacun d'entre eux, de choisir la version correcte interactivement. Le résultat est ensuite sauvé sur disque, en attente d'édition éventuelle pour peaufiner la fusion, puis de recompilation (capsis4/bin/jmingle.bat ou jmingle.sh).

4.6 Comment se préserver des collisions

Malgré la modeste contrainte qu'imposent les commit fréquents, une politique de mises à jour rapprochées peut faire gagner beaucoup de temps en évitant la survenue de collisions. Si CVS sait en effet identifier, voire régler tout seul, les conflits de révision, cela ne dispense pas les utilisateurs d'agir avec prudence et bon sens.

Conseil : En règle générale, il est souhaitable de vérifier qu'on dispose bien d'une révision "à jour" avant de se lancer dans une intervention. Pour s'en assurer : commande status (réponse Up-to-date ou Needs-update/checkout), ou de façon plus systématique : update sur les fichiers choisis avant de commencer les modifications locales.

On veillera par ailleurs à ne pas intervenir sur la mise en forme des lignes ou paragraphes déjà édités lorsque ce n'est pas indispensable, surtout si elle n'en modifie pas le sens où la compréhension. Ceci afin de ne pas rendre inutilement fastidieuse la lecture des listings produits par diff et accessoirement de ménager l'espace disque sur le serveur (d'après G. Mariano).

4.7 Avant checkout - ma version (hors CVS) est plus récente que celle du dépôt

Vous vous apprêtez à passer sous CVS alors que la version de référence de votre module (bibliothèque) est sur votre machine. C'est le cas si vous avez travaillé sur votre version depuis la dernière synchronisation avec la plate-forme Capsis par le technicien du projet Capsis ;-).

Marche à suivre pour un module (une bibliothèque) :

Sauver votre copie de référence en la renommant : capsis4/ -> capsis4reference/
Procéder au checkout (cf. 2.1) pour obtenir une copie locale sous CVS : capsis4/
Dans la copie locale, pour votre module (biliothèque), supprimer tous les fichiers (.java, .class, .properties, .html...) sans toucher aux répertoires (model/, gui/ CVS/...). Les remplacer par les versions plus récentes de capsis4reference/ par copier-coller dans un gestionnaire de fichiers (ignorer les .class).
Recompiler en local avec jib (cf. 3.6) et tester jusqu'à obtenir une version stable.
Sous SmartCVS, faire des add pour chaque fichier ajouté, éventuellement des remove pour chaque fichier supprimé, puis sélectionnez le répertoire de votre module (bibliothèque) et faites commit pour remonter vos modifications dans le dépôt.

Remarque : pour les extensions, voir 4.8.

4.8 Gestion des extensions - droits en écriture pour commit

Les modules et bibliothèques sont gérés par leurs auteurs. Des droits d'accès ont été disposés dans le dépôt pour ne permettre leur modification qu'à leurs auteurs et aux développeurs.

Remarque : si vous notez des anomalies / erreurs apparentes dans l'attribution des droits d'accès, prévenez l'administrateur.

Certaines parties de la plate-forme sont accessibles en commit seulement pour les développeurs (noyau, pilotes...).

Les extensions sont à part : elles sont modifiables par tous les modélisateurs. Vous devez donc procéder avec discipline pour ne pas modifier à tort le travail des autres membres de la communauté Capsis :

Pour les extensions spécifiques à votre modèle (ex: format d'import, visualiseur spécifique...), vous pouvez les gérer individuellement, elles ne concernent que vous.
Pour les extensions génériques (non spécifiques à votre modèle) : ne faites pas de commit sans l'accord de l'auteur de l'extension (@author dans le commentaire de classe). Si vous pensez que des améliorations sont possibles, discutez en avec lui avant d'agir.

Certains fichiers sont accessibles par tous :

les fichiers de configuration du répertoire etc/, notamment capsis.extensions (déclaration de nouvelles extensions)
bin/makefile.jib (pour modifier les commandes qui vous concernent)

4.9 Problème de changements majuscules / minuscules dans un nom de fichier depuis Windows

cvs [server aborted]: received abort signal
cvs: hash.c:312: findnode: Assertion 'key != ((void *)0)' failed.

[ou cvs: commit.c:2040: checkaddfile: Assertion '*rcsnode == ((void *)0)' failed.]

Sous windows, vous avez essayé de renommer un fichier en modifiant seulement la casse (maj./min.) de certaines lettres. Vous rencontrez des problèmes pour répercuter la modification dans le dépôt (sur add/commit).

Le problème est lié au fait que Windows ne fait pas la différence entre les majuscules et les minuscules dans ses noms de fichiers (pour lui, nomFichier et NOMfichier représentent le nom d'un même fichier).

Pour régler le problème, envoyez le fichier à l'administrateur cvs par mail. Il devra supprimer le fichier directement du dépôt sur le serveur avec un gestionnaire de fichiers, puis faire le add/commit depuis sa propre copie locale avec son client SmartCVS sous Linux.

4.10 Add sur des fichiers d'un nouveau répertoire ok, mais impossible de commiter à nouveau dans le répertoire

Lors d'un add sur des fichiers d'un nouveau répertoire, le répertoire est créé dans le dépôt. Le script de mise à jour des droits qui tourne régilièrement sur le serveur ne connaissant pas ce nouveau répertoire, il n'autorise par défaut l'écriture qu'aux membres du groupe des dévéloppeurs. Il vous faut demander la modification du script sur le serveur pour qu'il vous autorise l'écriture dans le répertoire.

4.11 Des erreurs répétées lors des commit et des statuts bizarres sur les fichiers d'un répertoire

En cas de problèmes répétés et apparement insolubles sous SmartCVS concernant un répertoire, il y a une solution systématique pour tout remettre à plat. Ces problèmes peuvent subvenir en cas d'incohérences dans les fichiers de gestion CVS/ de votre copie locale pour plusieurs raisons, par exemple une copie de répertoire pour prendre exemple sur un module / une extension existant(e) et l'oubli de supprimer les répertoires CVS/ de la nouvele copie avant renommage des fichiers et connexion avec le serveur (-> beau micmac).
Dans ce cas, procéder comme suit :
- dans votre copie locale, avec un gestionnaire de fichiers, déplacer le répertoire posant problème en dehors de la copie locale capsis4/ (copie de sauvegarde) ;
- dans SmartCVS, procéder à un update de la copie locale (complète, curseur sur capsis4/), on récupère ainsi une version propre du module / extension avec des répertoires CVS/ corrects dans la copie locale ;
- recopier les fichiers nécessaires depuis la copie de sauvegarde (copie avec le gestionnaire de fichiers) dans l'arborescence ainsi nettoyée (ne copier que les .java, .html... surtout aucun répertoire CVS/) ;
- dans SmartCVS, commit sur ces fichiers pour mettre à jour le dépôt sur le serveur.

4.12 Problème sur checkout - checkout: failed to create lock directory for /opt/cvs/amapkit ... Permission denied

fc - 17.10.2008 (problème griffon : checkout impossible sur amapkit).

Le user doit avoir les droits en écriture dans le dépot, ex: /opt/cvs par appartenance au groupe "cvs". Le répertoire "cvs" doit avoir des droits du genre :

drwxrwsr-x 5 root cvs 4096 2008-10-17 14:44 cvs

si ca n'est pas le cas, pour s'assurer que les ont le bit groupe correctement posistionné :

chown -R :cvs /opt/cvs

Pour s'assurer que les nouveau répertoires et fichiers ajoutés utiliseront le groupe cvs plutot qu'un autre :

chmod -R g+ws /opt/cvs

Si dans CVSROOT/config, l'option LockDir est positionnée (ex: LockDir=/var/lock/cvs), il faut s'assurer que le user a les droits en écriture dans le répertoire en question (par l'appartenance au groupe cvs). (C'était ca pour notre problème).