Standardmäßig führt Subversion Hook-Skripte mit einer leeren Umgebung aus – d.h., es sind überhaupt keine Umgebungsvariablen gesetzt, nicht einmal $PATH (oder %PATH% unter Windows). Deshalb sind viele Administratoren verwirrt, wenn deren Hook-Programme normal starten, wenn sie manuell aufgerufen werden, aber nicht funktionieren, wenn sie Subversion startet. Historisch haben Administratoren dem Problem damit entgegengewirkt, dass sie manuell alle Umgebungsvariablen, die ihre Hook-Skripte benötigen, im Skript selbst gesetzt haben.

Subversion 1.8 stellt eine neue Art vor, die Umgebung von Hook-Skripten zu verwalten, die von Subversion ausgeführt werden – die Konfigurationsdatei für die Hook-Skript-Umgebung. Falls Subversion eine Datei namens hooks-env im Unterverzeichnis conf/ des Projektarchivs findet, parst es diese Datei als Konfigurationsdatei im INI-Format und wendet die darin gefundenen Optionsnamen und Variablen als Umgebungsvariablen in der Ausführungs-Umgebung für das Hook-Skript an.

Die Syntax der Datei hooks-env ist ziemlich einfach: jeder Abschnittsname ist der Name eines Hook-Skriptes (etwa [pre-commit] oder [post-revprop-change]), und die Konfigurationseinträge in diesem Abschnitt werden als Abbildungen von Umgebungsvariablen auf gewünschte Werte behandelt. Darüber hinaus gibt es noch einen besonderen Abschnitt [default], der verwendet werden kann, um Abbildungen von Umgebungsvariablen zu konfigurieren, die auf alle Hook-Skripte angewendet werden sollen (es sei denn, sie sind ausdrücklich durch eigene Hook-Skript Einträge überschrieben). Siehe Beispiel 5.1, „hooks-env (maßgeschneiderte Umgebungskonfiguration für Hook-Skripte)“ für ein Beispiel einer hooks-env Konfigurationsdatei.

# Alle Skripte sollten eine UTF-8 Locale verwenden und unser Hook-Skript
# das Werkzeugverzeichnis im Suchpfad haben.

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


# Auch die post-commit und post-revprop-change Skripte möchten
# Programme aus unserer maßgeschneiderten Synctools-Replikations-Software
# Sammlung verwenden.

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

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

Anmerkung

Beispiel 5.1, „hooks-env (maßgeschneiderte Umgebungskonfiguration für Hook-Skripte)“ zeigt auch die elegante Syntax zur Ersetzung von Zeichenketten aus Subversions Konfigurationsdateien-Parser. In diesem Beispiel wird der Wert der Option PATH – aus dem Abschnitt [default] der Datei gelesen – anstelle des Platzhalters %(PATH)s in den Hook-Abschnitten eingefügt. Mehr zu dieser besonderen Syntax finden Sie in der Datei README.txt in Subversions Verzeichnis für die Laufzeitkonfiguration. (Und für weitere Informationen zu diesem Verzeichnis, siehe „Laufzeit-Konfigurations-Bereich“.)

Natürlich kann es lästig werden, exakte Duplikate Ihrer Hook-Skript-Umgebungs-Konfigurations-Dateien in jedem conf/ Verzeichnis jedes einzelnen Projektarchivs vorzuhalten, insbesondere, falls Sie Änderungen an allen machen müssen. Deshalb erlauben Ihnen die Server von Subversion, einen alternativen (möglicherweise gemeinsam benutzten) Speicherort für diese Konfiguration anzugeben.

Projektarchiv-Hook-Skripte können einen breiten Nutzen bieten, doch die meisten decken ein paar grundsätzliche Kategorien ab: Benachrichtigung, Validierung und Replizierung.

