CVS
La CVS est le moyen de développement choisi pour le BR.
Présentation de CVS
Principe de base
Le principe d'une CVS est de centraliser le développement en fournissant un moyen simple de programmer en groupe. Chaque développeur a chez lui une copie personnelle du projet sur laquelle il fait ses modifications. Quand il est satisfait, il valide ses modifications (commit) et tout le monde peut y avoir accès.
La CVS gère également des branches qui permette de continuer à développer sur une branche 'instable' pendant qu'on décide de 'releaser' une version stable.
Chaque projet est appelé un module.
Utilisation
Récupérer une copie locale
cvs -d $user$@gwennoz:/home/cvs co [-r $branche$] $module$
Cette commande récupère sur le serveur la dernière version du module dans la branche précisée (branche principale par défaut). La copie est stockée dans ./$module$/
Récupérer les modifications des autres
cvs up [-d] [$fichiers$]
Récupère la dernière copie des fichiers spécifiés. Le -d est nécessaire pour récupérer de nouveaux répertoires
Valider ses modifications
cvs ci [$fichiers$]
Cette commande envoie au serveur les fichiers modifiés. Si aucun conflit n'est détecté la modification est validée.
Il faut toujous updater la copie locale avant de commiter ses modifications.
Ajouter un fichier/répertoire
cvs add $fichiers$
Ajoute les fichiers spécifiés à la CVS. Les répertoires sont ajoutés immédiatement, par contre il faut commiter les fichiers ajoutés pour valider l'ajout.
Supprimer un fichier
cvs remove $fichiers$
Supprime un fichier du module. La suppression sera effective après un commit.
La copie locale doit être supprimée avant !!!
Créer une branche
cvs tag -b $branche$
Crée le branche spécifiée. Pour travailler sur cette branche, il faut faire un checkout de cette branche
Backporter
cvs up -j$version1$ -j$version2$ $fichier$ cvs ci -m 'Backport de $fichier$'
Effectue les modifications qu'il y a eu entre la version1 et la version2 sur fichier.
Attention à mettre version1 et version2 dans le bon sens, sinon on supprime les modifications au lieu de les appliquer.
Installation de la CVS sous Windows
TODO : remplir cette partie !!!
Modules présents sur la CVS
Cette partie n'a pas pour but d'être exhaustive, mais elle doit tout de même donner une liste la plus complète possible des modules présents sur la CVS.
CVSROOT arpwatch bin-root cocoaxnet -> xnet/cocoaxnet config config/etc config-etc -> config/etc docs frankiz -> fankiz2 frankiz2 infobr mxnet -> xnet/mxnet news news-bin -> news/bin news-etc -> news/etc news-public_html -> news/public_html projet -> xshare/projet qrezix -> xnet/qrezix qrezix-plugins -> xnet/qrezix-plugins qrezix2 -> xnet/qrezix2 siteeleves test web xnet xnet/cocoaxnet xnet/cpanet xnet/doc xnet/mxnet xnet/qrezix xnet/qrezix-plugins xnet/qrezix-plugins/smilix xnet/qrezix-plugins/xplo xnet/qrezix2 xnet/rexnet xnet/xnet-tcp xnet/xnetserver xnet/xnetserver-old xnetserver -> xnet/xnetserver xnet-tcp -> xnet/xnet-tcp xplo+ xplorateur xshare
Module | Détails |
---|---|
CVSROOT |
Module d'administration de la CVS... |
arpwatch | Arpwatch du BR, développé par Schmurtz (BR2002). |
bin-root |
Scripts d'administration, maintenance des serveurs |
config |
Module regroupant tous les fichiers de configuration critiques. Ce module contient un sous-module :
|
docs (DEPRECATED) |
Ancien module contenant tous les développement du BR visant à produire une documentation. Il contient les sous modules :
|
frankiz2 |
Module CVS de la version dite 2 du site web des élèves. Ce modules contient l'intégralité du code de FrankizII. |
infobr |
Les infos BR de différents BR. On pourra noter en particulier la présence de l'infoBR du BR2003. Il contient les sous-modules :
|
news |
Contient tous les fichiers de configuration et les scripts des news. |
siteeleves (DEPRECATED) |
No comment... |
test |
No comment |
web |
Module du site externe du BR. Ce module a pour but de permettre le développement d'un site web qui présente le Binet Réseau, à la fois accessible en interne (pour les élèves présents sur le Résal) et en extérieur (en particulier les membres de Federez). |
xnet |
Ce module regroupe tout ce qui concerne xNet. Il contient les sous modules suivant : Modules mineurs :
cocoaxnet Le client xNet conçu par les X99 pour une intégration parfaite dans MacOS. qrezix qRezix est le principal client xNet. Ce module contient différentes version du programme :
qrezix-plugins Contient les plugins pour qRezix. Les plugins actuellement présents sont :
qrezix2 Module censé accueillir le travail de développement de la future version 2.x de qRezix. xnet-tcp Serveur xnet de prod. |
xplo+ |
Version du moteur de recherche Xplorateur codée par leolio avec un moteur d'indexation en C. |
xplorateur |
Moteur d'indexation des FTP et de recherche Xplorateur II. Attention : La version de prod actuelle a été modifiée depuis la version CVS (en particulier pour ce qui est de l'obtention de la liste des utilisateurs). |
xshare (DEPRECATED) |
Modules de l'ancienne interface des X-shares. |
Administration de la CVS
Actuellement la CVS est divisée en deux principales parties :
- le cvs en ssh (dans /home/cvs) qui est utilisable par toutes les personnes qui sont dans le group cvs sur gwennoz
- la cvs en pserver qui fournit un accès public anonyme à une partie des modules en lecture seule.
CVS over SSH
Administration de la CVS
La CVS est gérée par le modules CVSROOT qui contient un certains nombre de données de configuration et d'utilitaires. Les plus notables sont :
La gestion des pseudo-modules avec le fichier modules. Ce fichier permet d'associer un nom de module à une autre module. Par exemple, on a un programme blah dans le grouope chombier (donc le module pour blah c'est chombier/blah), on peut définir un module blah facilement accessible dans ce fichier modules :
#================================= # blah pseudo modules #================================= blah chombier/blah
Le mail de commit est géré un un utilitaire très complet et produisant des mails propres et lisibles appellé 'activitymail'. On ne rentrera pas en détail dans le fonctionnement de ce script perl, mais ce qu'il faut savoir c'est :
- le script doit être appelé par les fichier commitinfo, loginfo, ... pour que la gestion des logs soit faite par activitymail
- activitymail peut-être modifié directement dans /home/cvs/CVSROOT/activitymail... même si ce n'est à faire qu'en cas d'extrême nécessité, c'est pratique pour réparer le script après un commit foireux...
Gestion des droits
Il est facile de limiter l'accès à certains modules uniquement à certaines personnes. Il suffit de donner des droits spécifiques sur le répertoire de ce module. Ceci permet par exemple de rendre le module de configuration des serveurs accessible uniquement aux root (membres du group adm en fait), le modules d'administration du serveur de news uniquement aux newsmestres (groupe news), ou encore le module CVSROOT uniquement aux membres du groupe cvsadmin.
Actuellement les modules sur lesquels il y a des limitations d'accès sont :
CVSROOT -> cvsadmin bin-root -> adm config -> adm news -> news
Anoncvs
Configurer et utiliser le pserver
Le pserver est géré par cvsd (disponible sur l'arbre gentoo). Actuellement il utilise une configuration relativement peu sécurisée, mais qui a le mérite de marcher. La configuration se trouve dans /etc/cvsd/cvsd.conf. Les principales données de configuration actuelle sont :
Uid root Gid cvsadmin Listen * 2401 Repos /home/anoncvs
Le pserver n'est configuré que pour un compte anonyme, dont l'utilisation se fait en 2 temps :
- se logguer (mot de passe vide) sur la CVS avec:
cvs -d :pserver:anoncvs@gwennoz:/home/cvs login
- télécharger les sources :
cvs -d :pserver:anoncvs@gwennoz:/home/cvs co [comme d'hab]
Administrer les modules de l'anoncvs
Pour mettre un module dans l'anoncvs, il suffit de créer un lien symbolique depuis le module de la CVS normale vers /home/anoncvs.
Les modules actuellement présents sont :
faq-frankiz infoBR (InfoBR2k3) mxnet qrezix qrezix-plugins xnetserver (ancien serveur) xnet/cocoaxnet xnet/doc xnet/qrezix xnet/qrezix-plugins xnet/xnetserver (ancien serveur)
Retour : Accueil