Dieser Text befindet sich gegenwärtig in Bearbeitung, unterliegt ständigen Änderungen und kann dadurch nicht stets akkurat irgendeine freigegebene Version der Software Apache™ Subversion® beschreiben. Das Speichern dieser Seite als Lesezeichen oder andere auf diese Seite zu verweisen, ist keine so gute Idee. Besuchen Sie http://www.svnbook.com/, um stabile Versionen dieses Buchs zu erhalten.

Verwenden von Zweigen

An dieser Stelle sollten Sie ein Verständnis haben, 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.

Abbildung 4.2. Projektarchiv-Struktur zu Beginn

Projektarchiv-Struktur zu Beginn

Wie vorher sei hier angenommen, dass sowohl Sally als auch Sie Arbeitskopien des Projektes calc besitzen. Genauer gesagt, 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.

Nehmen wir an, Sie haben die Aufgabe bekommen, einen großen Teil einer Software umzusetzen. Die Erstellung benötigt einen langen Zeitraum 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. Sallys Arbeit hängt davon ab, 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 übertragen, werden Sie die Dinge für Sally (und auch für andere Teammitglieder) bestimmt in Unordnung bringen.

Eine Strategie wäre es, 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 übertragen 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, wenn Sie mit Ihren Änderungen fertig sind, sehr schwierig sein, Ihr Arbeitsergebnis wieder mit dem Hauptteil der Quelltexte Ihrer Firma zusammenzuführen. Sally (und andere) hätten viele andere Änderungen ins Projektarchiv übertragen 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.

Erzeugen eines Zweiges

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? Wo 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 von Ihnen gewählte Name 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) vereinbart hat, Zweige im Verzeichnis branches zu erzeugen, das ein Geschwister-Verzeichnis des Projekt-Stamms (Trunk) 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 Kopie aus der Ferne 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 ^/calc/trunk ^/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. [34] 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. Zusätzlich eröffnet diese Vorgehensweise die Möglichkeit, Arbeitskopien mit gemischten Revisionen zu kopieren. Das ist nicht von Natur aus gefährlich, kann jedoch später beim Zusammenführen zu unnötigen Komplikationen führen. Falls Sie sich entscheiden, einen Zweig über eine Kopie eines Pfades der Arbeitskopie zu erstellen, sollten Sie sicherstellen, dass das Quellverzeichnis weder lokale Änderungen noch gemischte Revisionen hat.

Abbildung 4.3. Projektarchiv mit neuer Kopie

Projektarchiv mit neuer Kopie

Arbeiten mit Ihrem Zweig

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/doc
A    my-calc-branch/src
A    my-calc-branch/doc/INSTALL
A    my-calc-branch/src/real.c
A    my-calc-branch/src/main.c
A    my-calc-branch/src/button.c
A    my-calc-branch/src/integer.c
A    my-calc-branch/Makefile
A    my-calc-branch/README
Ausgecheckt, Revision 341.
$

An dieser Arbeitskopie ist nichts besonders; sie spiegelt bloß ein anderes Verzeichnis im Projektarchiv wider. Wenn Sie Änderungen übertragen, 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/src/button.c, die die Revision 342 erzeugt.

  • Sie machen eine Änderung an /calc/branches/my-calc-branch/src/integer.c, die die Revision 343 erzeugt.

  • Sally macht eine Änderung an /calc/trunk/src/integer.c, die die Revision 344 erzeugt.

Nun hat integer.c zwei unabhängige Entwicklungslinien (siehe Abbildung 4.4, „Die Verzweigung der Geschichte einer Datei“).

Abbildung 4.4. Die Verzweigung der Geschichte einer Datei

Die Verzweigung der Geschichte einer Datei

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 src/integer.c
------------------------------------------------------------------------
r343 | user | 2013-02-15 14:11:09 -0500 (Fr, 15. Feb 2013) | 1 Zeile
Geänderte Pfade:
   M /calc/branches/my-calc-branch/src/integer.c

* integer.c:  Wazjub gefrozzelt.
------------------------------------------------------------------------
r341 | user | 2013-02-15 07:41:25 -0500 (Fr, 15. Feb 2013) | 1 Zeile
Geänderte Pfade:
   A /calc/branches/my-calc-branch (from /calc/trunk:340)

Privaten Zweig von /calc/trunk angelegt.
------------------------------------------------------------------------
r154 | sally | 2013-01-30 04:20:03 -0500 (Mi, 30. Jan 2013) | 2 Zeilen
Geänderte Pfade:
   M /calc/trunk/src/integer.c

* integer.c:  Einen Docstring geändert.
------------------------------------------------------------------------
r113 | sally | 2013-01-26 15:50:21 -0500 (Sa, 26. Jan 2013) | 2 Zeilen
Geänderte Pfade:
   A /calc/trunk/src/integer.c

* integer.c:  Die fooplus API überarbeitet.
------------------------------------------------------------------------
r8 | sally | 2013-01-17 16:55:36 -0500 (Do, 17. Jan 2013) | 1 Zeile
Geänderte Pfade:
   A /calc/trunk/Makefile
   A /calc/trunk/README
   A /calc/trunk/doc/INSTALL
   A /calc/trunk/src/button.c
   A /calc/trunk/src/integer.c
   A /calc/trunk/src/main.c
   A /calc/trunk/src/real.c

Ursprünglicher Calc Projekt Quelltext-Import von trunk.
------------------------------------------------------------------------

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 er kopiert wurde. Es zeigt die Erzeugung des Zweigs als ein Ereignis in der Geschichte, da integer.c implizit kopiert wurde, als alles andere aus /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 src/integer.c
------------------------------------------------------------------------
r344 | sally | 2013-02-15 16:44:44 -0500 (Fr, 15. Feb 2013) | 1 Zeile
Changed paths:
   M /calc/trunk/src/integer.c

Die bazzle Funktionen refaktoriert.
------------------------------------------------------------------------
r154 | sally | 2013-01-30 04:20:03 -0500 (Mi, 30. Jan 2013) | 2 Zeilen
Changed paths:
   M /calc/trunk/src/integer.c

* integer.c:  Einen Docstring geändert.
------------------------------------------------------------------------
r113 | sally | 2013-01-26 15:50:21 -0500 (Sa, 26. Jan 2013) | 2 Zeilen
Changed paths:
   A /calc/trunk/src/integer.c

* integer.c:  Die fooplus API überarbeitet.

------------------------------------------------------------------------
r8 | sally | 2013-01-17 16:55:36 -0500 (Do, 17. Jan 2013) | 1 Zeile
Changed paths:
   A /calc/trunk/Makefile
   A /calc/trunk/README
   A /calc/trunk/doc/INSTALL
   A /calc/trunk/src/button.c
   A /calc/trunk/src/integer.c
   A /calc/trunk/src/main.c
   A /calc/trunk/src/real.c

Ursprünglicher Calc Projekt Quelltext-Import von trunk.
------------------------------------------------------------------------

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 zwischen den Revisionen 8 und 154 gemacht wurden.

Die Schlüsselkonzepte des Verzweigens

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 versehen ist.

Zweitens bestehen die Zweige von Subversion, bedingt durch den Kopiermechanismus, als normale Dateisystemverzeichnisse im Projektarchiv. Das ist ein Unterschied zu anderen Versions-Kontroll-Systemen, 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.



[34] Subversion unterstützt nicht das Kopieren zwischen unterschiedlichen Projektarchiven. Wenn Sie mit svn copy oder svn move URLs verwenden, können Sie nur Objekte innerhalb desselben Projektarchivs kopieren oder verschieben.