Utilisation de GIT

Gestion des versions du noyau dans CVS

A partir de la version 6.2.0, la gestion de versions du noyau d'Ovidentia se fera comme suit:

• Les versions stables sont celles ayant pour version X.Y.0
• Les versions X.Y.Z sont les versions patchées de la version X.Y.0
• Le nombre Y est incrémenté à chaque ajout d'une ou plusieurs petites fonctionnalités
• Le nombre X sera incrémenté quand il s'agit d'une version majeure

A chaque sortie d'une version X.Y.0, considérée comme stable, une branche de nom PATCHS-X-Y-0 sera créée dans CVS pour les corrections des bugs constatés dans cette version.

Si un bug est constaté sur les versions X.Y.0 ou X.Y.Z:

• Le développeur récupère la branche PATCHS-X-Y-0
• Qualifie le problème
• Corrige le bug
• Commit la correction
• Fais un merge avec le tronc principal.
• Vérifie que la correction fonctionne aussi dans le tronc principal
• Fourni le ou les patchs au support par l'intermédiaire de l'application "Gestion des patchs" qui se trouve

sur le portail extranet http://www.cantico.fr

Il appartient au développeur de s'assurer que ses corrections ont été mergées dans le tronc principal de CVS.

Il appartient à la personne qui sort la version X.(Y+1).0 que les branches PATCHS ont bien été mergées.

Cette méthode permet:

• d'avoir des branches PATCHS de versions stables.
• de facilement sortir les patchs pour une version X.Y.0

La branche principale sera toujours instable jusqu'à la sortie de la version X.Y.0.

Les versions stables se trouveront dans les branches PATCHS-X-Y-0.

Développement personnel ou expérimentation

Tout besoin de développement personnel pour des expérimentations doit se faire dans une branche à part. Le nom de la branche doit porter les initiales du développeur ayant initié la branche. Le nom de la branche commence par les initiales du développeur, un tiret, et un libellé. Par exemple : SZ-SYNCHML

Faire un update à chaque utilisation de CVS

• Avant de travailler sur n'importe quel fichier.
• Avant de faire un commit

Lire les messages de CVS à la suite d'une action

Toujours lire les messages renvoyés par CVS à la suite d'une action. ( Dans le cas de WinCVS, les messages sont affichés dans la fenêtre du bas ).

Messages de commit

• Lors d'un commit, toujours donnez un message décrivant ce qui a été fait.

Le message doit être en anglais. Ne jamais laisser ce message vide.

• Si la mise à jour est mineure ( faute d'orthographe, correction html, etc... )

mettez : Minor change afin que la personne qui lit le log comprend que c'est bien une modification mineure.

• Si la mise à jour corrige un bug, préfixez le message par BUGM #XXX:

'BUGM #124: message

• • BUGM : signifie que le bug est enregistré dans Mantis
  • XXX: est le numéro du bug dans Mantis.
  • message: texte court décrivant le bug ( Ne jamais laisser ce message vide) .

Par exemple:

BUGM #124: Error SQL when you try to access calendar

Le fait de donner le numéro du bug permet d'avoir plus de détails sur le bug en consultant la base de Mantis.

Client CVS

Lors de l'utilisation de wincvs par SSH, le mot de passe est enregistré en clair dans les sous-répertoires CVS de chaque répertoire du projet. Il faut faire attention de ne pas livrer un package avec les sous-répertoires de CVS.

Autre client CVS linux/windows : lincvs

Ajouter un projet dans CVS (add-on, script...)

Aucune indication sur l'environnement CVS doit être remplie car des informations doivent restées privées à Cantico.

Seule remarque : Après l'ajout d'un nouveau projet (add-on, script...) dans CVS, des droits d'accès sur la machine qui héberge CVS doivent être appliqués sur le système de fichiers. Contactez l'administrateur pour cette opération.