Benachrichtigungs-Skripte sind diejenigen, die jemanden mitteilen, dass etwas passiert ist. Die häufigsten hiervon, die in einem Subversion-Dienst angetroffen werden können, umfassen Programme, die E-Mails mit Benachrichtigungen zu Übertragungen und Änderungen an Revisions-Eigenschaften an Projektmitarbeiter versenden, und die von den post-commit bzw. post-revprop-change Hooks ausgelöst werden. Es gibt zahlreiche andere Ansätze zu Benachrichtigungen, von Integrationsskripten für Fehlerverfolgungs-Systeme bis zu Skripten, die als IRC-Bots arbeiten, um zu verkünden, dass sich etwas im Projektarchiv geändert hat.

Bei der Validierung ist die Verwendung der Hooks start-commit und pre-commit weit verbreitet, um Übertragungen abhängig von verschiedenen Kriterien zu erlauben oder zu verbieten: der Autor der Übertragung, die Formatierung und/oder der Inhalt der Protokollnachricht, die die Übertragung beschreibt, und sogar die Feinheiten der an Dateien und Verzeichnissen vorgenommenen Änderungen in der Übertragung. Ähnlich handelt der Hook pre-revprop-change als Portal zu Änderungen an Revisions-Eigenschaften, was eine besonders nützliche Rolle ist, angesichts der Tatsache, dass Revisions-Eigenschaften an sich nicht versioniert sind und deshalb nur destruktiv bearbeitet werden können.

Eine besondere Klasse von Änderungsvalidierung, die seit der Veröffentlichung Subversion 1.5 weit verbreitet ist, stellt die Validierung des übertragenden Clients an sich dar. Als die Merge-Tracking-Funktionalität von Subversion (ausführlich beschrieben in Kapitel 4, Verzweigen und Zusammenführen) mit dieser Veröffentlichung eingeführt wurde, benötigten Subversion-Administratoren eine Möglichkeit, sicherzustellen, dass, alle Merges von Anwendern ihrer Projektarchive, die die neue Funktionalität verwendeten, verfolgt werden. Um die Wahrscheinlichkeit eines nicht verfolgten Merges zu verringern, verwendeten sie start-commit-Hooks, um die von Subversion-Clients bekanntgegebenen funktionalen Fähigkeiten zu untersuchen. Falls der übertragende Client nicht die Fähigkeit zur Unterstützung von Merge-Tracking meldete, wurde die Übertragung abgelehnt und eine Anleitung zum aktualisieren des Clients an den Anwender gesendet. Beispiel 5.2, „start-commit Hook, um Merge-Tracking Unterstützung zu erzwingen“ stellt ein Beispiel eines start-commit-Skripts bereit, was genau das macht.

#!/usr/bin/env python
import sys

# sys.argv[3] is a colon-delimited capabilities list
if 'mergeinfo' not in sys.argv[3].split(':'):
  sys.stderr.write("""\
ERROR: Commits to this repository must be made using Subversion
clients which support the merge tracking feature.  Please upgrade
your client to at least Subversion 1.5.0.
""")
  sys.exit(1)

Beginnend mit Subversion 1.8, stellen Clients, die an einen Subversion 1.8 Server übertragen immer noch die Zeichenkette mit ihren funktionalen Fähigkeiten zur Verfügung, geben darüber hinaus gehend jedoch zusätzliche Informationen über sich preis durch flüchtige Transaktions-Eigenschaften. Flüchtige Transaktions-Eigenschaften sind im Grunde genommen Revisions-Eigenschaften, die vom Client während der Übertragungs-Transaktion bei der frühesten Gelegenheit gesetzt werden, die dann aber vom Server wieder entfernt werden, unmittelbar, bevor die Transaktion eine abgeschlossene Revision wird. Sie können diese Eigenschaften mit denselben Werkzeugen untersuchen, mit denen Sie andere bei Übertragungs-Transaktionen im Zeitraum zwischen dem Aufruf der start-commit und pre-commit Hooks gesetzte unversionierte Eigenschaften untersuchen würden.

Die folgenden sind die flüchtigen Transaktions-Eigenschaften, die Subversion momentan unterstützt und implementiert:

