Dieser Text befindet sich gegenwärtig in Bearbeitung, unterliegt ständigen Änderungen und kann dadurch nicht stets akkurat irgendeine freigegebene Version der Software Apache™ Subversion® beschreiben. Das Speichern dieser Seite als Lesezeichen oder andere auf diese Seite zu verweisen, ist keine so gute Idee. Besuchen Sie http://www.svnbook.com/, um stabile Versionen dieses Buchs zu erhalten.

Anlegen und konfigurieren Ihres Projektarchivs

Weiter oben in diesem Kapitel (in „Strategien für die Verwendung eines Projektarchivs“), schauten wir auf einige der wichtigen Entscheidungen, die zu treffen sind, bevor Ihr Subversion-Projektarchiv angelegt und konfiguriert wird. Jetzt schaffen wir es endlich, uns die Hände schmutzig zu machen! In diesem Abschnitt werden wir sehen, wie ein Subversion-Projektarchiv überhaupt angelegt wird und wie es konfiguriert wird, damit es bei bestimmten Projektarchiv-Ereignissen spezielle Aktionen ausführt.

Anlegen des Projektarchivs

Das Anlegen eines Subversion-Projektarchivs ist eine unglaublich einfache Aufgabe. Das mit Subversion gelieferte Dienstprogramm svnadmin stellt ein Unterbefehl (svnadmin create) zur Verfügung, der genau das macht.

$ # Ein Projektarchiv anlegen
$ svnadmin create /var/svn/repos
$

Vorausgesetzt, dass das Verzeichnis /var/svn/repos vorhanden ist, Sie die zum Ändern erforderlichen Rechte besitzen, legt der obige Befehl ein neues Projektarchiv mit dem Standard-Dateisystem-Speicherverfahren (FSFS) an. Sie können den Dateisystemtypen ausdrücklich wählen, indem Sie das Argument --fs-type benutzen, das als Parameter entweder fsfs oder bdb zulässt.

$ # Ein FSFS-basiertes Projektarchiv anlegen
$ svnadmin create --fs-type fsfs /var/svn/repos
$
# Ein Berkeley-DB-basiertes Projektarchiv anlegen
$ svnadmin create --fs-type bdb /var/svn/repos
$

Nach dem Ausführen dieses einfachen Befehls haben Sie ein Subversion-Projektarchiv. Abhängig davon, wie Anwender künftig auf dieses neue Projektarchiv zugreifen sollen, müssten Sie gegebenenfalls an den Dateisystem-Berechtigungen feilen. Da allerdings die grundsätzliche Systemverwaltung nicht Gegenstand dieses Textes ist, betrachten wir die weitere Untersuchung dieses Themas als Übung für den Leser.

[Tipp] Tipp

