Salut,
Installe subversion, le versionning des commit est mieux fait que dans CVS.
A+.
http://subversion.tigris.org

Je ne sais pas si ça peut aider, mais sait-on jamais :

http://www.think-underground.com/index. … is-eclipse

Hello,

  Tu devrais franchement considérer Subversion, qui corrige plusieurs incohérences peinibles de CVS (entre autres: perte des versions en cas de renommage d'un fichier, impossibilité de déterminer clairement si un ensemble de versions spécifiques représente un état cohérent ou non du developpement du soft, etc..)

  Ensuite, si c'est pour du developpement privé, et que les personnes qui doivent avoir accès au CVS ont aussi un compte sur le dit serveur, c'est beaucoup plus facile d'utiliser ssh que le pserver (sans compter l'amélioration au niveau de la sécurité.)

  Pour cela, il te suffit de remplacer "pserver" par "ext" (comme extended) dans l'URL de ton repository, et de configurer une variable d'environnement en plus:

$ export CVS_RSH=ssh

Il faut aussi s'assurer que l'utilisateur a les droits appropriés pour accéder au repository, par exemple en créant un groupe "cvs" dans lequel tu mettras tous tes utilisateurs, et qui aura droit d'écriture sur le repository. Sinon, côté serveur, la méthode ssh ne demande aucune autre configuration, ça devrait marcher tout seul.

  La commande cvs login devient alors inutile. A chaque commande CVS, il va invoquer SSH, et te demander ton mot de passe. Tu peux éviter ceci en utilisant des clefs ssh, soit avec une clef sans mot de passe (pas recommandé) soit avec ssh-agent, qui permet d'entrer le mot de passe de la clef une fois pour toutes.

  Note que la méthode ssh fonctionne aussi de manière transparente avec Subversion.

  Si tu as besoin de plus d'explications, n'hésite pas.

++

Alors, en deux mots:

Méthode 1 (plus facile):

1) Sur la machine client, générer une clef ssh:

user@client$ ssh-keygen -t dsa

et laisser le mot de passe vide.

2) Sur la machine serveur: s'assurer que le répertoire ~/.ssh (configuration ssh pour l'utilisateur) existe

user@serveur$ mkdir ~/.ssh

3) Transférer la clef publique du client vers le serveur. Sur la machine client:

user@client$ cat ~/.ssh/id_dsa.pub |ssh user@serveur 'cat >>.ssh/authorized_keys'

4) Sur le serveur, vérifier les permissions de la clef

user@serveur$ chmod 644 ~/.ssh/authorized_keys

Et normalement c'est tout bon.

Méthode 2: (plus sécure)

1) Pareil que première méthode, mais mettre un mot de passe a la clef

2) La ca dépend des distributions, certaines le font automatiquement, mais il faut que ssh-agent soit démarré et les variables d'environnement adéquates exportées partout. Usage typique, avant l'initialisation de X:

user@client$ ssh-agent >~/.agent && source ~/.agent

(ssh-agent produit en sortie un shell script qu'il faut executer pour avoir
les variables d'environnement correctes)

Une fois que l'agent est démarré,

user@client$ ssh-add

Qui va te demander le mot de passe de la clef, et la charger dans l'agent.

Et a partir de la, ca devrait marcher tout seul pareil.

++
BOFH