Utilisation de GIT : Différence entre versions

De OviWiki
Aller à : navigation, rechercher
(Messages de commit)
(Gestion des versions du noyau dans CVS)
Ligne 34 : Ligne 34 :
  
 
Les versions stables se trouveront dans les branches '''PATCHS-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
  
 
=== Développement personnel ou expérimentation ===
 
=== Développement personnel ou expérimentation ===

Version du 14 février 2007 à 08:55

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

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.