Subversion implementiert das Konzept eines Projektarchivs für Versionskontrolle so, wie es jedes andere moderne Versionskontrollsystem auch machen würde. Im Gegensatz zu einer Arbeitskopie ist ein Subversion-Projektarchiv ein abstraktes Gebilde, das sich fast ausschließlich über die eigenen Subversion-Bibliotheken und -Werkzeuge manipulieren lässt. Da die meisten Interaktionen eines Anwenders mit Subversion die Benutzung des Subversion-Clients einbeziehen und im Kontext einer Arbeitskopie vollzogen werden, wird sich ein großer Teil dieses Buches mit dem Subversion-Projektarchiv und dessen Bearbeitung beschäftigen. Für die Feinheiten des Projektarchivs, siehe allerdings Kapitel 5, Verwaltung des Projektarchivs.

Ein Subversion-Client übergibt eine (d.h., übermittelt die Änderungen an einer) beliebigen Anzahl von Dateien und Verzeichnissen als eine einzige atomare Transaktion. Eine atomare Transaktion bedeutet: entweder es gehen alle Änderungen in das Projektarchiv oder keine. Angesichts von Programm- und Systemabstürzen, Netzproblemen oder anderer Anwenderaktionen hält Subversion an dieser Atomizität fest.

Jedes Mal wenn das Projektarchiv eine Übertragung annimmt, wird ein neuer Zustand des Dateisystem-Baums erzeugt, der Revision genannt wird. Jeder Revision wird eine einmalige natürliche Zahl zugewiesen, die um eins größer ist als die Vorgänger-Revision. Die anfängliche Revision eines frisch erzeugten Projektarchivs bekommt die Nummer 0 und besteht lediglich aus einem leeren Wurzelverzeichnis.

Abbildung 1.6, „Änderungen am Baum im Verlauf der Zeit“ zeigt, wie man sich das Projektarchiv vorstellen kann. Stellen Sie sich eine Reihe von Revisionsnummern vor, die bei 0 startet und von links nach rechts wächst. Jede Revisionsnummer hat einen Dateisystem-Baum unter sich hängen, der ein „Schnappschuss“ des Projektarchivs nach einer Übertragung ist.

Abbildung 1.6. Änderungen am Baum im Verlauf der Zeit

Subversion-Client-Programme verwenden URLs, um Dateien und Verzeichnisse in Subversion-Projektarchivs zu identifizieren. Meistens benutzen diese URLs die Standardsyntax, die es erlaubt, Servernamen und Portnummern als Teil des URL zu spezifizieren.

Die Subversion-Projektarchiv-URLs sind nicht beschränkt auf den Typ http://. Da Subversion mehrere unterschiedliche Kommunikationswege zwischen seinen Clients und Servern anbietet, unterscheiden sich die zur Adressierung des Projektarchivs verwendeten URLs auf eine subtile Art, abhängig davon, welcher Zugriffsmechanismus zum Projektarchiv angewendet werden soll. Tabelle 1.1, „Projektarchiv-Zugriffs-URLs“ beschreibt, wie unterschiedliche URL Schemata auf die verfügbaren Zugriffsmethoden abgebildet werden. Details über die Serveroptionen von Subversion finden Sie unter Kapitel 6, Konfiguration des Servers.

Allerdings gibt es einige bemerkenswerte Feinheiten, wie Subversion mit URLs umgeht. Beispielsweise dürfen URLs, die die file://-Zugriffsmethode enthalten (für lokale Projektarchive verwendet), gemäß Konvention entweder den Servernamen localhost oder gar keinen Servernamen enthalten:

Darüber hinaus müssen Benutzer des file:// Schemas auf Windows-Plattformen eine inoffizielle „Standard“-Syntax verwenden falls auf Projektarchive auf derselben Maschine aber auf einem anderen Laufwerk zugegriffen werden soll. Beide der folgenden URL-Pfad-Syntaxen funktionieren, wobei X das Laufwerk ist, wo das Projektarchiv liegt:

Beachten Sie, dass ein URL Schrägstriche verwendet, selbst wenn die übliche (nicht-URL) Form eines Pfades unter Windows rückwärtige Schrägstriche verwendet. Beachten Sie ebenfalls, bei der Verwendung des Formats file:///X|/ den URL in Anführungsstriche einzuschließen, damit der senkrechte Strich nicht als Pipe-Symbol interpretiert wird.

Anmerkung

Sie können die file:// URLs von Subversion nicht in einem normalen Web-Browser auf die Art und Weise verwenden wie andere file:// URLs. Falls Sie versuchen, einen file:// URL in einem gewöhnlichen Web-Browser anzusehen, wird der Inhalt der Datei von der angegebenen Stelle direkt aus dem Dateisystem gelesen und angezeigt. Allerdings befinden sich die Daten von Subversion in einem virtuellen Dateisystem (siehe „Projektarchiv-Schicht“), und der Browser wird nicht mit diesem Dateisystem umzugehen wissen.