Das Pfad-Argument zu svnadmin ist bloß ein gewöhnlicher Pfad im Dateisystem und kein URL wie ihn das Client-Programm svn verwendet, um auf Projektarchive zu verweisen. Sowohl svnadmin als auch svnlook werden als serverseitige Dienstprogramme betrachtet – sie werden auf dem Rechner benutzt, auf dem das Projektarchiv untergebracht ist, um Aspekte des Projektarchivs zu untersuchen oder zu verändern; tatsächlich sind sie nicht in der Lage, Aufgaben über das Netz zu erledigen. Ein verbreiteter Fehler von Subversion-Neulingen ist der Versuch, URLs (sogar lokale vom Typ file://) an diese zwei Programme zu übergeben.

Im Unterverzeichnis db/ Ihres Projektarchivs befindet sich die Implementierung des versionierten Dateisystems. Das Leben des versionierten Dateisystems Ihres Projektarchivs beginnt mit Revision 0, die aus nichts anderem als dem Wurzelverzeichnis (/) besteht. Zu Beginn hat die Revision 0 eine einzige Revisions-Eigenschaft, svn:date, das als Wert die Angabe des Zeitpunktes besitzt, zu dem das Projektarchiv angelegt wurde.

Da Sie nun ein Projektarchiv haben, ist es an der Zeit, es anzupassen.

[Warnung] Warnung

Während einige Teile des Projektarchivs – wie die Konfigurationsdateien und Hook-Skripte – für eine manuelle Untersuchung und Bearbeitung gedacht sind, sollten Sie nicht (und sie sollten es auch nicht nötig haben) an den anderen Teilen des Projektarchivs händisch herumdoktern. Das Dienstprogramm svnadmin sollte für alle notwendigen Änderungen an Ihrem Projektarchiv ausreichen; sie können auch Dienstprogramme von Drittanbietern verwenden, um in entsprechenden Unterabschnitten des Projektarchivs Änderungen vorzunehmen. Versuchen Sie nicht, die Historie Ihrer Versionskontrolle manuell zu verändern, indem Sie in den Speicherdateien des Projektarchivs herumstochern!

Erstellen von Projektarchiv-Hooks

Ein Hook (Haken) ist ein Programm, das durch einige Projektarchiv-Ereignisse gestartet wird, wie etwa die Erzeugung einer neuen Revision oder die Veränderung einer unversionierten Eigenschaft. Einige Hooks (die sogenannten Pre-Hooks) starten vor einer Projektarchiv-Operation und bieten eine Möglichkeit sowohl zu berichten, was passieren wird, als auch zu verhindern, dass es überhaupt passiert. Andere Hooks (die Post-Hooks) starten nach Abschluss eines Projektarchiv-Ereignisses und sind nützlich für Aufgaben, die das Projektarchiv inspizieren – aber nicht verändern. Jedem Hook wird ausreichend Information übergeben, damit er feststellen kann, um welches Ereignis es sich handelt (oder handelte), welche genauen Änderungen am Projektarchiv beabsichtigt sind (oder durchgeführt wurden) und wie der Name des Anwenders lautet, der das Ereignis ausgelöst hat.

Das Unterverzeichnis hooks beinhaltet standardmäßig Vorlagen für verschiedene Projektarchiv-Hooks:

$ ls repos/hooks/
post-commit.tmpl          post-unlock.tmpl  pre-revprop-change.tmpl
post-lock.tmpl            pre-commit.tmpl   pre-unlock.tmpl
post-revprop-change.tmpl  pre-lock.tmpl     start-commit.tmpl
$

Es gibt eine Vorlage für jeden Hook, den Subversion unterstützt. Sie können sehen, wodurch jedes dieser Skripte gestartet wird und welche Daten übergeben werden, indem Sie den Inhalt der Skripte inspizieren. In vielen dieser Vorlagen befinden sich auch Beispiele dafür, wie dieses Skript zusammen mit anderen Programmen aus dem Lieferumfang von Subversion verwendet werden kann, um häufige, nützliche Aufgaben zu erledigen. Um einen funktionierenden Hook zu installieren, brauchen Sie nur ein ausführbares Programm oder Skripte im Verzeichnis repos/hooks abzulegen, das unter dem Namen des Hooks (etwa start-commit oder post-commit) gestartet werden kann.

Auf Unix Plattformen bedeutet das, ein Skript oder Programm bereitzustellen (welches ein Shell-Skript, ein Python-Programm, ein übersetztes C-Binärprogramm oder sonst etwas sein kann), das genauso heißt wie der Hook. Natürlich sind die Vorlagen nicht nur zur Information da – die einfachste Möglichkeit, unter Unix einen Hook zu installieren, ist es, einfach die passende Vorlagedatei in eine Datei zu kopieren, der die Dateiendung .tmpl fehlt, den Inhalt anzupassen und sicherzustellen, dass das Skript ausführbar ist. Unter Windows werden jedoch Dateiendungen verwendet, um festzustellen, ob ein Programm ausführbar ist, so dass Sie ein Programm zur Verfügung stellen müssen, dessen Basisname dem Hook entspricht und dessen Endung einer derjenigen entspricht, die Windows für ausführbare Programme hält, etwa .exe für Programme und .bat für Batch-Dateien.

Subversion führt die Hooks unter der Anwenderkennung aus, die auch der Prozess besitzt, der auf das Projektarchiv zugreift. Meistens wird auf das Projektarchiv über einen Subversion-Server zugegriffen, so dass die Anwenderkennung der des Serverprozesses entspricht. Die Hooks müssen deshalb mit den entsprechenden Berechtigungen des Betriebssystems versehen werden, damit diese Anwenderkennung sie ausführen kann. Das bedeutet auch, dass der direkte oder indirekte Zugriff auf irgendwelche Programme oder Dateien (einschließlich des Subversion-Projektarchivs) durch den Hook auch unter derselben Kennung erfolgt. Mit anderen Worten: Achten Sie auf mögliche Probleme im Zusammenhang mit Zugriffsrechten, die den Hook daran hindern könnten, die Ihm zugeteilten Aufgaben wahrzunehmen.

Es gibt mehrere im Subversion-Projektarchiv implementierte Hooks; Details zu jedem können Sie in Subversion Projektarchiv-Hook-Referenz nachlesen. Als Projektarchiv-Administrator müssen Sie entscheiden, welche Hooks sie einrichten wollen (indem Sie ein entsprechend benanntes und mit den nötigen Zugriffsrechten versehenes Hook-Programm bereitstellen) und wie Sie sie einsetzen wollen. Wenn Sie diese Entscheidung treffen, dann behalten Sie das Gesamtbild des Projektarchiv-Einsatzes im Auge. Wenn Sie beispielsweise die Konfiguration des Servers verwenden, um festzustellen, welche Anwender Änderungen an Ihr Projektarchiv übertragen dürfen, benötigen Sie für diese Zugriffskontrolle nicht das Hook-System.

Konfiguration der Umgebung von Hook-Skripten

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.

Beispiel 5.1. hooks-env (maßgeschneiderte Umgebungskonfiguration für Hook-Skripte)

# 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 diee 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] 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.

Häufige Anwendungen für Hook-Skripte

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.

Beispiel 5.2. start-commit Hook, um Merge-Tracking Unterstützung zu erzwingen

#!/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:

svn:txn-client-compat-version

Beinhaltet die Zeichenkette mit der Version der Subversion-Bibliothek zu der der Client angibt, kompatibel zu sein. Das ist nützlich, um zu entscheiden, ob der Client die zur richtigen Behandlung der Projektarchiv-Daten notwendige minimale Funktionalität unterstützt.

svn:txn-user-agent

Beinhaltet die Zeichenkette user agent, die das übertragende Client-Programm beschreibt. Die Bibliotheken von Subversion definieren der ersten Teil dieser Zeichenkette, doch können Dritte, die dieses API verwenden (GUI-Clients, usw.) eigene Informationen anhängen.

[Anmerkung] 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.

Finding hook scripts or rolling your own

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] 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.

FSFS Konfiguration

Seit Subversion 1.6 besitzen FSFS Dateisysteme mehrere konfigurierbare Parameter, die ein Administrator zur Feinabstimmung der Leistungsfähigkeit oder der Plattennutzung seines Projektarchivs verwenden kann. Sie können diese Optionen und deren Dokumentation in der Datei db/fsfs.conf im Projektarchiv finden.