Et comment qu'on fait ?
Par Fred le mercredi 2 juin 2010, 22:01 - Développement - Lien permanent
Quand on a un seul Subversion et plusieurs environnements Trac ?
Pour comprendre ce qui suit, mieux vaut maitriser un tant soit peu Subversion et Trac. M'enfin, je dis ça, je dis rien.
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.