Der Subversion-Client wandelt URLs nach Bedarf automatisch um, wie es auch ein Web-Browser macht. So wird beispielsweise der URL http://host/path with space/project/españa – der sowohl Leerzeichen als auch Zeichen aus dem höheren ASCII-Bereich enthält – automatisch von Subversion so interpretiert als ob sie http://host/path%20with%20space/project/espa%C3%B1a geschrieben hätten. Falls der URL Leerzeichen enthält, stellen Sie sicher, ihn auf der Kommandozeile in Anführungszeichen zu setzen, so dass Ihre Shell alles als ein einzelnes Argument für das Programm behandelt.

Es gibt eine erwähnenswerte Ausnahme von der Regel, wie Subversion URLs behandelt, die in vielen Kontexten auch auf die Behandlung lokaler Pfade anwendbar ist. Falls die letzte Pfadkomponente des URL oder lokalen Pfades einen Klammeraffen (@) enthält, müssen Sie eine besondere Syntax verwenden – in „Peg- und operative Revisionen“ beschrieben – damit Subversion diese Ressource passend ansprechen kann.

In Subversion 1.6 wurde eine neue Notation mit Zirkumflex (^) als Kurzschreibweise für „der URL des Wurzelverzeichnisses des Projektarchivs“ eingeführt. Sie können beispielsweise ^/tags/bigsandwich/ verwenden, um sich auf den URL des Verzeichnisses /tags/bigsandwich im Wurzelverzeichnis des Projektarchivs zu beziehen. Beachten Sie, dass dieser URL nur dann funktioniert, wenn Ihre aktuelles Arbeitsverzeichnis eine Arbeitskopie ist – der Kommandozeilen-Client kennt den URL des Projektarchiv-Wurzelverzeichnisses, da er sich die Metadaten der Arbeitskopie ansieht. Beachten Sie auch, dass Sie ^/ statt nur ^ verwenden (mit dem abschließenden Schrägstrich), wenn Sie sich auf das Wurzelverzeichnis des Projektarchivs beziehen möchten.

Eine Subversion-Arbeitskopie ist ein gewöhnlicher Verzeichnisbaum auf Ihrem lokalen System, der eine Ansammlung von Dateien enthält. Sie können diese Dateien nach belieben bearbeiten, und wenn es sich um Quelltexte handelt, können Sie hieraus Ihr Programm auf die übliche Weise compilieren. Ihre Arbeitskopie ist Ihr privater Arbeitsbereich: nie wird Subversion weder die Änderungen von anderen einpflegen, noch Ihre eigenen Änderungen anderen zur Verfügung stellen, bis Sie es ausdrücklich dazu auffordern. Sie können sogar mehrere Arbeitskopien desselben Projektes haben.

Nachdem Sie einige Änderungen an den Dateien Ihrer Arbeitskopie gemacht und sichergestellt haben, dass sie funktionieren, stellt Ihnen Subversion Befehle zur Verfügung, um Ihre Änderungen den anderen, die an Ihrem Projekt mitarbeiten, „publik“ zu machen (indem es ins Projektarchiv schreibt). Wenn die anderen ihre Änderungen veröffentlichen, stellt Ihnen Subversion Befehle zur Verfügung, um diese Änderungen in Ihr Arbeitsverzeichnis einzupflegen (indem es aus dem Projektarchiv liest).

Eine Arbeitskopie verfügt darüber hinaus über einige zusätzliche Dateien, die von Subversion erzeugt und gepflegt werden, um es bei diesen Befehlen zu unterstützen. Insbesondere enthält jede Arbeitskopie ein Unterverzeichnis namens .svn, auch bekannt als das Verwaltungsverzeichnis der Arbeitskopie. Die Dateien in jedem Verwaltungsverzeichnis helfen Subversion dabei, zu erkennen, welche Ihrer versionierten Dateien unveröffentlichte Änderungen enthalten und welche Dateien hinsichtlich der Arbeit anderer veraltet sind.

Anmerkung

Vor Version 1.7 unterhielt Subversion administrative .svn-Unterverzeichnisse in jedem versionierten Verzeichnis Ihrer Arbeitskopie. Subversion 1.7 bietet einen völlig neuen Ansatz für die Speicherung und Verwaltung von Metadaten der Arbeitskopie; der sichtbarste Unterschied ist, dass jede Arbeitskopie nur ein .svn Unterverzeichnis als unmittelbares Kind des Wurzelverzeichnisses der Arbeitskopie besitzt.

Tipp

