Utilisation de GIT : Différence entre versions

Version du 14 mars 2007 à 18:07

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.

Pour chaque sortie de patch ou version, il faut mettre un tag sur la branche.

exemple :

• Tag version-6-2-0 sur le tronc et création de la branche PATCH-6-2-0
  • Tag version-6-2-1 sur PATCH-6-2-0
  • Tag version-6-2-2 sur PATCH-6-2-0
• Tag version-6-3-0 sur le tronc et création de la branche PATCH-6-3-0
  • Tag version-6-3-1 sur PATCH-6-3-0
  • Tag version-6-3-2 sur PATCH-6-3-0
  • Tag version-6-3-3 sur PATCH-6-3-0

Programme de reprise

Lors de la mise à jour d'ovidentia, tout le programme de reprise sera exécuté, il appartient au développeur de faire les tests nécessaires afin de ne pas effectuer une action plusieurs fois. Pour chaque version, il sera possible de définir un numéro de version minimal pour l'installation d'origine d'ovidentia, dans le but de forcer des mises à jours par paliers en cas de gros écarts de version. Comme tout le programme est exécuté à chaque mise à jour cela permet de supprimer de temps en temps les parties du programme qui ne sont plus utilisées.

Par défaut, une version peut être mise à jour si le numéro de la nouvelle version est plus grand. Quand un branche de patch est prolongée au dela de la version suivante du tronc, il est possible qu'une mise à jour se fasse d'une version récente vers une version plus ancienne. par exemple de 6.2.3 vers la 6.3.0 alors que la 6.2.3 est sortie après la 6.3.0 dans ce cas il sera possible dans la dernière version d'interdire la mise à jour vers des numéros spécifiés dans la configuration.

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.