Sie haben bereits über Arbeitskopien gelesen; nun werden wir zeigen, wie Subversion diese erstellt und benutzt.
Eine Subversion-Arbeitskopie ist eine ganz normale Ordnerstruktur auf einem lokalen Dateisystem, die eine Anzahl von Dateien enthält. Sie können diese Dateien ändern wie Sie wollen, und falls es Quellcode-Dateien sind, können Sie diese kompilieren wie sonst auch. Ihre Arbeitskopie ist Ihr eigenes privates Arbeitsfeld: Subversion wird nie Änderungen von anderen einfügen oder Ihre Änderungen anderen zur Verfügung stellen, ohne dass Sie Subversion explizit dazu auffordern.
Nachdem Sie einige Änderungen an den Dateien in Ihrer Arbeitskopie vorgenommen haben und überprüft haben, dass diese immer noch korrekt funktionieren, stellt Ihnen Subversion Befehle zur Verfügung, um Ihre Änderungen zu publizieren (durch Speichern im zentralen Projektarchiv), d. h. anderen zur Verfügung zu stellen. Falls andere Benutzer ihre Änderungen veröffentlicht haben, stellt Subversion Befehle zur Verfügung, mit denen Sie diese Änderungen in Ihre Arbeitskopie einfügen können (durch Lesen aus dem zentralen Projektarchiv).
Eine Arbeitskopie enthält auch einige Extradateien, die Subversion erzeugt und verwaltet, um diese Kommandos auszuführen. Insbesondere enthält Ihre Arbeitskopie ein Unterverzeichnis namens .svn
, das auch Verwaltungsordner der Arbeitskopie genannt wird. Die Dateien in diesem Verwaltungsordner benutzt Subversion, um zu erkennen, welche Dateien unveröffentlichte Änderungen enthalten und welche Dateien in Bezug zur Arbeit anderer Teammitglieder veraltet sind. Vor der Version 1.7 unterhielt Subversion einen .svn
-Ordner in jedem versionierten Unterverzeichnis Ihrer Arbeitskopie. Subversion 1.7 wählt hier einen völlig anderen Ansatz: jede Arbeitskopie enthält von jetzt an nur noch einen Verwaltungsordner, der direkt im Wurzelverzeichnis dieser Arbeitskopie angesiedelt ist.
Ein typisches Subversion-Projektarchiv enthält oft Dateien (oder Quellcode) von mehreren Projekten; normalerweise ist jedes Projekt ein Unterordner im Dateibaum. In einem solchen Umfeld enthält eine Arbeitskopie normalerweise nur einen bestimmten Unterordner des Projektarchivs.
Als Beispiel nehmen Sie an, dass Sie ein Projektarchiv haben, das zwei Softwareprojekte enthält.
Mit anderen Worten: das Hauptverzeichnis des Projektarchivs hat zwei Unterordner: paint
und calc
.
Um eine Arbeitskopie zu erhalten, müssen Sie einen dieser Unterordner aus dem Projektarchiv auschecken. Der Begriff auschecken klingt so, als würden dadurch Ressourcen gesperrt oder reserviert, aber dem ist nicht so. Es wird lediglich eine private Kopie des Projekts für Sie erzeugt.
Angenommen, Sie machen Änderungen an der Datei button.c
. Da der .svn
-Ordner den Originalinhalt und das Änderungsdatum gespeichert hat, kann Subversion feststellen, dass Sie diese Datei geändert haben. Jedoch wird Subversion diese Änderungen erst veröffentlichen, wenn Sie Subversion dazu ausdrücklich auffordern. Der Vorgang des Veröffentlichens ist allgemein mit dem Begriff Übertragen oder Einchecken (engl. to commit
oder to check in
) belegt.
Um Ihre Änderungen anderen zur Verfügung zu stellen, verwenden Sie den Befehl Übertragen.
Danach sind Ihre Änderungen an der Datei button.c
im Projektarchiv gespeichert; falls jemand anders nun eine neue Arbeitskopie von /calc
auscheckt, wird diese auch Ihre letzten Änderungen an der Datei button.c
enthalten.
Nehmen Sie an, Sie haben eine Mitarbeiterin, Sally, die eine Arbeitskopie von /calc
zur selben Zeit wie Sie ausgecheckt hat. Wenn Sie Ihre Änderungen übertragen, bleibt die Arbeitskopie von Sally unverändert. Subversion ändert nur dann etwas an einer Arbeitskopie, wenn Sie es ausdrücklich dazu auffordern.
Um ihre Arbeitskopie auf den neusten Stand zu bringen, sagt Sally Subversion, dass es ihre Arbeitskopie aktualisieren soll mittels des Aktualisieren-Befehls. Dies wird Ihre Änderungen in die Arbeitskopie von Sally übernehmen, genau wie alle weiteren Änderungen, die andere vorgenommen haben, seit Sally ihre Arbeitskopie zuletzt aktualisiert hat.
Beachten Sie, dass Sally nicht angeben muss, welche Dateien genau Subversion aktualisieren soll; Subversion nutzt die Informationen im .svn
Ordner und weitere Informationen aus dem Projektarchiv, um dies selbst festzustellen.
Auf Subversion Projektarchive kann mittels vieler verschiedener Methoden zugegriffen werden - lokal oder durch verschiedene Netzwerk-Protokolle. Auf ein Objekt im Projektarchiv wird immer über eine URL zugegriffen. Das URL-Schema zeigt die Zugriffsmethode:
Tabelle 2.1. Zugriffs-URLs für das Projektarchiv
Schema | Zugriffsmethode |
---|---|
file://
| Direkter Zugriff auf einer lokalen Festplatte oder einem Netzwerkverzeichnis. |
http://
| Zugriff via WebDAV-Protokoll auf einen Apache-Server, auf dem Subversion installiert ist. |
https://
| Wie http:// , aber mit SSL-Verschlüsselung. |
svn://
| Nicht authentifizierter TCP/IP Zugriff mittels eigenem Protokoll auf einen svnserve Server. |
svn+ssh://
| Authentifizierter, verschlüsselter TCP/IP Zugriff mittels eigenem Protokoll auf einen svnserve Server. |
In den weitaus meisten Fällen nutzen Subversion-URLs die Standardsyntax und erlauben, dass Servernamen und Portnummern als Teil der URL angegeben werden. Beachten Sie jedoch, dass die Zugriffsmethode file://
normalerweise nur für den Zugriff auf lokale Projektarchive verwendet wird, obwohl auch mittels eines UNC-Pfades auf ein Projektarchiv im Netzwerk zugegriffen werden kann. In diesem Fall nimmt die URL die Form file://rechnername/pfad/zum/projektarchiv
an. Bei einem lokalen Projektarchiv muss der Rechnername entweder leer oder localhost
sein. Deshalb enthalten lokale Pfade meistens drei Schrägstriche, file:///pfad/zum/projektarchiv
.
Zudem müssen Benutzer des Schemas file://
auf Windowsrechnern eine nicht offizielle „Standard“-Syntax für die URL verwenden. Jede der folgenden URLs funktioniert, wobei X
das Laufwerk mit dem Projektarchiv ist:
file:///X:/path/to/repos ... file:///X|/path/to/repos ...
Beachten Sie, dass die URL normale Schrägstriche verwendet, obwohl Windows-Pfade mit umgekehrten Schrägstrichen angegeben werden.
Sie können zwar per Netzwerkfreigabe auf ein FSFS-Projektarchiv zugreifen, dies wird jedoch aus verschiedenen Gründen nicht empfohlen:
Sie geben sämtlichen Anwendern vollständigen Schreibzugriff, sodass diese versehentlich das Projektarchiv löschen oder beschädigen können.
Nicht alle Netzwerkfreigabeprotokolle unterstützen die von Subversion benötigten Sperrmechanismen, was dazu führen kann, dass Ihr Projektarchiv subtil beschädigt wird.
Sie müssen die Zugriffsberechtigungen exakt richtig setzen. Samba ist in dieser Hinsicht besonders schwierig.
Wenn eine Person einen neueren Client installiert und dieser das Format des Projektarchivs hochstuft, können alle anderen solange nicht auf das Projektarchiv zugreifen, bis sie ebenfalls auf die neueste Clientversion aktualisiert haben.
Ein Übertragen-Befehl kann Änderungen an beliebig vielen Dateien und Ordnern als eine einzige atomare Operation übertragen. In Ihrer Arbeitskopie können Sie Dateien ändern, erstellen, löschen, umbenennen und verschieben und dann alle diese Änderungen in einem einzigen Schritt übertragen.
Im Projektarchiv wird jede Übertragung als eine einzige atomare Transaktion behandelt: entweder werden alle Änderungen abgespeichert oder gar keine. Subversion stellt dies sogar im Falle von Systemabstürzen, Netzwerkproblemen, Stromausfällen oder anderen Problemen sicher.
Jedes mal wenn ein Projektarchiv eine Übertragung akzeptiert, wird dadurch ein neuer Zustand der Dateistruktur erzeugt. Ein solcher Zustand wird Revision genannt. Jeder Revision wird eine natürliche Zahl zugeordnet, jeweils um eins größer als die vorherige Revision. Der Ursprungszustand eines Projektarchivs bei der Erstellung ist also Revision 0. Revision 0 enthält nichts außer einem leeren Hauptverzeichnis.
Eine Möglichkeit, sich das Projektarchiv vorzustellen, ist als eine Reihe von Bäumen. Stellen Sie sich eine Reihe von Revisionsnummern vor, beginnend mit 0, die sich von links nach rechts ausdehnt. An jeder Revisionsnummer hängt ein Dateibaum, und jeder dieser Bäume ist eine „Momentaufnahme“ davon, wie das Projektarchiv nach der jeweiligen Übertragung ausgesehen hat.
Es ist wichtig zu beachten, dass Arbeitskopien nicht immer mit einer einzigen Revision des Projektarchivs übereinstimmen; sie können Dateien von verschiedenen Revisionen enthalten. Nehmen Sie zum Beispiel an, Sie haben aus einem Projektarchiv eine Arbeitskopie ausgecheckt, bei welcher die neueste Revision die 4 ist:
calc/Makefile:4 integer.c:4 button.c:4
In diesem Moment entspricht die Arbeitskopie exakt der Revision 4 im Projektarchiv. Nun nehmen Sie an, Sie ändern die Datei button.c
und übertragen diese Änderungen. Nehmen Sie weiter an, dass keine weiteren Änderungen vorgenommen wurden und Ihre Übertragung eine neue Revision 5 im Projektarchiv erstellt. Ihre Arbeitskopie wird dann so aussehen:
calc/Makefile:4 integer.c:4 button.c:5
Nehmen Sie nun an, dass jetzt Sally Änderungen an der Datei integer.c
überträgt und damit eine Revision 6 erstellt. Wenn Sie nun Ihre Arbeitskopie aktualisieren, wird diese so aussehen:
calc/Makefile:6 integer.c:6 button.c:6
Sallys Änderungen an der Datei integer.c
werden in Ihre Arbeitskopie eingefügt, und Ihre Änderungen in der Datei button.c
werden immer noch vorhanden sein. In diesem Beispiel ist der Inhalt der Datei Makefile
identisch in den Revisionen 4, 5 und 6, aber Subversion markiert Ihre lokale Kopie von Makefile
mit Revision 6 um zu zeigen, dass diese immer noch aktuell ist. Also wird, nachdem Sie eine saubere Aktualisierung durchgeführt haben, Ihre Arbeitskopie exakt einer Revision im Projektarchiv entsprechen.
Für jede Datei in einer Arbeitskopie zeichnet Subversion zwei wesentliche Informationen im .svn
-Administrationsordner auf:
Die Revision, auf der Ihre Arbeitsdatei basiert (wird als Arbeitsrevision bezeichnet), und
Der Zeitpunkt, an dem die Datei zum letzten Mal aus dem Projektarchiv aktualisiert wurde.
Mittels dieser Informationen ist Subversion in der Lage, durch Anfragen an das Projektarchiv herauszufinden, in welchem der folgenden vier Zustände eine Datei ist:
Die Datei wurde weder lokal noch im Projektarchiv verändert. Sowohl Übertragen als auch Aktualisieren dieser Datei bewirken nichts.
Die Datei wurde lokal verändert, aber nicht im Projektarchiv. Eine Übertragung bewirkt ein Speichern dieser Änderungen im Projektarchiv. Eine Aktualisierung hingegen bewirkt nichts.
Die Datei wurde lokal nicht verändert, jedoch gibt es Änderungen an der Datei im Projektarchiv. Eine Übertragung bewirkt nichts, jedoch wird ein Aktualisieren die Änderungen aus dem Projektarchiv in die lokale Kopie der Datei einfügen.
Die Datei wurde lokal und im Projektarchiv verändert. Ein Übertragen wird mit der Fehlermeldung nicht mehr aktuell fehlschlagen. Sie müssen die Datei zuerst Aktualisieren, um die Änderungen aus dem Projektarchiv in die lokale Kopie einzufügen. Wenn Subversion nicht in der Lage sein sollte, diese Änderungen selbst zusammenzuführen, was selten der Fall ist, überlässt es das Auflösen des Konflikts dem Benutzer.