blog.bressure.net

Il est courant dans un projet d’insérer dans les sources la révision du fichier. Cela est accomplit par le système de versionnage de source par un mécanisme de substitution d emot clé. Par exemple le mot clé Revision balisé par $Revision:$ est automatiquement remplacé par subversion par $Revision: 70$ si la révision du fichier est 70.

Ce mécanisme est très utile si on veut pouvoir raccroché un source à un révision en dehors de l’environnement de développement. Cela est en l’occurence utile quand on souhaite remonté un bug dans un projet en python. Imaginons un projet ecrit en python. Python étant un langage interprété, l’application est distribuée sous forme de fichiers sources .py. Lorsqu’une exception survient, python peut rapporter la pile d’execution constituant un début rapport d’erreur. Mais il faut encore associer cette pile à une version de l’application. Quand l’application est en version finale, on peut inclure dans le livrable la version commerciale de l’application mais il est encore plus facile pour le développeur d’inclure dans le rapport la révision des sources. Et c’est encore plus vrai quand l’application est en phase de développement ou de beta-test.

C’est exactement ce qui m’arriva avec Zourite, une application de réseautage professionnel pour N900. Zourite contient un mécanisme de rapport de bug qui envoie la pile d’erreur au site du développement du projet. Ce dernier étant hébergé par googlecode, je n’ai pas d’accès aux mécansime de hook subversion. Je dois donc me contenter de la substitution de révision qui ne fournit pour un fichier que la plus récente révision où ce fichier a été modifié. Or la pile d’éxecution fait appel à plusieurs fichiers donc afin que le développeur reproduise le bug, il me faut absolument la révision gloable des sources qui ont produit le bug.

Subversion fournit un outil svnversion mais celui-ci doit être executé sur un copie local des sources donc il n’est pas utilisable avec l’application livrée. De plus n’ayant pas accès au serveur subversion de googlecode, il m’est impossible d’envisager utiliser un hook pour automatiser le renseignement de la révision globale du projet.

Mais heureusement python contrairement à Java utilise la notion d’import dans son sens originel c’est-a-dire monter en mémoire un module et non pas comme un simple raccourci de notation comme en Java. Donc on peut se servir des instruction d’import des module python pour que l’application parcours tous les modules la composant. Si chaque module va proposer sa révision à un module centralisant les révisions, on est capable de connaitre la révision globale du projet… à l’éxécution.

La mise en place du mécanisme de substitution est assez aisé. Pour un ajout automatique à un nouveau fichier, suivre les instructions ici pour lesquels nous retiendrons les étapes suivantes:

1. ouvrir le fichier ~/.subversion/conf
2. dans la section [miscellany] décommenter la ligne enable-auto-props = yes
3. dans la section [auto-props] ajouter la ligne *.py = svn:eol-style=native;svn:keywords=Revision

Malheureusement les fichiers qui sont déjà sous subversion ne seront pas affectés. Il faut donc un a un leur rajouter la propriété de substitution. Dans ESBox il faut selectionner le fichier et dans le menu contextuel ouvrir le menu Team > Set property:

Puis selectionner pour property name la propriété svn:keywords et pour property content la valeur Revision

Répéter l’opération pour tous les fichiers où subversion doit appliquer la substituoin par mot clé.

Maintenant nos pouvons ajouter le mot clé $Revision$ dans les sources python. Cette valeur sera reprise par chaque module et soumis à un module centrale qui portera la révision globale.

Voic le code source du module centrale qui lui même renseigne sa révision à lui-même !

# -*- encoding: UTF-8 -*-
'''
Created on 28 mars 2010

@author: thierry
'''

CURRENT_VERSION = "1.0-SNAPSHOT"  # this must be modified before any release

def getInstance():
 return SINGLETON

class Version(object):
 '''
 Hold the revision of the application.
 '''        

 def __init__(self):
 '''
 Constructor
 '''
 self.revision = ""

 def submitRevision(self, rev):
 '''
 submit a new revision. If the revision is upper than
 the current revision, it become the new current revision
 '''

 if self.revision < rev:
 self.revision = rev

 def getRevision(self):
 '''
 Return the scm revision for this application
 '''
 return self.revision

 def getVersion(self):
 '''
 Return the marketing version for this application.
 '''
 return CURRENT_VERSION

SINGLETON = Version()  # object that track the revision of current applcation for issue tracking purpose

getInstance().submitRevision("$Revision: 73 $")

Chaque module doit alors à l’instar du module version lui-même, renseigner sa révision. Ainsi chaque module devra contenir en dernière instruction d’import le code suivant:

import version
version.getInstance().submitRevision("$Revision: 74 $")

Quand on aura besoin de connaitre la révision globale de l’application pour soumettre un bug par exemple, il suffit de faire :

versionInstance = version.getInstance()
versionStr = versionInstance.getVersion()
revisionStr = versionInstance.getRevision()