Par défaut, le dépôt Subversion exécute les procédures automatiques avec un environnement vide — c'est-à-dire sans aucune variable d'environnement définie, même pas $PATH (ou %PATH% sous Windows). C'est ainsi que de nombreux administrateurs sont perplexes lorsque leurs programmes fonctionnent correctement à la main mais pas dans Subversion. Assurez-vous de définir explicitement toutes les variables d'environnement nécessaires dans votre procédure automatique.

Subversion 1.8 introduit une nouvelle façon de gérer l'environnement dans lequel s'exécutent les procédures automatiques, le fichier de configuration de l'environnement des procédures automatiques. Si le serveur Subversion trouve un fichier nommé hooks-env dans le sous-répertoire conf/ du dépôt, il analyse ce fichier à la manière d'un fichier .INI et insère les options et variables qu'il a trouvées dans l'environnement de la procédure automatique via des variables d'environnement.

La syntaxe du fichier hooks-env est très simple : chaque nom de section correspond à la procédure automatique à laquelle la section s'applique (tels que [pre-commit] ou [post-revprop-change]) et les éléments à l'intérieur des sections sont les variables d'environnement dont on souhaite définir les valeurs. En plus, il existe une section générale [default], qui permet de définir la valeur de variables d'environnement pour toutes les procédures automatiques (sauf si cette variable est explicitement redéfinie à l'intérieur d'une section particulière à une procédure automatique). Exemple 5.1, « hooks-env (configuration personnalisée de l'environnement des procédures automatiques) » fournit un exemple de fichier de configuration hooks-env.

# Toutes les procédures seront configurées en français encodé en UTF-8
# et auront le répertoire contenant nos utilitaires dans leur chemin
# par défaut.

[default]
LANG = fr_FR.UTF-8
PATH = /usr/local/svn/tools:/usr/bin


# Les procédures post-commit et post-revprop-change ont aussi besoin
# de nos programmes personnalisés pour la synchronisation

[post-commit]
PATH = /usr/local/synctools-1.1/bin:%(PATH)s

[post-revprop-change]
PATH = /usr/local/synctools-1.1/bin:%(PATH)s

Note

Exemple 5.1, « hooks-env (configuration personnalisée de l'environnement des procédures automatiques) » montre aussi la fonctionnalité de substitution des chaînes de caractères de l'analyseur du fichier de configuration. Dans cet exemple, la valeur de l'option PATH (récupérée depuis la section [default] du fichier) remplacera à la volée le texte %(PATH)s dans les sections dédiées à chaque procédure automatique. Pour plus d'informations sur le fonctionnement de cette syntaxe, reportez-vous au fichier README.txt qui se trouve dans le répertoire de configuration de Subversion (et pour plus d'information sur ce répertoire, lisez la section intitulée « Zone de configuration des exécutables »).

Bien sûr, avoir exactement les mêmes informations dans chaque fichier de configuration de l'environnement des procédures automatiques, dans chaque répertoire conf/ de chaque dépôt serait vite très lourd, surtout quand vous devez les modifier tous. C'est pourquoi le serveur Subversion vous permet de spécifier un emplacement alternatif (possiblement partagé) pour ces informations de configuration.

Les procédures automatiques du dépôt permettent de réaliser une large palette de fonctions, mais la plupart sont en fait utilisées pour quelques actions simples : la notification, la validation et la réplication.

Les procédures de notification sont celles qui indiquent à quelqu'un que quelque chose est arrivé. Celles que l'on retrouve le plus souvent dans l'utilisation de Subversion envoient des courriels de compte-rendu de propagation (resp. de modification de propriété de révision) aux membres du projet, elles sont pilotées par la procédure automatique post-commit (resp. post-revprop-change). Il existe beaucoup d'autres types de notification, depuis l'intégration dans un outil de suivi de bogues jusqu'au robot IRC qui annonce que quelque chose a changé dans le dépôt.

Pour ce qui concerne la validation, les procédures automatiques start-commit et pre-commit sont largement utilisées pour autoriser ou interdire des propagations en fonction de divers critères : l'auteur de la propagation, le format ou le contenu du commentaire de propagation voire même des détails de bas-niveau relatifs aux modifications faites aux fichiers et dossiers par la propagation. De la même manière, la procédure automatique pre-revprop-change agit comme un point de passage obligé pour les modifications des propriétés de révisions, ce qui est particulièrement utile compte tenu du fait que les propriétés de révisions ne sont pas suivies en versions et ne sont donc modifiées qu'en détruisant l'ancienne valeur.

Une catégorie de validation des modifications se généralise depuis la sortie de Subversion 1.5 : la validation du logiciel client lui-même. Quand la fonctionnalité de suivi des fusions (qui est décrite en détails dans Chapitre 4, Gestion des branches) est apparue dans Subversion 1.5, les administrateurs de Subversion ont eu besoin de s'assurer que, une fois que certains commençaient à utiliser cette fonctionnalité, alors tous leurs fusions devaient être suivies. Afin de réduire la chance que quelqu'un propage une fusion non suivie vers le dépôt, ils ont utilisé la procédure automatique start-commit pour examiner les capacités annoncées par le client Subversion. Si celui-ci n'indiquait pas savoir suivre les fusions, la propagation était interdite avec un message pour l'utilisateur lui indiquant de mettre à niveau le client Subversion ! Exemple 5.2, « procédure automatique start-commit qui s'assure que le client sait suivre les fusions. » donne un exemple de script start-commit qui implémente précisément cette fonction.

#!/usr/bin/env python
import sys

# sys.argv[3] contient la liste, séparée par des ':', des capacités du client
if 'mergeinfo' not in sys.argv[3].split(':'):
  sys.stderr.write("""\
ERREUR : les propagations (commit) vers ce dépôt ne sont possible
qu'avec des clients qui savent suivre les fusions. Veuillez mettre à
niveau votre client à Subversion 1.5 ou ultérieur.
""")
  sys.exit(1)

Depuis Subversion 1.8, les clients qui propagent des modifications sur un serveur Subversion 1.8 fournissent toujours une chaîne indiquant leurs capacités mais fournissent aussi des informations complémentaires les concernant en utilisant des propriétés éphémères de transaction. Ces propriétés éphémères de transaction sont principalement des propriétés de révision qui sont définies sur la transaction de propagation par le client dès qu'il a l'occasion de le faire au moment de la propagation. Elle sont automatiquement supprimées par le serveur juste avant que la transaction ne devienne une révision. Vous pouvez inspecter ces propriétés, pendant le laps de temps séparant les procédures automatiques start-commit et pre-commit, à l'aide des mêmes outils que ceux que vous utilisez pour inspecter les autres propriétés non suivies en versions.

Vous trouverez ci-après les propriétés éphémères de transactions que Subversion reconnait actuellement :

Note

alors que la plupart des clients vont transmettre les propriétés éphémères de transaction assez tôt dans le processus de transaction et pouvoir ainsi être examinées par la procédure automatique start-commit, certaines configurations de Subversion vont entrainer que ces propriétés ne seront définies dans la transaction que plus tard dans le processus de propagation. Les administrateurs doivent donc prendre le parti d'effectuer les validations basées sur les propriétés éphémères à la fois dans les procédures automatiques start-commit et pre-commit (dans le premier cas pour éviter qu'un client invalide ne transmette le contenu de la propagation, dans le deuxième cas « juste au cas où » les vérifications n'auraient pas pu être effectuées par la procédure automatique start-commit).

Comme nous l'avons déjà noté, les propriétés éphémères de transaction sont supprimées de la transaction juste avant qu'elle ne soit promue en nouvelle révision. Certains administrateurs peuvent vouloir conserver les informations de ces propriétés pour plus tard. Nous vous conseillons alors d'utiliser la procédure automatique pre-commit pour copier les valeurs des propriétés vers de nouvelles propriétés avec un nom différent. En fait, le code source distribué avec Subversion fournit un script persist-ephemeral-txnprops.py (situé dans le dossier tools/hook-scripts/), qui fait exactement cela.

La troisième catégorie que l'on rencontre souvent dans l'utilisation des procédures automatiques concerne la réplication. Que ce soit pour simplement faire une copie de sauvegarde ou pour un scénario impliquant des dépôts mirroirs, les procédures automatiques peuvent s'avérer critiques. Lisez la section intitulée « Sauvegarde d'un dépôt » et la section intitulée « Réplication d'un dépôt » pour davantage d'informations sur ces aspects de la maintenance du dépôt.

Comme vous pouvez l'imaginer, il n'est pas concevable d'avoir un de procédures automatiques et de scripts divers qui ne soient librement accessibles que ce soit au sein de la communauté Subversion ou ailleurs. En fait, la distribution Subversion fournit plusieurs procédures automatiques utilisées un peu partout dans son répertoire tools/hook-scripts/. Cependant, si vous ne trouvez pas votre bonheur dans ce répertoire, vous pouvez écrire la vôtre. Lisez Chapitre 8, Intégration de Subversion pour obtenir des informations sur le développement d'applications utilisant l'API publique de Subversion.

Avertissement

les procédures automatiques sont capables de faire tout et n'importe quoi, mais leurs auteurs doivent faire preuve de modération. Il pourrait être tentant, disons, d'utiliser les procédures automatiques pour corriger automatiquement des erreurs, des coquilles ou des violations de la politique dans les fichiers propagés. Malheureusement, une telle action peut engendrer des problèmes. Subversion conserve en cache, côté client, certaines parties des données du dépôt et, si vous modifiez une transaction de propagation de cette façon, ces caches seront périmés sans que cela ne puisse être détecté. De telles incohérences peuvent aboutir à des comportements surprenants et inattendus. Autant il est généralement correct d'ajouter des propriétés de transaction par une procédure automatique, autant tout le reste dans une transaction de propagation doit être considéré comme en lecture seule. Au lieu de modifier une transaction pour la rendre plus policée, contentez-vous de vérifier la transaction dans la procédure automatique pre-commit et rejetez-la si elle ne remplit pas les conditions nécessaires. Entre autre avantages, vos utilisateurs prendront ainsi des habitudes de travail empreintes de respect des procédures et de qualité.