protis comme serveur CVS

les CVSROOT:

• VFdecomp: CVSROOT=/space/cvs/latp/edp (groupe edpdvlpt)
• LGD: CVSROOT=/space/cvs/cvsroot (groupe cvs)
• STOK: CVSROOT=/space/cvs/latp/bhe
• marchesa: CVSROOT=/space/cvs/latp/marchesa

doc. A. Cadiou

useradd -g cvsgrp -u /home/cvs
au lieu de
useradd -g cvsgrp -d /home/cvs cvs

Questions à poser: - p12: création de CVSROOT dans $CVSROOT, mais que se passe t il si plusieurs projets? +ieurs $CVSROOT? et que se passe t il si un projet contient plusieurs modules?

ensuite, pour identifier une base, c'est le répertoire contenant au moins CVSROOT qui l'identifie:

hobbit-henry% setenv CVSROOT protis:/space/cvs/latp
hobbit-henry% cvs status
Cannot access /space/cvs/latp/CVSROOT
No such file or directory

il faut que tous les répertoires de la base soient accessibles en écriture au groupe cvs

mimosa-root% find . -type d -exec chgrp edpdvlpt {} \;
permet de changer le groupe pour tous les reprtoires d'un projet

Problème: on positionne CVSROOT à une certaine valeur, par exemple /home/cvs/base2 si on fait “cvs status”, cette commande en fait va afficher des informations sur /home/cvs/base1 parce que il y a des repertoires CVS dans le répertoire courant! Quelle doit etre la stratégie?: - on doit accéder à une base cvs par ssh - dans notre répertoire de travail, il existe deja des projets cvs - il faut donc donner le nom du répertoire qu'on veut récupérer, par exemple VFdecomp après avoir défini la base à /space/cvs/latp/edp

http://fusion.gat.com/docview/cvs_intro.html

Il semble qu'il suffise de créer le répertoire $CVSROOT avec le setgid pour que tout se passe bien sur les sous répertoires?

Voici un point de vue:

"Also you can browse your repository by using cvsweb.

I'm evaluating to use a repository to store my C/C++ projects, but I admit that I'm tempted to use subversion in place of cvs. One of the best advantages, from my point of view, of subversion versus cvs are:

a) Copies and renaming files seem better under subversion. In most cases with CVS you will loose the files history.

b) (I read that of) Better binary file handling, it is usefull when you have to work with a lot of images such under web development. In fact with cvs if you commit 100 modifications to an image file, the remote repository will have 100 copies of the same file....what a waste of space. Subversion uses an internal algorithm to handle binary files, so in pratice it does not store a new copy of an image when you commit a modification. Only differences are send. In pratice binary files are handled the ``same way'' as text files, more or less.... ;)

I used CVS and Subversion for few days only, so point a) is not that clear to me. Point b) is something that web developers should think of.

IMHO, CVS seems more fine, with some limitations, to text-only projects. For a web-development, due to lot of images, I'd try subversion.

There exists an Apache module for subversion, but it works under 2.x. The reason seems due to web_dav support of 2.x series.

CVS is a more stable and mature product, though.

Many CVS competitors, such as subversion, offer the import of an existing CVS repository, so starting with CVS would let you to switch to another version control ``easily''...if you evaluate that CVS doesn't do something you need."