An dieser Stelle sollten Sie verstehen, wie jede Übergabe an das Projektarchiv dort einen neuen Zustand des Dateibaums (genannt „Revision“) erzeugt. Wenn nicht, blättern Sie zurück und lesen Sie in „Revisionen“ über Revisionen nach.
Lassen Sie uns noch einmal auf das Beispiel aus
Kapitel 1, Grundlegende Konzepte zurückkommen. Erinnern Sie sich,
dass Sie und Ihre Mitarbeiterin Sally sich ein Projektarchiv
teilen, das zwei Projekte beinhaltet: paint
und calc. Beachten Sie, dass in Abbildung 4.2, „Projektarchiv-Struktur zu Beginn“ dieses Mal jedoch
jedes Projektverzeichnis Unterverzeichnisse namens
trunk und branches
beinhaltet. Der Grund hierfür wird bald klar sein.
Wie bereits vorher sei hier angenommen, dass sowohl Sally
als auch Sie Arbeitskopien des Projektes „calc“
besitzen. Ausdrücklich hat jeder von Ihnen eine Arbeitskopie von
/calc/trunk. Alle Dateien des Projektes
befinden sich in diesem Unterverzeichnis statt in
/calc selber, da Ihr Team entschieden hat,
dass in /calc/trunk die
„Hauptlinie“ der Entwicklung stattfindet.
Sagen wir mal, dass Sie die Aufgabe bekommen haben, ein
großes Stück Software umzusetzen. Die Erstellung benötigt eine
lange Zeit und berührt alle Dateien im Projekt. Das Problem,
dass sofort auftaucht ist, dass Sie Sally nicht in die Quere
kommen möchten, die gerade hier und da kleinere Fehler
beseitigt. Sie ist davon abhängig, dass die letzte Version des
Projektes (in /calc/trunk) stets benutzbar
ist. Wenn Sie nun damit beginnen, Stück für Stück Ihre
Änderungen zu übergeben, werden Sie die Dinge für Sally (und
auch für andere Teammitglieder) bestimmt in Unordnung
bringen.
Eine Strategie ist, sich in ein Loch zu verkriechen: Sie können für eine Woche oder zwei den Informationsaustausch einstellen, und die Dateien Ihrer Arbeitskopie ausräumen und umorganisieren, ohne Änderungen zu übergeben oder die Arbeitskopie zu aktualisieren, bevor Sie mit Ihrer Arbeit vollständig fertig sind. Das wirft allerdings einige Probleme auf. Erstens ist das nicht sehr sicher. Falls Ihrer Arbeitskopie oder Ihrem Rechner etwas Schlimmes zustoßen sollte, riskieren Sie, alle Ihre Änderungen zu verlieren. Zweitens ist es nicht sehr flexibel. Falls Sie Ihre Änderungen nicht manuell über mehrere Arbeitskopien oder Rechner abgleichen, müssen Sie Ihre Änderungen in einer einzigen Arbeitskopie vornehmen. Ebenso schwierig wäre es, Ihre Änderungen mit anderen zu teilen. Eine weit verbreitete „beste Vorgehensweise“ ist es, Ihren Mitarbeitern zu erlauben, Ihre bisherigen Ergebnisse zu überprüfen, während Sie mit Ihrer Arbeit fortfahren. Wenn niemand Ihre unmittelbaren Änderungen sieht, haben Sie keine möglichen Rückmeldungen und es könnte sein, dass Sie für Wochen einen falschen Weg einschlagen, bevor es jemand aus Ihrem Team bemerkt. Schließlich könnte es am Ende sehr schwierig sein, Ihr Arbeitsergebnis wieder mit dem Hauptteil der Quelltexte Ihrer Firma zusammenzuführen, wenn Sie mit Ihren Änderungen fertig sind. Sally (und andere) hätten viele andere Änderungen ins Projektarchiv übergeben haben können, die sich schwer in Ihre Arbeitskopie einarbeiten lassen, wenn Sie schließlich nach Wochen der Isolierung svn update ausführen.
Die bessere Lösung ist es, Ihren eigenen Zweig oder Ihre eigene Entwicklungslinie im Projektarchiv zu erzeugen. Dies erlaubt Ihnen, Ihre unvollständigen Arbeitsergebnisse regelmäßig zu sichern, ohne die Änderungen anderer zu stören; dennoch können Sie selektiv Informationen mit Ihren Kollegen teilen. Im Weiteren werden Sie sehen, wie das funktioniert.
Es ist sehr einfach, einen Zweig zu erzeugen – Sie
erstellen mit dem Befehl svn copy eine
Kopie des Projekt-Baumes im Projektarchiv. Da der Quelltext
Ihres Projektes seine Wurzel im Verzeichnis
/calc/trunk hat, werden Sie diese
Verzeichnis kopieren. Wo soll die neue Kopie angelegt werden?
Wohin Sie wünschen. Der Ort im Projektarchiv, in dem Zweige
gespeichert werden sollen, wird von Subversion den
Projektrichtlinien überlassen. Schließlich benötigt Ihr Zweig
noch einen Namen, um ihn von anderen Zweigen zu unterscheiden.
Auch diesmal ist der Name, den Sie wählen, für Subversion
unwichtig – Sie können einen Namen verwenden, der am
besten für Sie und Ihr Team geeignet ist.
Nehmen wir an, dass Ihr Team (wie die meisten) die
Konvention vereinbart hat, Zweige im Verzeichnis
branches zu erzeugen, das ein
Geschwister-Verzeichnis des Projekt-Stamms ist (in unserem
Szenario das Verzeichnis /calc/branches).
Aus Mangel an Phantasie wählen Sie als Namen für Ihren Zweig
my-calc-branch. Das heißt, sie legen ein
neues Verzeichnis
/calc/branches/my-calc-branch an, das als
Kopie von /calc/trunk beginnt.
Sie haben vielleicht schon gesehen, wie mit svn copy innerhalb einer Arbeitskopie eine Datei auf eine andere kopiert wird. Es kann allerdings auch verwendet werden, um eine entfernte Kopie durchzuführen: eine Kopie die unmittelbar eine neue Revision des Projektarchivs zur Folge hat, und für die überhaupt keine Arbeitskopie notwendig ist. Kopieren Sie einfach einen URL auf einen anderen:
$ svn copy http://svn.example.com/repos/calc/trunk \
http://svn.example.com/repos/calc/branches/my-calc-branch \
-m "Privaten Zweig von /calc/trunk angelegt."
Revision 341 übertragen.
$
Dieser Befehl bewirkt eine fast sofortige Übergabe im
Projektarchiv, wobei in Revision 341 ein neues Verzeichnis
erzeugt wird. Das neue Verzeichnis ist eine Kopie von
/calc/trunk. Dies wird in Abbildung 4.3, „Projektarchiv mit neuer Kopie“ gezeigt.
[27]
Obwohl es auch möglich ist, einen Zweig zu erzeugen, indem
svn copy verwendet wird, um ein Verzeichnis
innerhalb der Arbeitskopie zu duplizieren, wird dieses
Vorgehen nicht empfohlen. Es kann in der Tat sehr langsam
sein! Das client-seitige Kopieren eines Verzeichnisses besitzt
einen linearen Zeitaufwand, da wirklich jede Datei und jedes
Verzeichnis innerhalb dieser Arbeitskopie auf der lokalen
Platte dupliziert werden muss. Das Kopieren eines
Verzeichnisses auf dem Server jedoch besitzt einen konstanten
Zeitaufwand und ist die Art und Weise, auf die die meisten
Leute Zweige erstellen.
Da Sie nun einen Zweig des Projektes erzeugt haben, können Sie eine neue Arbeitskopie auschecken, um ihn zu benutzen:
$ svn checkout http://svn.example.com/repos/calc/branches/my-calc-branch A my-calc-branch/Makefile A my-calc-branch/integer.c A my-calc-branch/button.c Ausgecheckt, Revision 341. $
An dieser Arbeitskopie ist nichts besonders; sie spiegelt
bloß ein anderes Verzeichnis im Projektarchiv wider. Wenn Sie
Änderungen übergeben, wird sie Sally jedoch nicht sehen, wenn
sie aktualisiert, da sie eine Arbeitskopie von
/calc/trunk hat. (Stellen Sie sicher,
dass Sie „Zweige durchlaufen“ weiter
unten in diesem Kapitel lesen: Der Befehl svn
switch ist eine Alternative für die Bereitstellung
einer Arbeitskopie eines Zweiges.)
Tun wir mal so, als ob eine Woche ins Land geht und die folgenden Übergaben stattfinden:
-
Sie machen eine Änderung an
/calc/branches/my-calc-branch/button.c, die die Revision 342 erzeugt. -
Sie machen eine Änderung an
/calc/branches/my-calc-branch/integer.c, die die Revision 343 erzeugt. -
Sally macht eine Änderung an
/calc/trunk/integer.c, die die Revision 344 erzeugt.
Nun finden zwei unabhängige Entwicklungslinien (siehe
Abbildung 4.4, „Die Verzweigung der Geschichte einer Datei“) auf
integer.c statt.
Es wird interessant, wenn Sie die Geschichte der
Änderungen an Ihrer Kopie von integer.c
betrachten:
$ pwd /home/user/my-calc-branch $ svn log -v integer.c ------------------------------------------------------------------------ r343 | user | 2002-11-07 15:27:56 -0600 (Do, 07. Nov 2002) | 2 Zeilen Geänderte Pfade: M /calc/branches/my-calc-branch/integer.c * integer.c: Wazjub gefrozzelt. ------------------------------------------------------------------------ r341 | user | 2002-11-03 15:27:56 -0600 (Do, 07. Nov 2002) | 2 Zeilen Geänderte Pfade: A /calc/branches/my-calc-branch (from /calc/trunk:340) Privaten Zweig von /calc/trunk angelegt. ------------------------------------------------------------------------ r303 | sally | 2002-10-29 21:14:35 -0600 (Di, 29. Okt 2002) | 2 Zeilen Geänderte Pfade: M /calc/trunk/integer.c * integer.c: Einen Docstring geändert. ------------------------------------------------------------------------ r98 | sally | 2002-02-22 15:35:29 -0600 (Fr, 22. Feb 2002) | 2 Zeilen Geänderte Pfade: A /calc/trunk/integer.c * integer.c: Diese Datei dem Projekt hinzugefügt. ------------------------------------------------------------------------
Beachten Sie, dass Subversion die Geschichte von
integer.c auf Ihrem Zweig über die
gesamte Zeit zurück verfolgt, und dabei sogar über den Punkt
hinweg geht, an dem es kopiert wurde. Es zeigt die Erzeugung
des Zweigs als ein Ereignis in der Geschichte, da
integer.c implizit kopiert wurde, als
alles andere in /calc/trunk/ kopiert
wurde. Sehen Sie nun, was passiert, wenn Sally den gleichen
Befehl auf Ihre Arbeitskopie der Datei anwendet:
$ pwd /home/sally/calc $ svn log -v integer.c ------------------------------------------------------------------------ r344 | sally | 2002-11-07 15:27:56 -0600 (Do, 07. Nov 2002) | 2 Zeilen Changed paths: M /calc/trunk/integer.c * integer.c: Ein paar Rechtschreibfehler behoben. ------------------------------------------------------------------------ r303 | sally | 2002-10-29 21:14:35 -0600 (Di, 29. Okt 2002) | 2 Zeilen Changed paths: M /calc/trunk/integer.c * integer.c: Einen Docstring geändert. ------------------------------------------------------------------------ r98 | sally | 2002-02-22 15:35:29 -0600 (Fr, 22. Feb 2002) | 2 Zeilen Changed paths: A /calc/trunk/integer.c * integer.c: Diese Datei dem Projekt hinzugefügt. ------------------------------------------------------------------------
Sally sieht ihre eigene Änderung in Revision 344, aber nicht die Änderung, die Sie in Revision 343 gemacht haben. Was Subversion angeht, hatten diese beiden Übergaben Auswirkungen auf unterschiedliche Dateien an unterschiedlichen Stellen im Projektarchiv. Gleichwohl zeigt Subversion, dass die beiden Dateien einen Teil der Geschichte gemeinsam haben. Bevor die Kopie des Zweiges in Revision 341 gemacht wurde, waren die Dateien dieselbe Datei. Deshalb sehen sowohl Sie als auch Sally die Änderungen, die in den Revisionen 303 und 98 gemacht wurden.
Sie sollten sich zwei Lektionen aus diesem Abschnitt merken. Erstens besitzt Subversion kein internes Konzept für einen Zweig – es weiß lediglich, wie Kopien angelegt werden. Wenn Sie ein Verzeichnis kopieren, ist das entstehende Verzeichnis bloß ein „Zweig“, weil Sie ihm diese Bedeutung geben. Sie mögen über das Verzeichnis anders denken oder es anders behandeln, doch für Subversion ist es einfach ein gewöhnliches Verzeichnis, das nebenbei mit einigen zusätzlichen historischen Informationen ausgestattet ist.
Zweitens bestehen die Zweige von Subversion, bedingt durch
den Kopiermechanismus, als normale
Dateisystemverzeichnisse im Projektarchiv. Das ist ein
Unterschied zu anderen Versionskontrollsystemen, bei denen
Zweige typischerweise definiert werden, indem auf einer
eigenen Ebene den Dateisammlungen „Etiketten“
hinzugefügt werden. Der Ort Ihres Zweig-Verzeichnisses spielt
für Subversion keine Rolle. Die meisten Teams folgen der
Konvention, alle Zweige in einem Verzeichnis namens
/branches abzulegen, jedoch steht es
Ihnen frei, eine Vorgehensweise nach Ihren Wünschen zu
erfinden.
[27] Subversion unterstützt nicht das Kopieren zwischen verschiedenen Projektarchiven. Wenn Sie mit svn copy oder svn move URLs verwenden, können Sie nur Objekte innerhalb desselben Projektarchivs kopieren oder verschieben.