Le CVS et son utilisation
Un article de LodelWiki.
Explication concernant le fonctionnement du CVS de Lodel.
Attention! Cette page est en cours d'élaboration.
Sommaire |
[modifier] Fonctionnement
[modifier] Numéros de version
Ils ont la forme x.y.z.
- x est le numéro de version majeure : il est incrementé lorsque de grosses modifications ont été apportées, et qui cassent la compatibilité avec la version majeure précédente x-1, nécessitant donc de grosses modifications dans les projets pour la migration.
- y est le numéro de version mineure : il est incrémenté quand il y a de nouvelles fonctionnalités, évolutions, corrections de bugs etc.. Par contre un projet basé sur une version lodel x.y doit être compatible avec une version lodel x.y-1.
- z est le numéro de version de correction : il change quand il y a eu simplement des corrections de bugs par rapport à la version x.y.z-1.
Nota Bene : le numéro x est pour le moment à 0 car les critères permettant de dire que Lodel est stable et que la compatibilité entre version existe ne sont pas remplis.
[modifier] Création des branches et des tags
Les tags dans CVS permettent d'étiqueter les versions successives de Lodel. Ceci pour une branche Lodel donnée.
- Un tag est créé pour chaque version x.y. Ce tag étiquette la version x.y de la manière suivante, nommé de la façon suivante :
version_x_y cvs rtag version_x_y lodeldevel (la commande cvs rtag permet de tagger sans faire référence à un bac à sable particulier).
- Puis, une branche est créée pour chaque version x.y. Elle est destinée à recevoir les corrections de bugs rapportés au fur et à mesure sur cette version. Leur convention de nommage est :
version_x_y-bugfixes-branch
Utilisation du tag version_x_y pour créer la branche version_x_y_bugfixes-branch :
cvs checkout -r version_x_y lodeldevel cd lodeldevel cvs tag -b version_x_y-bugfixes-branch
Travail sur la branche créée :
cvs checkout -r version_x_y-bugfixes-branch lodeldevel
Les commit se feront automatiquement sur cette branche.
- Ces branches contiendront des tags de version corrective au fur et à mesure des corrections apportées (si celles-ci sont l'objet d'une release) :
version_x_y_z
Tagger une version corrective sur une branche particulière :
cvs checkout -r version_x_y-bugfixes-branch lodeldevel cvs tag version_x_y_z
- Le développement se fait lui sur le tronc du CVS.
- Il faudrait réfléchir à la possibilité de créer des branches pour des versions expérimentales. Par exemple si l'on veut tester Ajax avec Lodel ou encore PHP5 avec Lodel on peut imaginer la création de branches spécifiques du genre version_x_y_exp_ajax (en taggant le début de la branche avec version_x_y_exp_ajax_begin, CVS ne permettant pas de récuperer le début d'une branche). Si les fonctionnalités de cette branche doivent être ajouter à la version en cours, il reste possible de faire un merge de la branche avec le tronc.
Cette organisation permet de :
- pouvoir sortir des versions correctives de versions antérieures tout en continuant à travailler sur la version en cours.
- avoir un tronc correspondant toujours à la dernière version de Lodel, la version dite 'unstable'.
- avoir une succession de versions dites stables marquées par des tags et des branches contenant leur(s) correctif(s).
[modifier] correction de bug sur le CVS
- il faut que le but soit déclaré sur Sourceforge.
- se baser sur la version concernée pour modifier la bonne branche du CVS
[modifier] critères de publication d'une release
[modifier] versions majeures et mineures
Une version majeure correspond à l'accomplissement des améliorations et corrections d'une roadmap. La liste des bugs pour cette version doit aussi être proche de zéro.
- Il peut alors être publié des release candidate (RC). Un tag est alors appliqué :
version_x_y_RC1
Ceci implique que seules les corrections de bugs seront acceptées. Il peut y avoir jusqu'à trois RC.
- Pour l'instant il n'y a pas de version alpha ou beta, même si cela a été utilisé dans les versions antérieures de Lodel. Il est possible cependant que des versions bétâ soient utilisées par la suite.
- une version corrective (mineure) ne sort que pour une version majeure, puisque cette correction s'applique sur la branche correspondant à la version majeure.
[modifier] bugs critiques
En cas de bug critique, une release peut-être publiée rapidement. Il faut prévoir tout de même environ une semaine entre la correction d'un bug critique et une release afin de pouvoir éventuellement y adjoindre d'autres corrections mineures. Sont considérés comme des bugs critiques :
- des failles de sécurité
- problèmes empêchant le fonctionnement correct de Lodel et étant répercuté par un grand nombre d'utilisateur.
[modifier] bugs non critiques
Les corrections de bugs non critiques de donne lieu a des release que lorsque l'équipe de Lodel le juge nécessaire.
[modifier] Utilisation pour développeurs
Pour avoir un accès en lecture/écriture au CVS de Lodel, il faut disposer d'un compte.
- définir la variable d'environnement CVSROOT :
export CVSROOT=":pserver:<nomutilisateur>@lodeldevel.revues.org:/usr/local/cvs"
- se connecter au serveur CVS
cvs login
- créer un bac à sable
cvs checkout lodeldevel
ou
cvs checkout -r version_x_y_bugfixes-branch (pour travailler sur des corrections de bug antérieures)
- ensuite déposer un fichier en commitant :
cvs commit <nom_fichier>
- mettre à jour sa copie locale :
- d'un fichier
cvs update <nom_fichier>
- du projet entier ou d'un répertoire en particulier. Se placer à la racine du projet ou du répertoire, puis :
cvs update
- supprimer un fichier
cvs del <vieux_fichier> cvs add <nouveau_fichier> cvs commit <nouveau_fichier>
- lors de commit il est très important de respecter le fomulaire de saisie.
Type:ttt<retourchariot> Descr:ddd
- ttt peut etre :
- F pour l'ajout de fonctionnalité
- BM pour la correction de bug majeur
- Bm pour la correction de bug mineur
- S pour la correction de faille de sécurité
- O pour optimisation du code php ou lodelscript
- A autres (ce type regroupant les modifications peu importantes qui ne sont pas des bugs : ajout d'image, suppression de fichiers
- ddd peut être n'importe quelle phrase non nulle
- Il faut éviter de faire des commit trop souvent pour ne pas "polluer" les logs.
- Avant un commit, faire un maximum de tests pour vérifier le fonctionnement du logiciel après mise à jour et faire valider.
- Penser a se deloger quand vous avez fini de travailler. Ca évite de faire trainer votre mot de passe sur le disque.
- Menu Admin/Logout
[modifier] Utilisation anonyme
Le CVS de Lodel est accessible en lecture pour les utilisateurs anonymes.
- définir la variable d'environnement CVSROOT :
export CVSROOT=":pserver:anonymous@lodeldevel.revues.org:/usr/local/cvs"
- se connecter au serveur CVS et récupérer les fichiers
cvs login (il n'y a pas de mot de passe) cvs checkout lodeldevel
- mettre à jour les fichiers
cvs login cvs update -Pd (-P pour supprimer les répertoires vides, -d pour récupérer les nouveaux répertoires)
[modifier] Administration
cf. documentation interne de l'administrateur du serveur.
