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.
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 $
Damit wird ein neues Projektarchiv im Verzeichnis
/var/svn/repos
mit dem
Standard-Speicherverfahren angelegt. Vor Subversion 1.2 war es
Berkeley DB, nun ist es FSFS. 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.
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 |
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 | |
---|---|
Während einige Teile des Projektarchivs – wie die Konfigurationsdateien und Hook-Scripts – 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 (wie das Werkzeugpaket von Berkeley DB) 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! |
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 Benutzers lautet, der das Ereignis ausgelöst hat.
Das Verzeichnis für die Hooks
ist
standardmäßig mit Vorlagen für verschiedene Projektarchiv-Hooks
gefüllt:
$ 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 Scripte
gestartet wird und welche Daten übergeben werden, indem Sie
den Inhalt der Scripte inspizieren. In vielen dieser Vorlagen
befinden sich auch Beispiele dafür, wie dieses Script 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 Script 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 Script oder
Programm bereitzustellen (welches ein Shell-Script, ein
Python-Programm, ein übersetztes C-Binärprogramm oder
sonstetwas 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 Script 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.
Tipp | |
---|---|
Aus Sicherheitsgründen führt Subversion Hook-Programme
in einer leeren Umgebung aus – d.h., es sind überhaupt
keine Umgebungsvariablen gesetzt, nicht einmal
|
Subversion führt die Hooks unter der Benutzerkennung aus, die auch der Prozess besitzt, der auf das Projektarchiv zugreift. Meistens wird auf das Projektarchiv über einen Subversion-Server zugegriffen, so dass die Benutzerkennung der des Serverprozesses entspricht. Die Hooks müssen deshalb mit den entsprechenden Berechtigungen des Betriebssystems versehen werden, damit diese Benutzerkennung 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 „Projektarchiv-Hooks“ 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 Benutzer Änderungen an Ihr Projektarchiv übergeben dürfen, benötigen Sie für diese Zugriffskontrolle nicht das Hook-System.
Es gibt keinen Mangel an Subversion-Hook-Programmen und Scripten, die frei verfügbar sind, entweder von der Subversion-Gemeinschaft oder von woanders her. Diese Scripte decken ein breites Spektrum ab – grundlegende Zugriffskontrolle, Kontrolle der Prozesstreue, Fehlersystemanbindung, E-Mail-basierte oder syndizierte Benachrichtigungen bei Übergaben und noch viel mehr. Oder, falls Sie Ihren eigenen schreiben wollen, siehe Kapitel 8, Subversion integrieren.
Warnung | |
---|---|
Obwohl Hook-Scripts fast alles machen können, gibt es
eine Dimension, in der sich Hook-Script-Autoren zurückhalten
sollten: Ändern Sie keine
Übergabe-Transaktion mithilfe von Hook-Scripten. Trotz der
Verlockung, Hook-Scripte zur automatischen Korrektur von
Fehlern, Unzulänglichkeiten oder Prozessverletzungen
innerhalb der zu übergebenden Dateien einzusetzen, kann das
zu Problemen führen. Subversion hält bestimmte
Projektarchiv-Daten in clientseitigen 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. Diese Inkonsistenz kann zu
überraschendem und unerwartetem Verhalten führen. Statt die
Transaktion zu verändern, sollten Sie sie einfach im
|
Eine Berkeley-DB-Umgebung ist eine Kapselung einer oder mehrerer Datenbanken, Protokolldateien, Regionsdateien und Konfigurationsdateien. Die Berkeley-DB-Umgebung hat ihre eigene Menge an Konfigurationswerten für Dinge wie die Maximalzahl von Datenbanksperren zu einem gegebenen Zeitpunkt, die Obergrenze für die Größe der Protokolldateien usw. Darüberhinaus wählt Subversions Dateisystemlogik Standardwerte für einige der Berkeley-DB-Konfigurationsoptionen. Manchmal jedoch benötigt Ihr besonderes Projektarchiv, welches eine einzigartige Sammlung von Daten und Zugriffsmustern darstellt, eine unterschiedliche Menge von Konfigurationswerten.
Den Herstellern von Berkeley-DB ist bewusst, dass
unterschiedliche Anwendungen und Datenbankumgebungen auch
unterschiedliche Anforderungen haben, so dass sie einen
Mechanismus zur Verfügung gestellt haben, der es ermöglicht,
während der Laufzeit viele der Konfigurationseinstellungen für
die Berkeley-DB-Umgebung zu überschreiben. BDB prüft, ob es
eine Datei namens DB_CONFIG
im
Umgebungsverzeichnis (das Verzeichnis db
des Projektarchivs) gibt und liest die in dieser Datei
vorhandenen Optionen. Subversion erzeugt diese Datei selbst,
wenn der Rest eines Projektarchivs erstellt wird. Anfangs
beinhaltet diese Datei einige Standardoptionen sowie Verweise
zur Berkeley-DB-Dokumentation im Netz, so dass Sie
nachschlagen können, was diese Optionen bewirken.
Selbstverständlich können Sie beliebige von Berkeley DB
unterstützte Optionen der Datei DB_CONFIG
hinzufügen. Beachten Sie jedoch, dass Sie es vermeiden
sollten, obwohl Subversion niemals versucht, den Inhalt der
Datei zu lesen oder zu interpretieren und auch sonst keinen
direkten Gebrauch von den dortigen Optionseinstellungen macht,
die Konfiguration so zu verändern, dass sich Berkeley DB
anders verhält, als es Subversion erwartet. Die Änderungen an
DB_CONFIG
werden außerdem erst nach einer
Wiederherstellung der Datenbankumgebung (mit svnadmin
recover) gültig.