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.
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.
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.
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“).
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.
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.