Obwohl .svn der allgemeine Standardname für das Subversion-Verwaltungsverzeichnis ist, könnten Windows mit dem ASP.NET Web-Application-Framework bekommen, das Zugriff auf Verzeichnisse verbietet, deren Namen mit einem Punkt (.) beginnt. Mit Rücksicht auf Anwender in solchen Situationen verwendet Subversion stattdessen _svn als Namen für das Verwaltungsverzeichnis, falls es eine Variable namens SVN_ASP_DOT_NET_HACK in seiner Arbeitsumgebung findet. Für dieses Buch gelten durchgängig alle Referenzen auf .svn ebenfalls für _svn, falls dieser „ASP.NET Hack“ angewendet wird.

Grundlegende Interaktionen der Arbeitskopie

Oft enthält ein typisches Subversion-Projektarchiv die Dateien (oder den Quelltext) für verschiedene Projekte; für gewöhnlich ist jedes Projekt ein Unterverzeichnis im Dateisystembaum des Projektarchivs. Bei dieser Anordnung entspricht die Arbeitskopie eines Benutzers gewöhnlich einem bestimmten Unterverzeichnis des Projektarchivs.

Nehmen wir zum Beispiel an, Sie haben ein Projektarchiv, das zwei Software-Projekte beinhaltet, paint und calc. Jedes Projekt ist in einem eigenen Hauptverzeichnis abgelegt, wie in Abbildung 1.7, „Das Dateisystem des Projektarchivs“ dargestellt.

Abbildung 1.7. Das Dateisystem des Projektarchivs

Um eine Arbeitskopie zu erhalten, muss zunächst irgendein Teilbaum des Projektarchivs ausgecheckt werden (check out). (Der Begriff check out hört sich an, als habe es etwas mit dem Sperren oder Reservieren von Ressourcen zu tun, hat es aber nicht; es erzeugt lediglich eine Arbeitskopie des Projektes für Sie.) Wenn Sie zum Beispiel /calc auschecken, bekommen Sie eine Arbeitskopie wie diese:

$ svn checkout http://svn.example.com/repos/calc
A    calc/Makefile
A    calc/integer.c
A    calc/button.c 
Ausgecheckt, Revision 56.
$ ls -A calc
Makefile  button.c integer.c .svn/
$

Die Liste der As am linken Rand zeigt an, dass Subversion Ihrer Arbeitskopie eine Anzahl von Objekten hinzufügt (Add). Sie haben nun eine persönliche Kopie des Verzeichnisses /calc im Projektarchiv, mit einem zusätzlichen Eintrag – .svn – das, wie bereits erwähnt, die besonderen Informationen enthält, die Subversion benötigt.

Angenommen, Sie nehmen Änderungen an button.c vor. Da sich das Verzeichnis .svn den ursprünglichen Änderungszeitpunkt und den Inhalt der Datei merkt, kann Subversion erkennen, dass Sie die Datei verändert haben. Trotzdem veröffentlicht Subversion Ihre Änderungen solange nicht, bis Sie es ausdrücklich hierzu auffordern. Der Vorgang des Veröffentlichens von Änderungen über das Projektarchiv ist gemeinhin bekannter als commit (oder check in).

Um Ihre Änderungen anderen gegenüber zu veröffentlichen, können Sie den Subversion-Befehl svn commit verwenden:

$ svn commit button.c -m "Fixed a typo in button.c." 
Sende          button.c
Übertrage Daten .
Revision 6 übertragen.
$

Nun sind Ihre Änderungen an button.c dem Projektarchiv überstellt, mitsamt einer Notiz, die Ihre Änderung beschreibt (nämlich, dass Sie einen Tippfehler beseitigt haben). Wenn eine andere Benutzerin eine Arbeitskopie von /calc auscheckt, wird sie Ihre Änderungen in der letzten Version der Datei sehen können.

angenommen, Sie haben eine Mitarbeiterin, Sally, die eine Arbeitskopie von /calc gleichzeitig mit Ihnen ausgecheckt hat. Wenn Sie Ihre Änderung an button.c übertragen, bleibt Sallys Arbeitskopie unverändert; Subversion ändert Arbeitskopien nur auf Wunsch des Benutzers.

Um ihr Projekt auf den neuesten Stand zu bringen, kann Sally Subversion dazu auffordern, ihre Arbeitskopie zu aktualisieren, indem sie den Befehl svn update verwendet. Das bringt sowohl Ihre als auch alle anderen Änderungen die übertragen wurden seit sie ausgecheckt hatte in ihre Arbeitskopie.

$ pwd
/home/sally/calc
$ ls -A
Makefile button.c integer.c .svn/
$ svn update
Updating '.':
U    button.c 
Aktualisiert zu Revision 57.
$

Die Ausgabe des svn update Befehls zeigt, dass Subversion den Inhalt von button.c aktualisiert hat (Update). Beachten Sie, dass Sally nicht angeben musste, welche Dateien zu aktualisieren sind; Subversion benutzt die Informationen aus dem .svn Verzeichnis und darüber hinaus weitere Informationen im Projektarchiv, um zu entscheiden, welche Dateien auf den neuesten Stand gebracht werden müssen.