Jede der Kernbibliotheken von Subversion gehört zu einer von
drei Schichten – der Projektarchiv-Schicht, der
Projektarchiv-Zugriffs-Schicht oder der Client-Schicht (siehe Abbildung 1, „Die Architektur von Subversion“ im Vorwort). Wir
werden diese Schichten gleich untersuchen, doch zunächst wollen
wir eine kurze Zusammenfassung der verschiedenen Bibliotheken
präsentieren. Aus Konsistenzgründen beziehen wir uns auf die
Bibliotheken mit ihren Unix-Namen ohne Dateiendung
(libsvn_fs
, libsvn_wc
,
mod_dav_svn
, usw.).
Hauptschnittstelle für Client-Programme
Prozeduren zum Vergleichen von Bäumen und Byte-Strömen
Prozeduren für kontextuelle Vergleiche und Zusammenführungen
Gemeinsame Dateisystemprozeduren und Modullader
Das Berkeley-DB-Dateisystem
Das FSFS-Dateisystem
Gemeinsame Prozeduren für den Projektarchiv-Zugriff und Modullader
Modul für den lokalen Projektarchiv-Zugriff
Modul für den WebDAV-Projektarchiv-Zugriff
Ein weiteres (experimentelles) Modul für den WebDAV-Projektarchiv-Zugriff
Projektarchiv-Zugriff über das spezielle Protokoll
Projektarchiv-Schnittstelle
Verschiedene nützliche Prozeduren
Die Bibliothek zur Verwaltung der Arbeitskopie
Apache-Autorisierung-Modul für den Subversion-Zugriff über WebDAV
Apache-Modul, zur Abbildung von WebDAV-Operationen auf solche von Subversion
Die Tatsache, dass das Wort „verschiedene“ nur einmal in der obigen Liste auftaucht, ist ein gutes Zeichen. Das Entwicklerteam von Subversion nimmt es ernst damit, dass Funktionen in den richtigen Schichten und Bibliotheken untergebracht werden. Der vielleicht größte Vorteil des modularen Entwurfs liegt aus Sicht eines Entwicklers in der Abwesenheit von Komplexität. Als Entwickler können Sie sich schnell das „große Bild“ vorstellen, das es Ihnen erlaubt, bestimmte Funktionsbereiche relativ einfach zu lokalisieren.
Ein weiterer Vorteil der Modularität ist die Möglichkeit,
ein gegebenes Modul durch eine völlig neue Bibliothek zu
ersetzen, die dieselbe Programmierschnittstelle implementiert,
ohne den Rest der Code-Basis zu beeinflussen. Eigentlich
passiert das bereits mit Subversion. Die Bibliotheken
libsvn_ra_local
,
libsvn_ra_neon
,
libsvn_ra_serf
und
libsvn_ra_svn
implementieren alle die
gleiche Schnittstelle und funktionieren als Plug-In für
libsvn_ra
. Alle vier kommunizieren mir der
Projektarchiv-Schicht – libsvn_ra_local
verbindet sich direkt mit dem Projektarchiv; die drei anderen
machen das über das Netz. Die Bibliotheken
libsvn_fs_base
und
libsvn_fs_fs
sind noch ein Paar, das die
gleiche Funktion auf verschiedene Art implementiert –
beide sind Plug-Ins der gemeinsamen Bibliothek
libsvn_fs
.
Auch der Client selber unterstreicht die Vorteile der
Modularität beim Entwurf von Subversion. Die meisten Funktionen,
die für den Entwurf eines Subversion-Clients benötigt werden,
sind in der Bibliothek libsvn_client
vorhanden (siehe „Client-Schicht“). Obwohl das
Subversion-Paket lediglich das Kommandozeilenprogramm
svn mitbringt, stellen mehrere Programme von
Drittanbietern verschiedene Spielarten graphischer
Benutzeroberflächen zur Verfügung, die die gleichen APIs wie der
Standard-Kommandozeilen-Client verwenden. Diese Art der
Modularität hat eine große Rolle bei der Verbreitung verfügbarer
Subversion-Clients sowie Integrationen in Entwicklungsumgebungen
gespielt und durch Erweiterungen zur enormen Akzeptanzrate von
Subversion selbst beigetragen.
Wenn wir uns auf die Projektarchiv-Schicht von Subversion
beziehen, reden wir üblicherweise über zwei grundlegende
Konzepte – die Implementierung des versionierten
Dateisystems (auf das mittels libsvn_fs
zugegriffen wird, unterstützt durch dessen Plug-Ins
libsvn_fs_base
und
libsvn_fs_fs
) und die Logik des
Projektarchivs, die es umgibt (implementiert in
libsvn_repos
). Diese Bibliotheken liefern
die Speicher- und Auswertungsmechanismen für die verschiedenen
Revisionen Ihrer versionskontrollierten Daten. Diese Schicht
ist mit der Client-Schicht über die
Projektarchiv-Zugriffs-Schicht verbunden und stellt, aus der
Sicht des Benutzers von Subversion, das „andere Ende der
Leitung“ dar.
Das Dateisystem von Subversion ist kein Dateisystem auf Kernel-Ebene, das im Betriebssystem installiert würde (so wie Linux ext3 oder NTFS), sondern ein virtuelles Dateisystem. Anstatt „Dateien“ und „Verzeichnisse“ als echte Dateien und Verzeichnisse abzulegen (in denen Sie mit Ihrem bevorzugten Shell-Programm navigieren können), verwendet es eins von zwei verfügbaren abstrakten Speicherungsverfahren – entweder eine Berkeley-DB-Datenbankumgebung oder eine Repräsentation über einfache Dateien. (Um mehr über die zwei Verfahren kennenzulernen, siehe „Auswahl der Datenspeicherung“.) Es hat seitens der Entwicklergemeinschaft ein beträchtliches Interesse bestanden, künftigen Versionen von Subversion die Fähigkeit zu verleihen, andere Datenbanksysteme zu verwenden, etwa über einen Mechanismus wie Open Database Connectivity (ODBC). Tatsächlich hat Google etwas ähnliches gemacht, bevor der Dienst Google Code Project Hosting gestartet wurde: Mitte 2006 wurde angekündigt, dass Mitarbeiter des Open-Source-Teams ein neues proprietäres Dateisystem-Plug-In für Subversion geschrieben hätten, welches Googles höchstskalierbare Bigtable-Datenbank zum Speichern verwendet.
Die von libsvn_fs
exportierte
Dateisystem-Programmierschnittstelle enthält die Funktionen,
die Sie auch von jeder anderen Programmierschnittstelle für
ein Dateisystem erwarten würden – Sie können Dateien und
Verzeichnisse anlegen und löschen, kopieren und verschieben,
den Inhalt verändern usw. Sie besitzt auch Funktionen, die
nicht so verbreitet sind, wie etwa die Fähigkeit, Metadaten
(„Eigenschaften“) an jede Datei oder jedes
Verzeichnis anzufügen, zu verändern oder zu entfernen. Zudem
ist das Dateisystem von Subversion ein versioniertes
Dateisystem, d.h., während Sie Ihren Verzeichnisbaum ändern,
merkt sich Subversion, wie er vor Ihren Änderungen ausgesehen
hat. Und vor den vorhergehenden Änderungen. Und davor. Und so
weiter durch die gesamte versionierte Zeitachse bis zu dem
Moment (und kurz davor), an dem Sie das erste Mal etwas dem
Dateisystem hinzugefügt hatten.
Alle Änderungen, die Sie an Ihrem Baum vornehmen, geschehen im Kontext einer Subversion-Übergabe-Transaktion. Das Folgende ist eine vereinfachte allgemeine Vorgehensweise beim Ändern Ihres Dateisystems:
Eine Subversion-Übergabe-Transaktion starten.
Nehmen Sie Ihre Änderungen vor (Ergänzungen, Löschungen, Änderungen an Eigenschaften usw.).
Schließen Sie Ihre Transaktion ab.
Sobald Sie Ihre Transaktion abgeschlossen haben, werden Ihre Änderungen am Dateisystem dauerhaft als historische Artefakte gespeichert. Jeder dieser Zyklen erzeugt eine einzelne neue Revision Ihres Baums, und jede Revision ist für immer verfügbar als unveränderliche Momentaufnahme „der Dinge, wie sie mal waren“.
Die meisten von der Dateisystemschnittstellen angebotenen
Funktionen drehen sich um Aktionen, die auf einzelnen
Dateisystempfaden stattfinden. Von außerhalb des Dateisystems
betrachtet heißt das, dass der Hauptmechanismus zur
Beschreibung und Handhabung einzelner Datei- und
Verzeichnisrevisionen über Pfadzeichenketten wie
/foo/bar
erfolgt, genauso, als ob Sie
Dateien und Verzeichnisse über Ihr bevorzugtes Shell-Programm
ansprechen würden. Sie fügen neue Dateien und Verzeichnisse
hinzu, indem Sie die künftigen Pfade an die passenden
API-Funktionen übergeben. Sie können Informationen über den
gleichen Mechanismus abrufen.
Im Gegensatz zu den meisten Dateisystemen reicht jedoch ein Pfad alleine nicht aus, um in Subversion eine Datei oder ein Verzeichnis zu identifizieren. Stellen Sie sich einen Verzeichnisbaum als ein zweidimensionales System vor, in dem Nachbarknoten eine Art horizontale und die Unterverzeichnisse eines Knotens eine vertikale Bewegung repräsentieren. Abbildung 8.1, „Dateien und Verzeichnisse in zwei Dimensionen“ zeigt genau das als typische Repräsentierung eines Baums.
Der Unterschied ist hier, dass das Dateisystem von
Subversion eine raffinierte dritte Dimension hat, die den
meisten Dateisystemen fehlt – Zeit!
[49]
Fast jede Funktion der Dateisystemschnittstelle, die ein
path
-Argument erwartet, benötigt auch
ein root
-Argument. Dieses Argument vom
Typ svn_fs_root_t
beschreibt entweder eine
Revision oder eine Subversion-Transaktion (welche einfach eine
Revision in Arbeit ist) und stellt die dritte Dimension des
Kontexts zur Verfügung, die benötigt wird, um den Unterschied
zwischen /foo/bar
in Revision 32 und
demselben Pfad in Revision 98 zu verstehen. Abbildung 8.2, „Versionierung der Zeit – die dritte Dimension!“ zeigt die
Revisionsgeschichte als eine zusätzliche Dimension im
Subversion-Dateisystem-Universum.
Wie bereits erwähnt, mutet die
libsvn_fs
-API wie jedes andere
Dateisystem an, außer dass es diese wundervolle
Versionierungsmöglichkeit hat. Sie wurde entworfen, um für
jedes Programm nutzbar zu sein, das an einem versionierten
Dateisystem interessiert ist. Nicht nur zufällig hat
Subversion selbst Interesse an dieser Funktion. Doch obwohl
die Unterstützung der Dateisystemschnittstelle ausreichend für
die einfache Versionierung von Dateien und Verzeichnissen ist,
braucht Subversion mehr – und hier hat
libsvn_repos
seinen Auftritt.
Die Subversion-Projektarchiv-Bibliothek
(libsvn_repos
) sitzt (logisch) oberhalb
der libsvn_fs
-API und stellt zusätzliche
Funktionen zur Verfügung, die über die grundlegende Logik
eines versionierten Dateisystem hinausgehen. Sie umhüllt nicht
alle Dateisystemfunktionen vollständig – lediglich
bestimmte größere Schritte im allgemeinen Zyklus der
Dateisystemaktivität. Einige dieser Schritte umfassen die
Erzeugung und den Abschluss von Subversion-Transaktionen und
die Änderung von Revision-Eigenschaften. Diese besonderen
Ereignisse werden durch die Projektarchiv-Schicht gekapselt, da
mit ihnen Hooks verknüpft sind. Ein System mit
Projektarchiv-Hooks hat strenggenommen nichts mit der
Implementierung eines versionierten Dateisystems zu tun, so
dass es in der Projektarchiv-Bibliothek untergebracht ist.
Der Hook-Mechanismus ist aber nur ein Grund für die
Abstraktion einer eigenständigen Projektarchiv-Bibliothek vom
Rest des Dateisystemcodes. Die API
libsvn_repos
stellt mehrere andere
wichtige Werkzeuge für Subversion zur Verfügung. Darunter
fallen Fähigkeiten, um
ein Subversion-Projektarchiv und das darin enthaltene Dateisystem zu erzeugen, zu öffnen, zu zerstören und hierauf Schritte zur Wiederherstellung auszuführen.
die Unterschiede zwischen zwei Dateisystem-Bäumen zu beschreiben.
die Übergabe-Protokollnachrichten aller (oder einiger) Revisionen abzurufen, in denen eine Menge aus Dateien im Dateisystem verändert wurde.
einen menschenlesbaren „Auszug“ des Dateisystems zu erzeugen — eine vollständige Repräsentierung der Revisionen im Dateisystem.
dieses Auszugsformat zu lesen und die Revisionen in ein anderes Subversion-Projektarchiv zu laden.
Während sich Subversion weiterentwickelt, wird die Projektarchiv-Bibliothek gemeinsam mit der Dateisystem-Bibliothek wachsen und erweiterte Funktionen und konfigurierbare Optionen unterstützen.
Wenn die Subversion-Projektarchiv-Schicht das „andere
Ende der Leitung“ repräsentiert, stellt die
Projektarchiv-Zugriffs-Schicht (RA) die Leitung selbst dar. Ihre
Aufgabe ist das Umherschaufeln von Daten zwischen den
Client-Bibliotheken und dem Projektarchiv. Diese Schicht umfasst
die Bibliothek libsvn_ra
zum Laden von
Modulen, die eigentlichen RA-Module (momentan
libsvn_ra_neon
,
libsvn_ra_local
,
libsvn_ra_serf
und
libsvn_ra_svn
) und alle zusätzlichen
Bibliotheken, die von einer oder mehreren dieser RA-Module
benötigt werden (so wie das Apache-Modul
mod_dav_svn
oder
svnserve, der Server von
libsvn_ra_svn
).
Da Subversion URLs zum Identifizieren seiner
Projektarchiv-Quellen benutzt, wird der Protokollteil des
URL-Schemas (normalerweise file://
,
http://
, https://
,
svn://
oder svn+ssh://
)
verwendet, um festzustellen, welches RA-Modul die
Kommunikation abwickelt. Jedes Modul hinterlegt eine Liste von
Protokollen, die es „versteht“, so dass der
RA-Lader zur Laufzeit bestimmen kann, welches Modul für die
aktuelle Aufgabe benutzt werden kann. Sie können feststellen,
welche RA-Module für der Kommandozeilen-Client zur Verfügung
stehen und welche Protokolle sie zu verstehen vorgeben, indem
Sie svn --version
aufrufen:
$ svn --version svn, Version 1.5.0 (r31699) übersetzt Jun 18 2008, 09:57:36 Copyright (C) 2000-2008 CollabNet. Subversion ist Open-Source-Software, siehe http://subversion.tigris.org/ Dieses Produkt enthält Software, die von CollabNet (http://www.Collab.Net/) entwickelt wurde. Die folgenden ZugriffsModule (ZM) für Projektarchive stehen zur Verfügung: * ra_neon : Modul zum Zugriff auf ein Projektarchiv über das Protokoll WebDAV mittels Neon. - behandelt Schema »http« - behandelt Schema »https« * ra_svn : Modul zum Zugriff auf ein Projektarchiv über das svn-Netzwerkprotokoll. - mit Cyrus-SASL-Authentifizierung - behandelt Schema »svn« * ra_local : Modul zum Zugriff auf ein Projektarchiv auf der lokalen Festplatte - behandelt Schema »file« * ra_serf : Modul zum Zugriff auf ein Projektarchiv über das Protokoll WebDAV mittels serf. - behandelt Schema »http« - behandelt Schema »https« $
Die von der RA-Schicht exportierte API beinhaltet
Funktionen, die zum Senden und Empfangen versionierter Daten
zum und vom Projektarchiv notwendig sind. Jedes der verfügbaren
RA-Plug-Ins kann diese Aufgabe mithilfe eines besonderen
Protokolls erledigen –
libsvn_ra_dav
kommuniziert über
HTTP/WebDAV (optional mit SSL-Verschlüsselung) mit einem
Apache-HTTP-Server auf dem das Subversion-Server-Modul
mod_dav_svn
läuft;
libsvn_ra_svn
kommuniziert über ein
maßgeschneidertes Netzprotokoll mit dem
svnserve Programm usw.
Für diejenigen, die über ein völlig anderes Protokoll auf das Projektarchiv zugreifen möchten, sei gesagt, dass genau das der Grund für die Modularisierung der Projektarchiv-Zugriffsschicht ist. Entwickler können einfach eine neue Bibliothek schreiben, die auf der einen Seite die RA-Schnittstelle implementiert und auf der anderen Seite mit dem Projektarchiv kommuniziert. Ihre neue Bibliothek kann bestehende Netzprotokolle verwenden, oder Sie können Ihr eigenes erfinden. Sie könnten Aufrufe über Interprozess-Kommunikation (IPC) machen oder – mal etwas verrücktes – sogar ein auf E-Mail basiertes Protokoll implementieren. Subversion liefert die APIs, Sie sorgen für die Kreativität.
Auf der Client-Seite finden alle Aktionen in der Subversion-Arbeitskopie statt. Der größte Teil der in den Client-Bibliotheken implementierten Funktionen dient dem alleinigen Zweck, die Arbeitskopien zu verwalten – Verzeichnisse voller Dateien und anderer Unterverzeichnisse, die als eine Art lokaler, editierbarer „Spiegelung“ einer oder mehrere Orte im Projektarchiv dienen – und Änderungen an die RA-Schicht weiterzugeben oder von ihr zu empfangen.
Die Bibliothek für die Arbeitskopie von Subversion,
libsvn_wc
, ist direkt dafür
verantwortlich, die Daten in den Arbeitskopien zu verwalten.
Hierzu speichert die Bibliothek Verwaltungsinformationen zu
jedem Verzeichnis der Arbeitskopie in einem besonderen
Unterverzeichnis. Dieses Unterverzeichnis namens
.svn
kommt in jedem Unterverzeichnis der
Arbeitskopie vor und beinhaltet zahlreiche weitere Dateien und
Verzeichnisse, in denen der Zustand aufgezeichnet wird und die
einen privaten Arbeitsbereich für Verwaltungsaufgaben liefern.
Für diejenigen, die CVS kennen, ist der Zweck des
Unterverzeichnisses .svn
ähnlich den in
CVS-Arbeitskopien zu findenden Verwaltungsverzeichnissen
CVS
. Weiter gehende Informationen zum
.svn
-Verwaltungsbereich finden sie später
in diesem Kapitel unter „Innerhalb des Verwaltungsbereichs für Arbeitskopien“.
Die Subversion-Client-Bibliothek,
libsvn_client
, besitzt die weitestgehende
Verantwortlichkeit; ihre Aufgabe ist es, die Funktionen der
Arbeitskopie-Bibliothek mit denen der RA-Schicht zu vermischen
und eine API auf höchster Ebene für Anwendungen zur Verfügung
zu stellen, die allgemeine Versionskontrollaktionen
durchführen wollen. Beispielsweise erwartet die Funktion
svn_client_checkout()
einen URL als
Argument. Sie leitet diesen URL an die RA-Schicht weiter und
startet eine authentifizierte Sitzung mit einem bestimmten
Projektarchiv. Dann fragt sie das Projektarchiv nach einem
bestimmten Baum und schickt diesen Baum an die
Arbeitskopie-Bibliothek, die dann die gesamte Arbeitskopie auf
die Platte schreibt (samt
.svn
-Verzeichnissen und allem Drum und
Dran).
Die Client-Bibliothek ist so aufgebaut, dass sie von jeder
Anwendung verwendet werden kann. Obwohl der Quelltext von
Subversion einen Standard-Kommandozeilen-Client enthält,
sollte es sehr einfach sein, eine beliebige Anzahl von
graphischen Clients zu schreiben, die auf die
Client-Bibliothek aufsetzen. Neue graphische Oberflächen (oder
eigentlich jeder neue Client) für Subversion brauchen keine
sperrigen Hüllen um den enthaltenen Kommandozeilen-Client zu
sein – sie haben über die API von
libsvn_client
vollen Zugriff auf die
Funktionen, Daten und Rückrufmechanismen die der
Kommandozeilen-Client benutzt. Tatsächlich enthält der
Quelltext von Subversion ein kleines C-Programm (das Sie unter
tools/examples/minimal_client.c
finden)
welches beispielhaft zeigt, wie die Subversion API verwendet
wird, um ein einfaches Client-Programm zu erzeugen.
[49] Wir sind uns bewusst, dass das für Science-Fiction-Fans, die lange Zeit davon ausgegangen sind, dass Zeit eigentlich die vierte Dimension ist, ein Schock sein kann, und wir bitten um Entschuldigung, falls die Geltendmachung einer unterschiedlichen Theorie unsererseits zu einem seelischen Schock führen sollte.