Anmerkung

Obwohl die meisten Clients die flüchtigen Transaktions-Eigenschaften früh genug im Übertragungsprozess schicken, so dass das start-commit Hook-Skript sie untersuchen kann, kann es vorkommen, dass es bei einigen Konfigurationen von Subversion dazu kommen, dass diese Eigenschaften erst später im Übertragungsprozess gesetzt werden. Deshalb sollten Administratoren erwägen, Validierungen, die auf flüchtigen Transaktions-Eigenschaften beruhen, sowohl im start-commit als auch im pre-commit Hook vorzunehmen – ersteres, um ungültige Clients auszuschließen, bevor sie die Daten der Übertragung senden, letzteres, „für alle Fälle“, falls die Validierung durch den start-commit Hook nicht möglich war.

Wie bereits angemerkt, werden flüchtige Transaktions-Eigenschaften aus der Transaktion entfernt, kurz bevor sie zu einer neuen Revision hochgestuft wird. Einige Administratoren möchten diese Informationen vielleicht auf unbestimmte Zeit bewahren. Wir schlagen vor, hierfür das pre-commit Hook-Skript die Werte dieser Eigenschaften in neue Eigenschaftsnamen kopieren zu lassen. In der Tat stellt die Quelltext-Distribution von Subversion ein Skript persist-ephemeral-txnprops.py (im Verzeichnis tools/hook-scripts/), das genau dies macht.

Der dritte verbreitete Anwendungsfall für Hook-Skripte ist zum Zweck der Replizierung. Ob Sie einen einfachen Backup-Prozess betreiben oder ein ausgeprägteres Spiegelungs-Szenario in ein entferntes Projektarchiv – Hook-Skripte können entscheidend sein. Siehe „Sicherung des Projektarchivs“ und „Projektarchiv Replikation“ für weitere Informationen zu diesen Aspekten der Projektarchiv-Pflege.

Wie Sie sich denken können, gibt es keinen Mangel an Subversion-Hook-Programmen und Skripten, die frei verfügbar sind, entweder von der Subversion-Gemeinschaft oder von woanders her. Tatsächlich liefert die Subversion-Distribution einige oft genutzte Hook-Skripte im Unterverzeichnis tools/hook-scripts/ mit. Sollten Sie jedoch keins finden können, dass Ihre besonderen Anforderungen erfüllt, sollten Sie erwägen, Ihr eigenes zu schreiben. Siehe Kapitel 8, Subversion integrieren zu Informationen über Softwareentwicklung unter Verwendung von Subversions öffentlichen APIs.

Warnung

Hook-Skripte können fast alles machen, doch sollten sich Hook-Skript-Autoren zurückhalten. Es mag verlockend erscheinen, Hook-Skripte, sagen wir mal, zur automatischen Korrektur von Fehlern, Unzulänglichkeiten oder Prozessverletzungen innerhalb der zu übertragenden Dateien einzusetzen. Unglücklicherweise kann das jedoch zu Problemen führen. Subversion hält bestimmte Projektarchiv-Daten in client-seitigen Caches vor, und wenn Sie auf diese Art eine Übergabe-Transaktion verändern, werden die im Cache befindlichen Informationen ungültig, ohne dass jemand etwas merkt, was zu überraschendem und unerwartetem Verhalten führt. Während es im Allgemeinen in Ordnung geht, einer Commit-Transaktion neue Eigenschaften über ein Hook-Skript hinzuzufügen, sollte im Wesentlichen alles andere an einer Commit-Transaktion als nur-lesbar betrachtet werden. Statt die Transaktion durch Manipulation der Daten zu verändern, sollten Sie sie einfach im pre-commit-Hook auf Gültigkeit prüfen und die Übergabe ablehnen, falls sie den Anforderungen nicht entspricht. Als Nebeneffekt werden Ihre Anwender lernen, wie wertvoll eine sorgfältige, sich an den Vorgaben orientierende Arbeitsweise ist.