Dans ma vie de tous les jours d'informaticien aventureux, j'utilise tout plein d'outils divers et variés afin de mieux m'amus... travailler ;-)

Parmi ces outils, j'en ai mis en place au boulot. Les heureux élus sont :


Le contexte!!

Au départ, les deux travaillaient de concert pour un seul projet. Cependant, chemin faisant[1], plusieurs projets ont demandé leur mise en gestion sous Subversion.

Les sus-cités projets avançant, il leur fallu bientôt se résoudre au fait, que nul n'étant parfait, ils avaient des bugs. J'ai donc proposé l'hébergement de leurs rapports de bug sous Trac.

Petit problème, les projets ne doivent pas partager leurs bugs donc plusieurs instances de Trac étaient nécessaires. Je me dit qu'un peu de Google m'aidera et effectivement je tombe là-dessus.

Très bien sauf que ça ne correspond pas à mon cas. En effet, les gestions de bugs sont séparées mais les sources sont stockées sur un même repository Subversion.

Je me trouve donc dans le cas décrit ici, à savoir plusieurs environnements, plusieurs projets et un seul Subversion.

Tout a l'air d'aller donc puisque la création d'environnement Trac, je maitrise. Reste à relier correctement le sous-arbre du repository correspondant au projet avec l'environnement Trac qui va bien.

Encore une fois, il y a de la doc. Trop facile !!


Les ennuis commencent!!

Jusque-là, tout va bien. Mon Trac est relié au Subversion par le script classique de hook présenté ici. Le hook en lui-même est directement issu des commentaires du script Python.

Ce qui donne quelque chose comme ça :


REPOS="$1"

REV="$2"

TRAC_ENV="/data/trac_project1"



$TRAC_ENVtrac-post-commit-hook -p "$TRAC_ENV" -r "$REV"

Tout va bien... Ou presque !

Un développeur m'annonce gentiment que lorsqu'il commit une correction, l'état du bug n'est pas changé automatiquement. Après réflexion et relecture du hook, j'aperçois :


TRAC_ENV="/data/trac_project1"

Ce qui veut dire que tous les commit sont renvoyés vers l'environnement du projet 1 et non pas ventilés entre projets !!!!

La confirmation de mes craintes survient quant je vérifie l'état du bug #15 du projet 1 qui a reçu le message de commit et la résolution d'un révision du projet 2.


La solution!!

Bon, comme je suis très fort, j'ai quand même trouvé une solution[2].

Donc, la solution que j'ai adoptée est la suivante.

Sachant que Subversion n'a aucune connaissance de Trac lors des hooks de post-commit, il faut trouver un moyen de passer le bon environnement.

Mon repository Subversion est organisé comme suit :


SVNRepos/

|-- project1

|   |-- branches

|   |-- tags

|   `-- trunk

`-- project2

    |-- branches

    |-- tags

    `-- trunk

J'ai donc utilisé le système des propriétés utilisé par Subversion pour la propriété svn:ignore. Ainsi, j'ai appliqué à la racine de chaque projet une propriété à moi, trac_path contenant le chemin de l'environnement Trac via, par exemple :


fred@titi:> cd ~/wc/project1

fred@titi:> svn propset trac_path ~/wc/trac_project1

fred@titi:> svn ci


Bon, il faut bien sûr avoir une copie de travail, même minimaliste de l'arborescence du projet

bien sûr, cela ne suffit pas et le script de hook doit être modifié en conséquence. Le voici donc :


#!/bin/sh



# POST-COMMIT HOOK

#<snipped>

#



REPOS="$1"

REV="$2"

TRAC_ENV='/data/trac'



SVNLOOK='/usr/local/bin/svnlook'

echo $SVNLOOK

#Find the project that is concerned

PROJECT=`$SVNLOOK dirs-changed -r $REV $REPOS | cut -d/ -f1 | uniq | head -n 1`



#Find the trac path associated with the project by getting the property

TRAC_ENV=`$SVNLOOK pg $REPOS trac_path $PROJECT`



if [ $TRAC_ENV ]; then

#Launch the update if nothing failed

$TRAC_ENV/trac-post-commit-hook -p $TRAC_ENV -r $REV

fi

Bon, normalement tout est dans les commentaires mais bon, je vais quand même me fendre de quelques explications.

Le premier svnlook a pour but de trouver le nom du projet. Simple et rapide, on prend juste le nom des répertoires qui ont changé et on en tire le premier élément du chemin qui devrait normalement être le projet au vu de mon arborescence.

Le second permet d'extraire la valeur de la propriété trac_path et si elle existe d'appliquer le script fourni par Trac se trouvant dans l'environnement du projet[3].


Conclusion!!

Après quelques sueurs froides, j'ai donc pu trouver une solution pas trop mal mais je suis ouvert à tout commentaire. Donc si vous trouvez mieux, je suis preneur... Bien que ma solution fonctionne bien.

Notes

[1] Et le prix aidant :D

[2] Et un moyen de modifier les vieux tickets modifiés par erreur mais ce sera pour un autre billet sur Trac seulement

[3] Des fois que ce serait pas le même pour tout le monde