Es ist an der Zeit, sich vom Abstrakten zum Konkreten zu bewegen. In diesem Abschnitt werden wir echte Beispiele zur Benutzung von Subversion zeigen.
Das ganze Buch hindurch verwendet Subversion 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:
$ svn checkout http://svn.example.com:9834/repos …
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:
$ svn checkout file:///var/svn/repos … $ svn checkout file://localhost/var/svn/repos …
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:
C:\> svn checkout file:///X:/var/svn/repos … C:\> svn checkout "file:///X|/var/svn/repos" …
Bei der zweiten Syntax muss der URL in Anführungsstriche eingeschlossen werden, damit der senkrechte Strich nicht als Pipe-Symbol interpretiert wird. Beachten Sie auch, dass in einem URL Schrägstriche verwendet werden, obwohl es unter Windows üblich ist, für Pfade umgekehrte Schrägstriche zu verwenden.
Anmerkung | |
---|---|
Sie können die |
Zuletzt sei noch angemerkt, dass der Subversion-Client, wie ein Web-Browser, nötigenfalls automatisch URLs umwandelt. Falls zum Beispiel in einem URL Leerzeichen oder Großbuchstaben vorkommen wie hier:
$ svn checkout "http://host/path with space/project/españa"
wird Subversion die unsicheren Zeichen umwandeln, als ob Sie
$ svn checkout http://host/path%20with%20space/project/espa%C3%B1a
geschrieben hätten.
Falls ein URL Leerzeichen beinhalten sollte, stellen Sie sicher, das der URL in Anführungszeichen gesetzt wird, damit die Shell alles als ein Argument für das svn Programm behandelt.
Sie haben schon über Arbeitskopien gelesen; nun werden wir zeigen, wie der Subversion-Client sie erzeugt und benutzt.
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 jedes Verzeichnis Ihrer Arbeitskopie ein
Unterverzeichnis namens .svn
, auch
bekannt als das Verwaltungsverzeichnis
der Arbeitskopie. Die Dateien in jedem Verwaltungsverzeichnis
helfen Subversion dabei, zu erkennen, welche Dateien
unveröffentlichte Änderungen enthalten und welche Dateien
hinsichtlich der Arbeit anderer veraltet sind.
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.6, „Das Dateisystem des Projektarchivs“ dargestellt.
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 private Kopie 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 A
s 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 "Tippfehler in button.c korrigiert" 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
committen, 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 committet wurden seit sie ausgecheckt hatte in ihre Arbeitskopie.
$ pwd /home/sally/calc $ ls -A Makefile button.c integer.c .svn/ $ svn update 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.
Ein svn commit veröffentlicht Änderungen an einer beliebigen Anzahl von Dateien und Verzeichnissen als eine einzige atomare Transaktion. In Ihrer Arbeitskopie können Sie Dateiinhalte ändern, Dateien und Verzeichnisse erzeugen, löschen, umbenennen und kopieren und dann den gesamten Umfang der Änderungen als atomare Transaktion durch ein svn commit in das Projektarchiv einbringen.
Eine atomare Transaktion bedeutet: entweder es gehen alle Änderungen in das Projektarchiv oder keine. Angesichts von Programmabstürzen, Systemabstürzen, Netzproblemen oder anderer Benutzeraktionen hält Subversion an dieser Atomizität fest.
Jedes Mal wenn das Projektarchiv ein Commit 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.7, „Das Projektarchiv“ 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 einem Commit ist.
Es ist wichtig zu beachten, dass eine Arbeitskopie nicht immer genau einer Revision im Projektarchiv zugeordnet werden kann; sie kann Dateien aus verschiedenen Revisionen beinhalten. Nehmen wir z.B. an, Sie checken sich eine Arbeitskopie einer Datei aus einem Projektarchiv aus, deren neueste Revision 4 ist:
calc/Makefile:4 integer.c:4 button.c:4
In diesem Augenblick entspricht Ihre Arbeitskopie exakt
der Revision im Projektarchiv. Sie machen jetzt allerdings eine
Änderung an button.c
und bringen diese
Änderung mit einem Commit ins Projektarchiv. Angenommen, dass
keine weiteren Commits vorgenommen wurden, wird Ihr Commit die
Revision 5 im Projektarchiv erzeugen, und Ihre Arbeitskopie sieht
so aus:
calc/Makefile:4 integer.c:4 button.c:5
Angenommen, zu diesem Zeitpunkt macht Sally einen Commit
für eine Änderung an integer.c
und
erzeugt Revision 6. Wenn Sie svn update
verwenden, um Ihre Arbeitskopie zu aktualisieren, sieht sie so
aus:
calc/Makefile:6 integer.c:6 button.c:6
Sallys Änderung an integer.c
erscheint in Ihrer Arbeitskopie, und Ihre Änderung ist immer
noch in button.c
. In diesem Beispiel ist
der Text von Makefile
in den Revisionen
4, 5 und 6 identisch, jedoch markiert Subversion die
Arbeitskopie von Makefile
mit Revision 6,
um zu zeigen, dass es noch aktuell ist. Wenn Sie also ein
sauberes Update von der Wurzel Ihrer Arbeitskopie her machen,
sollte sie im Allgemeinen genau einer Revision im Projektarchiv
entsprechen.
Für jede Datei eines Arbeitsverzeichnis merkt sich
Subversion zwei essentielle Informationen im
.svn/
-Verwaltungsbereich:
Auf welcher Revision Ihre Arbeitsdatei aufbaut (das wird die Arbeitsrevision der Datei genannt)
Ein Zeitstempel, der festhält, wann die lokale Kopie das letzte Mal vom Projektarchiv aktualisiert wurde.
Mit diesen Informationen kann Subversion durch Kommunikation mit dem Projektarchiv feststellen, in welchem der folgenden Zustände sich eine Arbeitsdatei befindet:
Die Datei im Arbeitsverzeichnis ist unverändert, und keinerlei Änderungen an der Datei sind seit der Arbeitsrevision an das Projektarchiv übergeben worden. Ein svn commit der Datei würde nichts machen, und ein svn update der Datei auch nicht.
Die Datei wurde im Arbeitsverzeichnis geändert, und keinerlei Änderungen an der Datei sind seit der letzten Aktualisierung an das Projektarchiv übergeben worden. Es gibt lokale Änderungen, die noch nicht an das Projektarchiv übergeben worden sind, so dass ein svn commit der Datei Ihre Änderungen erfolgreich veröffentlichen würde, und ein svn update der Datei nichts tun würde.
Die Datei wurde im Arbeitsverzeichnis nicht geändert, jedoch im Projektarchiv. Die Datei sollte aktualisiert werden, damit sie bezüglich der letzten öffentlichen Revision aktuell ist. Ein svn commit der Datei würde nichts machen, und ein svn update der Datei würde die letzten Änderungen in Ihre Arbeitskopie einbringen.
Die Datei wurde sowohl im Arbeitsverzeichnis als auch im Projektarchiv geändert. Ein svn commit der Datei würde mit einem „out-of-date“ Fehler abbrechen. Die Datei sollte erst aktualisiert werden; ein svn update Befehl würde versuchen, die öffentlichen mit den lokalen Änderungen zusammenzuführen. Wenn Subversion diese Zusammenführung nicht plausibel automatisch durchführen kann, wird die Auflösung des Konflikts dem Benutzer überlassen.
Das hört sich an, als müsse man jede Menge mitverfolgen, aber der svn status Befehl zeigt Ihnen den Zustand jedes Objektes in Ihrer Arbeitskopie. Weitergehende Informationen zu diesem Befehl finden Sie unter „Verschaffen Sie sich einen Überblick über Ihre Änderungen“.
Als allgemeingültiges Prinzip versucht Subversion, so flexibel wie möglich zu sein. Eine besondere Ausprägung der Flexibilität ist die Fähigkeit, eine Arbeitskopie bestehend aus Dateien und Verzeichnissen mit einer Mischung unterschiedlicher Revisionsnummern zu haben. Unglücklicherweise neigt diese Flexibilität dazu, eine Anzahl neuer Benutzer zu verwirren. Wenn Sie das vorangegangene Beispiel, das gemischte Revisionen vorgestellt hat, verwirrte, zeigen wir hier eine Einführung warum es diese Möglichkeit gibt und wie sie verwendet wird.
Eine der grundlegenden Regeln von Subversion ist, dass eine Aktion, die in das Projektarchiv schreibt keine Aktion zur Folge hat, die aus dem Projektarchiv liest und umgekehrt. Wenn Sie bereit sind, neue Änderungen an das Projektarchiv zu übergeben, heißt das noch lange nicht, dass Sie auch die Änderungen anderer haben möchten. Und wenn Sie noch an Änderungen arbeiten, sollte svn update elegant die Änderungen aus dem Projektarchiv mit Ihren Änderungen zusammenführen anstatt Sie dazu zu zwingen, Ihre Änderungen zu veröffentlichen.
Der hauptsächliche Nebeneffekt dieser Regel ist, dass eine Arbeitskopie zusätzlich buchhalten muss, um sowohl gemischte Revisionen zu verfolgen als auch diese Mischung vertragen zu können. Die Tatsache, dass auch Verzeichnisse selbst versioniert sind, verkompliziert die Sache nur.
Nehmen wir zum Beispiel an, Ihre Arbeitskopie besteht
komplett aus Revision 10. Sie bearbeiten die Datei
foo.html
und führen ein svn
commit aus, das die Revision 15 im Projektarchiv
erzeugt. Nach dem erfolgreichen Commit würden viele neue
Benutzer erwarten, dass die gesamte Arbeitskopie auf
Revision 15 stehe, was aber nicht der Fall ist! Alle
möglichen Änderungen können sich zwischen Revision 10 und 15
im Projektarchiv zugetragen haben. Der Client weiß nichts über
diese Änderungen im Projektarchiv, da Sie noch nicht
svn update aufgerufen haben, und
svn commit zieht keine Änderungen herein.
Wenn andererseits svn commit automatisch
Änderungen hereinziehen würde, könnte die gesamte
Arbeitskopie auf Revision 15 gebracht werden – doch dann
wäre die grundlegende Regel verletzt, dass Lesen und
Schreiben getrennte Aktionen sind. Deshalb ist das einzig
Sichere, das der Subversion-Client tun kann, die eine
Datei – foo.html
– als zur
Revision 15 gehörig zu kennzeichnen. Der Rest der
Arbeitskopie verbleibt bei Revision 10. Nur durch
svn update können die neuesten Änderungen
hereingezogen und die gesamte Arbeitskopie als
Revision 15 gekennzeichnet werden.
Tatsache ist, dass jedes Mal wenn
Sie svn commit aufgerufen haben, die
Arbeitskopie aus irgendeiner Mischung von Revisionen
besteht. Die Sachen, die Sie eben ins Projektarchiv gebracht
haben, werden mit höheren Revisionsnummern gekennzeichnet
als alles andere. Nach einigen Commits (ohne
zwischenzeitliche Updates) ist Ihre Arbeitskopie eine
Riesenmischung von Revisionen. Selbst wenn Sie die einzige
Person sind, die das Projektarchiv benutzt, werden sie dieses
Phänomen bemerken. Um Ihre Mischung aus Arbeitsrevisionen
untersuchen zu können, verwenden Sie den Befehl svn
status mit der --verbose
-Option
(siehe „Verschaffen Sie sich einen Überblick über Ihre
Änderungen“ für
weitergehende Informationen).
Oft ist neuen Benutzern überhaupt nicht bewusst, das ihre Arbeitskopie gemischte Revisionen beinhaltet. Das kann zur Verwirrung führen, weil viele Client-Programme empfindlich auf die Revision des Objektes reagieren, das sie untersuchen. Beispielsweise wird der svn log-Befehl verwendet, um die Historie der Änderungen einer Datei oder eines Verzeichnisses darzustellen (siehe „Erzeugung einer Liste der Änderungsgeschichte“). Wenn der Benutzer diesen Befehl auf ein Objekt in der Arbeitskopie anwendet, erwartet er, die gesamte Historie des Objektes zu sehen. Wenn jedoch die Arbeitsrevision des Objektes ziemlich alt ist (oftmals weil lange Zeit kein svn update aufgerufen wurde), wird die Historie der älteren Version des Objekts angezeigt.
Wenn Ihr Projekt hinreichend komplex ist, werden Sie entdecken, dass es manchmal ganz nett sein kann, Teile Ihrer Arbeitskopie zurückzudatieren (oder auf eine ältere Version als die vorliegende zu aktualisieren); wie das gemacht wird, wird in Kapitel 2, Grundlegende Benutzung gezeigt. Vielleicht möchten Sie eine ältere Version eines Teilmoduls in einem Unterverzeichnis testen, oder Sie möchten herausbekommen, wann ein Fehler das erste Mal in einer Datei auftauchte. Dies ist der „Zeitmaschinen“-Aspekt eines Versionskontrollsystems – die Eigenschaft, die es ermöglicht, irgendeinen Teil Ihrer Arbeitskopie zeitlich nach vorne oder nach hinten zu verschieben.
Wie auch immer Sie gemischte Revisionen in Ihrer Arbeitskopie verwenden, diese Flexibilität hat ihre Grenzen.
Erstens kann die Löschung einer Datei oder eines Verzeichnisses nicht an das Projektarchiv übergeben werden, wenn die Datei oder das Verzeichnis nicht ganz aktuell ist. Falls eine neuere Version im Projektarchiv existiert, wird Ihr Löschversuch abgelehnt, um zu vermeiden, dass Sie versehentlich Änderungen löschen, die Sie noch nicht gesehen haben.
Zweitens können Sie keine Änderungen an Metadaten eines Verzeichnisses an das Projektarchiv übergeben, wenn das Verzeichnis nicht ganz aktuell ist. In Kapitel 3, Fortgeschrittene Themen werden Sie lernen, wie man „Eigenschaften“ an Objekte hängt. Die Arbeitskopie eines Verzeichnisses definiert eine bestimmte Menge von Einträgen und Eigenschaften, so dass eine Eihgenschafts-Änderung an einem veralteten Verzeichnis Eigenschaften zerstören kann, die Sie noch nicht gesehen haben.