Diese Dokumentation wurde zur Beschreibung der Serie 1.6.x von Subversion erstellt. Falls Sie eine unterschiedliche Version von Subversion einsetzen, sei Ihnen dringend angeraten, bei http://www.svnbook.com/ vorbeizuschauen und stattdessen die zu Ihrer Version von Subversion passende Version dieser Dokumentation heranzzuiehen.

Der grundlegende Arbeitszyklus

Subversion hat zahlreiche Features, Optionen und noch jede Menge Schnickschnack, aber für die tägliche Arbeit ist die Wahrscheinlichkeit groß, nur wenig davon zu benutzen. In diesem Abschnitt gehen wir durch die gebräuchlichsten Dinge, die Sie während des Tagesgeschäftes mit Subversion machen werden.

Der typische Arbeitszyklus sieht so aus:

  1. Aktualisieren Sie Ihre Arbeitskopie. Das bedingt die Verwendung des Befehls svn update.

  2. Nehmen Sie Ihre Änderungen vor. Die häufigsten Änderungen, die Sie machen werden, sind Bearbeitungen des Inhalts Ihrer bestehenden Dateien. Doch manchmal müssen Sie Dateien und Verzeichnisse hinzufügen, entfernen und verschieben – die Befehle svn add, svn delete, svn copy sowie svn move bewerkstelligen derartige strukturelle Änderungen in der Arbeitskopie.

  3. Überprüfen Sie Ihre Änderungen. Die Befehle svn status und svn diff sind entscheidend beim Überprüfen der von Ihnen in der Arbeitskopie vorgenommenen Änderungen.

  4. Beheben Sie Ihre Fehler. Niemand ist vollkommen, und so kann es passieren, dass Sie beim Überprüfen Ihrer Änderungen etwas entdecken, was nicht richtig ist. Manchmal ist es am einfachsten, einfach erneut von vorne zu beginnen. Der Befehl svn revert stellt den ungeänderten Zustand einer Datei oder eines Verzeichnisses wieder her.

  5. Lösen Sie etwaige Konflikte auf (arbeiten Sie die Änderungen anderer ein). Während der Zeit, die Sie benötigen, um Änderungen vorzunehmen und zu überprüfen, hätten andere ebenfalls Änderungen machen und sie veröffentlichen können. Sie sollten deren Änderungen in Ihre Arbeitskopie integrieren, um Szenarien bedingt durch Veralterung zu vermeiden, die möglicherweise entstehen, wenn Sie Ihre Änderungen veröffentlichen wollen. Auch hier hilft Ihnen der Befehl svn update weiter. Sollte das zu lokalen Konflikten führen, müssen Sie jene mithilfe des Befehls svn resolve auflösen.

  6. Veröffentlichen (übergeben) Sie Ihre Änderungen. Der Befehl svn commit überträgt Ihre Änderungen in das Projektarchiv, in dem sie, falls sie angenommen werden, die neueste Version aller Dinge erstellen, die Sie modifiziert haben. Nun können auch andere Ihre Arbeit sehen.

Aktualisieren Sie Ihre Arbeitskopie

Wenn Sie in einem Projekt arbeiten, das über mehrere Arbeitskopien modifiziert wird, sollten Sie Ihre Arbeitskopie aktualisieren, damit Sie die Änderungen aus anderen Arbeitskopien seit Ihrer letzten Aktualisierung mitbekommen. Es kann sich dabei um Änderungen handeln, die andere Mitarbeiter aus dem Team gemacht haben, oder aber Änderungen, die Sie selbst von einem anderen Computer gemacht haben. Um Ihre Daten zu schützen, erlaubt es Ihnen Subversion nicht, neue Änderungen auf veraltete Dateien und Verzeichnisse anzuwenden, so dass Sie am besten die neuesten Versionen aller Ihrer Projektdateien und -verzeichnisse haben, bevor Sie selbst irgendwelche Änderungen vornehmen.

Verwenden Sie svn update, um Ihre Arbeitskopie mit der letzten Revision im Projektarchiv zu synchronisieren:

$ svn update
U    foo.c
U    bar.c
Aktualisiert zu Revision 2.

In diesem Fall sieht es so aus, dass jemand Änderungen sowohl an foo.c als auch an bar.c übergeben hat, seit Sie das letzte Mal aktualisiert haben, und Subversion hat Ihre Arbeitskopie aktualisiert, damit sie beide Änderungen enthält.

Wenn der Server über svn update Änderungen an Ihre Arbeitskopie schickt, wird ein Buchstabencode neben jedem Objekt angezeigt, um Ihnen anzuzeigen, was Subversion gemacht hat, um die Arbeitskopie auf den neuesten Stand zu bringen. Zur Bedeutung der Buchstaben, rufen Sie svn help update auf oder schauen sich svn update (up) an.

Nehmen Sie Ihre Änderungen vor

Nun können Sie loslegen und Änderungen an Ihrer Arbeitskopie vornehmen. Sie können zwei Arten von Änderungen an Ihrer Arbeitskopie machen: Dateiänderungen und Baumänderungen. Sie brauchen Subversion nicht mitteilen, dass Sie beabsichtigen, eine Datei zu ändern; machen Sie einfach Ihre Änderungen mit Ihrem Editor, Textverarbeitungsprogramm, Grafikprogramm oder was Sie sonst normalerweise benutzen. Subversion merkt automatisch, welche Dateien verändert wurden; darüber hinaus behandelt es binäre Dateien ebenso einfach wie Textdateien – und ebenso effizient. Davon unterscheiden sich Baumänderungen, die Änderungen an der Verzeichnisstruktur nach sich ziehen. Zu solchen Änderungen zählen das Hinzufügen und Entfernen von Dateien, das Umbenennen von Dateien oder Verzeichnissen sowie das Kopieren von Dateien und Verzeichnissen an andere Orte. Für Baumänderungen verwenden Sie Subversion-Operationen, um Dateien und Verzeichnisse zum Löschen, Hinzufügen, Kopieren oder Verschieben einzuplanen. Diese Änderungen können sofort in Ihrer Arbeitskopie stattfinden, jedoch wird im Projektarchiv nichts hinzugefügt oder gelöscht bevor Sie die Änderungen übergeben haben.

Hier ist ein Überblick der fünf Subversion-Unterbefehle, die Sie am häufigsten benutzen werden, um Änderungen am Verzeichnisbaum vorzunehmen:

svn add FOO

Verwenden Sie diesen Befehl, um die Datei, das Verzeichnis oder den symbolischen Link FOO zum Hinzufügen in das Projektarchiv vormerken. Wenn Sie das nächste Mal übergeben, wird FOO ein Kind seines Elternverzeichnisses. Beachten Sie, dass alles unterhalb von FOO zum Hinzufügen vorgemerkt wird, falls FOO ein Verzeichnis ist. Falls Sie nur FOO selber hinzufügen möchten, geben Sie die Option --depth=empty an.

svn delete FOO

Verwenden Sie das, um die Datei, das Verzeichnis oder den symbolischen Link FOO zum Löschen aus dem Projektarchiv vormerken. FOO wird sofort aus der Arbeitskopie entfernt, falls es eine Datei oder ein Link ist. Falls FOO ein Verzeichnis ist, wird es nicht gelöscht, sondern zum Löschen vorgemerkt. Wenn Sie Ihre Änderungen übergeben, wird das gesamte Verzeichnis FOO aus der Arbeitskopie und dem Projektarchiv entfernt. [6]

svn copy FOO BAR

Erzeuge ein neues Objekt BAR als Duplikat von FOO und merke BAR automatisch zum Hinzufügen vor. Wird bei der nächsten Übergabe BAR dem Projektarchiv hinzugefügt, wird die Historie der Kopie mit aufgezeichnet (so wie sie ursprünglich in FOO war). svn copy erzeugt keine Zwischenverzeichnisse, sofern nicht die Option --parents angegeben wird..

svn move FOO BAR

Dieser Befehl macht genau das gleiche wie svn copy FOO BAR; svn delete FOO. D.h., BAR wird zum Hinzufügen als Kopie von FOO und FOO selbst zum Löschen vorgemerkt. svn move erzeugt keine Zwischenverzeichnisse, sofern nicht die Option --parents angegeben wird.

svn mkdir FOO

Dieser Befehl macht genau das gleiche wie mkdir FOO; svn add FOO. D.h., ein neues Verzeichnis namens FOO wird angelegt und zum Hinzufügen vorgemerkt.

Überprüfen Sie Ihre Änderungen

Sobald Sie mit Ihren Änderungen fertig sind, müssen Sie sie ins Projektarchiv bringen; es ist normalerweise eine gute Idee, sich die Änderungen zuvor noch einmal anzusehen. Dadurch, dass Sie die Änderungen noch einmal begutachten, können Sie eine genauere Protokollnachricht schreiben (eine menschenlesbare Beschreibung der übergebenen Änderungen, die neben ihnen im Projektarchiv gespeichert wird). Es könnte auch sein, dass Sie feststellen, versehentlich eine Datei geändert zu haben, und dass Sie vor der Übergabe diese Änderung rückgängig machen müssen. Zusätzlich bietet sich hierbei eine gute Gelegenheit, die Änderungen vor der Veröffentlichung noch einmal genau durchzugehen. Sie können sich mit svn status einen Überblick über Ihre Änderungen verschaffen und mit svn diff die Änderungen im Detail anzeigen lassen.

Verschaffen Sie sich einen Überblick über Ihre Änderungen

Um einen Überblick über Ihre Änderungen zu bekommen, verwenden Sie den Befehl svn status. Wahrscheinlich werden Sie den Befehl svn status häufiger benutzen als alle anderen Subversion-Befehle.

[Tipp] Tipp

Da die Ausgabe des Befehls cvs status so geräuschvoll war, und cvs update nicht nur eine Aktualisierung vornimmt sondern auch den Status Ihrer lokalen Änderungen meldet, haben sich die meisten Anwender von CVS angewöhnt, cvs update zum Anzeigen Ihrer Meldungen zu verwenden. In Subversion sind die Aktualisierungs- und Statusmeldefunktionen vollständig getrennt. Zu Details, siehe „Unterscheidung zwischen Status und Update“

Wenn Sie svn status ohne zusätzliche Argumente ganz oben in Ihrer Arbeitskopie aufrufen, erfasst und meldet es alle Datei- und Verzeichnisbaumänderungen, die Sie gemacht haben.

$ svn status
?       scratch.c
A       stuff/loot
A       stuff/loot/new.c
D       stuff/old.c
M       bar.c
$

In seinem Standard-Ausgabemodus zeigt svn status sieben Spalten mit Zeichen, gefolgt von mehreren Leerzeichen und einem Datei- oder Verzeichnisnamen an. Die erste Spalte gibt Aufschluss über den Zustand einer Datei oder eines Verzeichnisses und/oder des entsprechenden Inhalts. Einige der häufigsten Codes, die svn status anzeigt, sind:

? item

Die Datei, das Verzeichnis oder der symbolische Link item ist nicht unter Versionskontrolle.

A item

Die Datei, das Verzeichnis oder der symbolische Link item ist zum Hinzufügen in das Projektarchiv vorgemerkt.

C item

Die Datei item befindet sich in einem Konfliktzustand. D.h., Änderungen, die vom Server bei einer Aktualisierung empfangen wurden, überlappen sich mit lokalen Änderungen, die Sie in Ihrer Arbeitskopie haben (und konnten beim Aktualisieren nicht automatisch aufgelöst werden). Sie müssen den Konflikt auflösen, bevor Sie Ihre Änderungen in das Projektarchiv übergeben können.

D item

Die Datei, das Verzeichnis oder der symbolische Link item ist zum Löschen im Projektarchiv vorgemerkt.

M item

Der Inhalt der Datei item ist geändert worden.

Wenn Sie einen speziellen Pfad an svn status übergeben, bekommen Sie nur Informationen über dieses Objekt:

$ svn status stuff/fish.c
D       stuff/fish.c

svn status hat auch eine --verbose-Option (-v), die Ihnen den Zustand jedes Objektes in der Arbeitskopie anzeigt, selbst wenn es sich nicht geändert hat:

$ svn status -v
M               44        23    sally     README
                44        30    sally     INSTALL
M               44        20    harry     bar.c
                44        18    ira       stuff
                44        35    harry     stuff/trout.c
D               44        19    ira       stuff/fish.c
                44        21    sally     stuff/things
A                0         ?     ?        stuff/things/bloo.h
                44        36    harry     stuff/things/gloo.c

Dies ist das lange Format der Ausgabe von svn status. Die Buchstaben in der ersten Spalte bedeuten dasselbe wie vorher, jedoch zeigt die zweite Spalte die Arbeitsrevision des Objektes an. Die dritte und vierte Spalte zeigen die Revision der letzten Änderung an und wer es geändert hat.

Keiner der vorangegangenen Aufrufe von svn status stellt eine Verbindung zum Projektarchiv her – sie berichten lediglich, das, was über die Objekte in der Arbeitskopie aus den Aufzeichnungen im Verwaltungsbereich der Arbeitskopie hervorgeht, sowie aus den Zeitstempeln und dem Inhalt geänderter Dateien. Manchmal ist es jedoch dienlich, zu sehen, welche der Objekte in Ihrer Arbeitskopie seit Ihrer letzten Aktualisierung im Projektarchiv geändert wurden. Dafür bietet svn status die Option --show-updates (-u), die eine Verbindung zum Projektarchiv herstellt, und Informationen darüber bereitstellt, was nicht mehr aktuell ist:

$ svn status -u -v
M      *        44        23    sally     README
M               44        20    harry     bar.c
       *        44        35    harry     stuff/trout.c
D               44        19    ira       stuff/fish.c
A                0         ?     ?        stuff/things/bloo.h
  Status bezogen auf Revision:   46

Beachten Sie die zwei Sternchen im vorangegangenen Beispiel: Wenn Sie an dieser Stelle svn update aufrufen würden, erhielten Sie Änderungen an README und trout.c. Das gibt Ihnen einige sehr wichtige Informationen: Da eins dieser Objekte auch von Ihnen lokal geändert wurde (die Datei README) müssen Sie vor der Übergabe aktualisieren, um die Änderungen an README vom Server mitzubekommen, oder das Projektarchiv wird Ihre Übergabe ablehnen, da sie nicht aktuell ist. Wir werden das später detailliert erörtern

svn status kann viel mehr Informationen über Dateien und Verzeichnisse in Ihrer Arbeitskopie anzeigen als wir hier gezeigt haben – für eine erschöpfende Beschreibung von svn status und dessen Ausgabe, rufen Sie svn help status auf oder schauen Sie unter svn status (stat, st).

Untersuchen Sie die Details Ihrer lokalen Änderungen

Eine andere Möglichkeit, Ihre Änderungen zu untersuchen, ist es, den Befehl svn diff zu verwenden, der Unterschiede im Dateiinhalt anzeigt. Wenn Sie svn diff ganz oben in Ihrer Arbeitskopie ohne Argumente aufrufen, gibt Subversion die von Ihnen gemachten Änderungen an menschenlesbaren Dateien in Ihrer Arbeitskopie aus. Jene Änderungen werden in einem Format namens unified diff angezeigt, welches Änderungen als Brocken (oder Schnipsel) des Dateiinhalts anzeigt, wobei jeder Textzeile ein Zeichencode vorangestellt wird: ein Leerzeichen, das bedeutet, dass die Zeile nicht geändert wurde, ein Minus (-), das bedeutet, dass die Zeile aus der Datei entfernt wurde oder ein Plus (+), das bedeutet, dass die Zeile der Datei hinzugefügt wurde. Im Kontext des Befehls svn diff zeigen Ihnen diese Minus- und Pluszeilen, wie die Zeilen vor bzw. nach Ihren Änderungen aussahen.

Hier ein Beispiel:

$ svn diff
Index: bar.c
===================================================================
--- bar.c	(revision 3)
+++ bar.c	(working copy)
@@ -1,7 +1,12 @@
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <unistd.h>
+
+#include <stdio.h>

 int main(void) {
-  printf("Sixty-four slices of American Cheese...\n");
+  printf("Sixty-five slices of American Cheese...\n");
 return 0;
 }

Index: README
===================================================================
--- README	(revision 3)
+++ README	(working copy)
@@ -193,3 +193,4 @@
+Note to self:  pick up laundry.

Index: stuff/fish.c
===================================================================
--- stuff/fish.c	(revision 1)
+++ stuff/fish.c	(working copy)
-Welcome to the file known as 'fish'.
-Information on fish will be here soon.

Index: stuff/things/bloo.h
===================================================================
--- stuff/things/bloo.h	(revision 8)
+++ stuff/things/bloo.h	(working copy)
+Here is a new file to describe
+things about bloo.

Der Befehl svn diff erzeugt diese Ausgabe, indem er Ihre Arbeitsdateien mit den unveränderten Kopien in der Text-Base vergleicht. Dateien, die zum Hinzufügen vorgemerkt sind, werden vollständig als hinzugefügter Text dargestellt, und Dateien, die zum Löschen vorgemerkt sind, werden vollständig als gelöschter Text dargestellt. Die Ausgabe von svn diff ist kompatibel zum Programm patch. Das Programm patch liest und verwendet Patch-Dateien (oder Patches), wobei es sich um Dateien handelt, die Unterschiede an einer oder mehreren Dateien beschreiben. Daher können Sie die in Ihrer Arbeitskopie vorgenommenen Änderungen mit jemanden teilen, ohne die Änderungen erst übergeben zu müssen, indem Sie aus der umgeleiteten Ausgabe des Befehls svn diff eine Patch-Datei erzeugen:

$ svn diff > patchfile
$

Subversion verwendet seinen eingebauten diff-Algorithmus, der standardmäßig das unified-diff-Format benutzt. Falls Sie die Ausgabe von diff in einem anderen Format haben möchten, geben Sie ein externes diff-Programm mit der --diff-cmd-Option an, und übergeben Sie ihm beliebige Flags mit der Option --extensions (-x). Sie möchten beispielsweise, dass Subversion die Berechnung und Anzeige der Unterschiede an das GNU-Programm diff delegiert, wobei die lokalen Änderungen an der Datei foo.c im Kontext-Format ausgegeben (einer anderen Darstellung der Unterschiede) und Unterschiede in Groß- und Kleinschreibung des Dateiinhalts ignoriert werden:

$ svn diff --diff-cmd /usr/bin/diff -x "-i" foo.c
…
$

Beheben Sie Ihre Fehler

Angenommen, Sie stellen beim Ansehen der Ausgabe von svn diff fest, dass alle Änderungen, die Sie an einer bestimmten Datei gemacht haben, fehlerhaft waren. Vielleicht hätten Sie die Datei überhaupt nicht ändern sollen, oder es wäre einfacher, noch einmal bei Null anzufangen. Sie könnten die Datei erneut bearbeiten und alle Änderungen rückgängig machen. Sie könnten versuchen, eine Kopie der Datei im Ursprungszustand zu bekommen und deren Inhalt über Ihre Änderungen zu kopieren. Sie könnten versuchen, diese Änderungen erneut mit patch -R rückwärts anzuwenden. Es gibt wahrscheinlich noch andere Herangehensweisen, die Sie ausprobieren könnten.

In Subversion bedarf das Rückgängigmachen und bei Null anfangen glücklicherweise nicht derartiger Akrobatik. Verwenden Sie einfach den Befehl svn revert:

$ svn status README
M       README
$ svn revert README
Rückgängig gemacht: »README«
$ svn status README
$

In diesem Beispiel hat Subversion die Datei wieder so her, wie sie vor der Änderung war, indem sie mit der unveränderten Version der Datei aus dem Cache der Text-Base überschrieben wurde. Beachten Sie aber auch, dass svn revert jegliche vorgemerkten Operationen rückgängig machen kann – z.B. könnten Sie sich entscheiden, eine neue Datei erst gar nicht hinzufügen zu wollen:

$ svn status new-file.txt
?       new-file.txt
$ svn add new-file.txt
A         new-file.txt
$ svn revert new-file.txt
Rückgängig gemacht: »new-file.txt«
$ svn status new-file.txt
?       new-file.txt
$

Oder vielleicht haben Sie die Datei versehentlich aus der Versionsverwaltung gelöscht:

$ svn status README

$ svn delete README
D         README

$ svn revert README
Rückgängig gemacht: »README«

$ svn status README
$

Der Befehl svn revert bietet die Rettung für unvollkommene Menschen. Er kann Ihnen jede Menge Zeit und Energie einzusparen helfen, die ansonsten beim manuellen Rückgängigmachen entstanden wäre, oder noch schlimmer, wenn Sie Ihre Arbeitskopie durch eine frische hätten ersetzen müssen, um noch einmal neu anzufangen.

Lösen Sie etwaige Konflikte auf

Wir haben bereits gesehen, wie svn status -u Konflikte vorhersagen kann, jedoch müssen wir uns noch um diese Konflikte kümmern. Konflikte können jederzeit auftreten, wenn Sie versuchen, Änderungen aus dem Projektarchiv mit Ihrer Arbeitskopie zusammenzuführen oder zu integrieren (in einem sehr allgemeinen Sinn). Bis hierher wissen Sie, dass svn update genau diese Art von Szenario hervorruft – der eigentliche Zweck dieses Befehls ist es, Ihre Arbeitskopie mit dem Projektarchiv auf einen Stand zu bringen, indem alle Änderungen seit Ihrer letzten Aktualisierung mit Ihrer Arbeitskopie zusammengeführt werden. Wie teilt Ihnen Subversion nun diese Konflikte mit, und wie gehen Sie damit um?

Angenommen, Sie rufen svn update auf und sehen diese interessante Ausgabe:

$ svn update
U    INSTALL
G    README
Konflikt in »bar.c« entdeckt.
Auswahl: (p) zurückstellen, (df) voller Diff, (e) editieren,
         (mc) eigene konfliktbehaftete Datei, (tc) fremde konfliktbehaftete Datei,
         (s) alle Optionen anzeigen: 

Die Codes U und G sind kein Grund zur Beunruhigung; diese Dateien haben die Änderungen aus dem Projektarchiv sauber aufgenommen. Eine mit U markierte Datei enthält keine lokalen Änderungen, wurden jedoch mit Änderungen aus dem Projektarchiv aktualisiert. Eine mit G markierte Datei enthielt zwar lokale Änderungen, die Änderungen aus dem Projektarchiv haben sich aber nicht damit überschnitten.

Die nächsten paar Zeilen sind allerdings interessant. Zunächst teilt Ihnen Subversion mit, dass es beim Versuch, ausstehende Server-Änderungen in die Datei bar.c hineinzubringen, festgestellt hat, dass einige dieser Änderungen mit lokalen Änderungen kollidieren, die Sie an dieser Datei in Ihrer Arbeitskopie vorgenommen, jedoch noch nicht übergeben haben. Vielleicht hat jemand dieselbe Textzeile wie Sie geändert. Wie dem auch sei, Subversion markiert diese Datei umgehend als konfliktbehaftet. Dann fragt es Sie, wie Sie mit diesem Problem umgehen möchten, indem es Ihnen interaktiv einen Bearbeitungsschritt zur Auflösung des Konfliktes anbietet. Die am häufigsten verwendeten Optionen werden angezeigt, aber Sie können auch alle Optionen sehen, wenn Sie s eintippen:

…
Auswahl: (p) zurückstellen, (df) voller Diff, (e) editieren,
         (mc) eigene konfliktbehaftete Datei, (tc) fremde konfliktbehaftete Datei,
         (s) alle Optionen anzeigen: s

  (e)  editieren          - zusammengeführte Datei in einem Editor ändern
  (df) voller Diff        - alle Änderungen in der zusammengeführten Datei anzeigen
  (r)  aufgelöst          - akzeptieren der zusammengeführten Version der Datei
  (dc) Konflikte anzeigen - alle Konflikte anzeigen (die zusammengeführte Version
                            ignorieren)
  (mc) mine-conflict      - eigene Version für alle Konflikte akzeptieren (das selbe)
  (tc) theirs-conflict    - fremde Version für alle Konflikte akzeptieren (das selbe)

  (mf) volle eigene Datei - die eigene Version der kompletten Datei akzeptieren
                            (selbst Nicht-Konflikte)
  (tf) volle fremde Datei - die fremde Version der kompletten Datei akzeptieren
                            (das selbe)
  (p)  zurückstellen      - den Konflikt erst später auflösen
  (l)  starten            - Starten eines externen Programms zur Konfliktauflösung
  (s)  alle anzeigen      - diese Liste anzeigen

Auswahl: (p) zurückstellen, (df) voller Diff, (e) editieren,
         (mc) eigene konfliktbehaftete Datei, (tc) fremde konfliktbehaftete Datei,
         (s) alle Optionen anzeigen:

Bevor wir im Detail erklären, was jede Option bedeutet, gehen wir noch mal eben die Optionen durch.

(e) editieren

Die Konfliktdatei im bevorzugten Editor, wie in der Umgebungsvariablen EDITOR angegeben, öffnen.

(df) voller Diff

Die Unterschiede zwischen der Basisrevision und der Konfliktdatei im unified-diff-Format anzeigen.

(r) aufgelöst

Nach dem Bearbeiten einer Datei teilen Sie svn mit, dass Sie die Konflikte in der Datei aufgelöst haben und der aktuelle Inhalt übernommen werden soll.

(dc) Konflikte anzeigen

Zeigt alle konfliktbehafteten Regionen der Datei an, wobei erfolgreich zusammengeführte Änderungen ignoriert werden.

(mc) mine-conflict

Die neuen vom Server erhaltenen Änderungen verwerfen, die in Konflikt mit Ihren lokalen Änderungen an der zu überprüfenden Datei stehen. Jedoch werden alle nicht in Konflikt stehenden Änderungen vom Server für diese Datei angenommen und zusammengeführt.

(tc) theirs-conflict

Alle lokalen Änderungen an der zu überprüfenden Datei verwerfen, die in Konflikt zu Änderungen vom Server stehen. Jedoch werden alle nicht in Konflikt stehenden lokalen Änderungen an dieser Datei beibehalten.

(mf) volle eigene Datei

Alle neuen vom Server erhaltenen Änderungen für die zu überprüfende Datei verwerfen, aber alle Ihre lokalen Änderungen an dieser Datei beibehalten.

(tf) volle fremde Datei

Alle Ihre lokalen Änderungen für die zu überprüfende Datei verwerfen und nur die neuen vom Server erhaltenen Änderungen für diese Datei verwenden.

(p) zurückstellen

Die Datei im Konfliktzustand lassen, um nach Abschluss der Aktualisierung die Konfliktauflösung durchzuführen.

(l) starten

Ein externes Programm zur Konfliktauflösung starten. Das setzt Vorbereitungen voraus.

(s) alle anzeigen

Die Liste aller bei der interaktiven Konfliktauflösung möglichen Befehle anzeigen.

Wir werden diese Befehle nun detaillierter behandeln, wobei sie nach Funktionalität gruppiert werden.

Interaktive Begutachtung der Konflikte

Bevor Sie entscheiden, wie Sie einen Konflikt beseitigen wollen, wollen Sie wahrscheinlich genau sehen, worin der Konflikt besteht. Zwei der bei der interaktiven Aufforderung zur Verfügung stehenden Befehle können Ihnen dabei helfen. Der erste ist der Befehl voller Diff (df), der alle lokalen Änderungen an der zu begutachtenden Datei und die in Konflikt stehenden Regionen anzeigt:

…
Auswahl: (p) zurückstellen, (df) voller Diff, (e) editieren,
         (mc) eigene konfliktbehaftete Datei, (tc) fremde konfliktbehaftete Datei,
         (s) alle Optionen anzeigen: df
--- .svn/text-base/sandwich.txt.svn-base      Tue Dec 11 21:33:57 2007
+++ .svn/tmp/tempfile.32.tmp     Tue Dec 11 21:34:33 2007
@@ -1 +1,5 @@
-Just buy a sandwich.
+<<<<<<< .mine
+Go pick up a cheesesteak.
+=======
+Bring me a taco!
+>>>>>>> .r32
…

Die erste Zeile des diff-Inhalts zeigt den vorherigen Inhalt der Arbeitskopie (die BASE-Revision), die nächste Zeile beinhaltet Ihre Änderung und die letzte Zeile ist die Änderung, die soeben vom Server empfangen worden ist (gewöhnlich die HEAD-Revision).

Der zweite Befehl ist ähnlich wie der erste, jedoch zeigt der Befehl Konflikte anzeigen (dc) nur die in Konflikt stehenden Regionen an statt aller Änderungen an der Datei. Darüber hinaus verwendet dieser Befehl ein etwas anderes Darstellungsformat für die Konfliktregionen, das es Ihnen auf einfache Weise erlaubt, den Dateiinhalt dieser Regionen in den drei möglichen Zuständen zu vergleichen: original und unbearbeitet, mit Ihren Änderungen, wobei die in Konflikt stehenden Änderungen vom Server ignoriert werden und mit den Änderungen vom Server, wobei Ihre lokalen Änderungen rückgängig gemacht wurden.

Nachdem Sie die durch diesen Befehl bereitgestellten Informationen geprüft haben, können Sie den nächsten Schritt in Angriff nehmen.

Interaktive Konfliktauflösung

Es gibt mehrere unterschiedliche Wege, um Konflikte interaktiv aufzulösen – von denen Ihnen zwei erlauben, Änderungen selektiv zusammenzuführen und zu editieren und die restlichen, die es Ihnen erlauben, einfach eine Version der Datei auszuwählen und weiterzumachen.

Falls Sie eine beliebige Kombination Ihrer lokalen Änderungen auswählen wollen, können Sie den Befehl editieren (e) verwenden, um die Datei mit den Konfliktmarken manuell in einem Texteditor (nach den Anweisungen in „Verwendung externer Editoren“ konfiguriert) bearbeiten. Nachdem Sie die Datei bearbeitet haben und mit Ihren Änderungen zufrieden sind, können Sie Subversion mitteilen, das sich die bearbeitete Datei nicht mehr im Konfliktzustand befindet, indem Sie den Befehl resolve (r) benutzen.

Egal, was Ihnen wahrscheinlich Ihr Unix-Snob erzählen wird, die manuelle Bearbeitung der Datei in Ihrem Lieblings-Texteditor ist die Low-Tech Variante zur Beseitigung von Konflikten (siehe „Manuelle Konfliktauflösung“ für die Vorgehensweise). Aus diesem Grund bietet Subversion den Befehl starten (l) zum Starten eines schicken graphischen Werkzeugs zum Zusammenführen (siehe „External merge“).

Falls Sie entscheiden, dass Sie keine Änderungen zusammenzuführen brauchen, sondern lediglich eine der beiden Dateiversionen akzeptieren wollen, können Sie entweder Ihre Änderungen (auch meine) mit dem mine-full-Befehl (mf) oder die der Anderen mit dem theirs-full-Befehl (tf) auswählen.

Zum Schluss gibt es noch ein Paar von Kompromissoptionen. Die Befehle mine-conflict (mc) und theirs-conflict (tc) sagen Subversion, es soll Ihre lokalen Änderungen bzw. die Änderungen vom Server zum Auflösen aller Konflikte innerhalb der Datei heranziehen. Im Gegensatz zu den Befehlen volle eigene Datei und volle fremde Datei bewahren beide Befehle jedoch Ihre lokalen Änderungen und die Änderungen vom Server an den Stellen der Datei, an denen keine Konflikte entdeckt wurden.

Aufschieben der Konfliktauflösung

Das hört sich vielleicht an wie ein passender Abschnitt zur Vermeidung von Ehestreitigkeiten, doch es geht immer noch um Subversion; also lesen Sie weiter. Falls Sie eine Aktualisierung vornehmen und ein Konflikt auftaucht, den Sie nicht begutachten oder auflösen können, ermöglicht Ihnen das Eingeben von p die Konfliktauflösung Datei für Datei aufzuschieben, wenn Sie svn update aufrufen. Falls Sie bereits vorher wissen, dass Sie aktualisieren wollen, ohne Konflikte aufzulösen, können Sie die Option --non-interactive an svn update übergeben, und jede Datei mit Konflikten wird automatisch mit einem C gekennzeichnet.

Das C (für Conflicted) bedeutet, dass die Änderungen vom Server sich mit Ihren eigenen überschneiden, und Sie nach Abschluss der Aktualisierung manuell aus den Änderungen wählen müssen. Wenn Sie eine Konfliktauflösung verschieben, macht svn typischerweise drei Dinge, um Ihnen bei der Konfliktauflösung zu helfen:

  • Subversion gibt ein C während der Aktualisierung aus und merkt sich, dass die Datei in einem Konfliktzustand ist.

  • Falls Subversion die Datei als geeignet zum Zusammenführen ansieht, fügt es Konfliktmarken – besondere Zeichenketten, die die Konfliktregion begrenzen – in die Datei ein, um die überlappenden Bereiche besonders hervorzuheben. (Subversion verwendet die Eigenschaft svn:mime-type, um festzustellen, ob sich die Datei kontextuell zeilenweise zusammenführen lässt. Siehe „Datei-Inhalts-Typ“, um mehr zu erfahren.)

  • Für jede Datei mit Konflikten stellt Subversion drei zusätzliche unversionierte Dateien in Ihre Arbeitskopie:

    filename.mine

    Dies ist Ihre Datei aus der Arbeitskopie bevor Sie die Aktualisierung begannen. Diese Datei beinhaltet Ihre lokalen Änderungen sowie Konfliktmarkierungen. (Falls Subversion diese Datei als nicht-zusammenführbar erachtet, wird die .mine-Datei nicht erstellt, da sie identisch mit der Datei der Arbeitskopie wäre.)

    filename.rOLDREV

    Dies ist die Datei, wie sie in der BASE-Revision aussah, d.h., die unmodifizierte Revision der Datei in Ihrer Arbeitskopie bevor Sie die Aktualisierung begonnen haben, wobei OLDREV die Nummer der BASE-Revision ist.

    filename.rNEWREV

    Dies ist die Datei, die Ihr Subversion-Client soeben durch die Aktualisierung Ihrer Arbeitskopie vom Server erhalten hat, wobei NEWREV der Revisionsnummer entspricht, auf der Sie aktualisiert haben (HEAD, falls nichts anderes angegeben wurde).

Beispielsweise ändert Sally die Datei sandwich.txt, übergibt diese Änderungen jedoch noch nicht. In der Zwischenzeit übergibt Harry Änderungen an derselben Datei. Sally aktualisiert Ihre Arbeitskopie vor der Übergabe und bekommt einen Konflikt, den sie verschiebt:

$ svn update
Konflikt in »sandwich.txt« entdeckt.
Auswahl: (p) zurückstellen, (df) voller Diff, (e) editieren,
         (mc) eigene konfliktbehaftete Datei, (tc) fremde konfliktbehaftete Datei
         (s) alle Optionen anzeigen: p
C  sandwich.txt
Aktualisiert zu Revision 2.
Konfliktübersicht:
  Textkonflikte: 1
$ ls -1
sandwich.txt
sandwich.txt.mine
sandwich.txt.r1
sandwich.txt.r2

An dieser Stelle erlaubt Subversion Sally nicht, die Datei sandwich.txt an das Projektarchiv zu übergeben, solange die drei temporären Dateien nicht entfernt werden:

$ svn commit -m "Add a few more things"
svn: Übertragen schlug fehl (Details folgen):
svn: Übertragung abgebrochen: »/home/sally/svn-work/sandwich.txt« bleibt im Konflikt

Falls Sie eine Konfliktauflösung aufgeschoben haben, müssen Sie den Konflikt auflösen, bevor Ihnen Subversion erlaubt, Ihre Änderungen in das Projektarchiv einzustellen. Sie werden dafür den svn resolve-Befehl mit einem von mehreren Argumenten für die --accept-Option aufrufen.

Falls Sie die Dateiversion vor Ihren Änderungen haben möchten, wählen Sie das base-Argument.

Falls Sie die Version möchten, die nur Ihre Änderungen enthält, wählen Sie das mine-full-Argument.

Falls Sie die Version möchten, die Ihre letzte Aktualisierung vom Server gezogen hat (und somit Ihre Änderungen vollständig verwerfen wollen), wählen Sie das Argument theirs-full.

Wenn Sie jedoch frei aus Ihren Änderungen und den Änderungen vom Server wählen möchten, führen Sie den konfliktbehafteten Text händisch zusammen (indem Sie die Konfliktmarken in der Datei begutachten und editieren) und wählen das working-Argument.

svn resolve entfernt die drei temporären Dateien und akzeptiert die Version, die Sie mit der --accept-Option angeben. Subversion betrachtet die Datei nun als nicht mehr konfliktbehaftet:

$ svn resolve --accept working sandwich.txt
Konflikt von »sandwich.txt« aufgelöst

Manuelle Konfliktauflösung

Das manuelle Auflösen von Konflikten kann ganz schön einschüchternd sein, wenn Sie es das erste Mal versuchen; jedoch kann es mit etwas Übung so leicht werden, wie vom Fahrrad zu fallen.

Hier ist ein Beispiel. Aufgrund einer schlechten Absprache bearbeiten Sie und Ihre Mitarbeiterin Sally gleichzeitig die Datei sandwich.txt. Sally übergibt ihre Änderungen an das Projektarchiv, und sobald Sie versuchen, Ihre Arbeitskopie zu aktualisieren, erhalten Sie einen Konflikt und müssen sandwich.txt bearbeiten, um den Konflikt aufzulösen. Zunächst wollen wir uns die Datei einmal ansehen:

$ cat sandwich.txt
Top piece of bread
Mayonnaise
Lettuce
Tomato
Provolone
<<<<<<< .mine
Salami
Mortadella
Prosciutto
=======
Sauerkraut
Grilled Chicken
>>>>>>> .r2
Creole Mustard
Bottom piece of bread

Die Zeichenketten aus Kleiner-als-Zeichen, Gleichheitszeichen und Größer-als-Zeichen sind Konfliktmarken und gehören nicht zu den eigentlichen Daten, die in Konflikt stehen. Im Allgemeinen werden Sie sicherstellen wollen, dass die Konflikte aus der Datei entfernt werden, bevor sie das nächste Mal eine Übergabe durchführen. Der Text zwischen den ersten beiden Marken besteht aus den Änderungen, die Sie im Konfliktbereich vorgenommen haben:

<<<<<<< .mine
Salami
Mortadella
Prosciutto
=======

Der Text zwischen der zweiten und der dritten Marke ist der Text aus Sallys Übergabe:

=======
Sauerkraut
Grilled Chicken
>>>>>>> .r2

Für gewöhnlich werden Sie nicht einfach die Konfliktmarken mitsamt der Änderungen von Sally löschen wollen – sie wird furchtbar überrascht sein, wenn das Sandwich kommt und nicht das drauf ist, was sie wollte. Hier ist der Zeitpunkt gekommen, zu dem Sie zum Telefon greifen oder durch das Büro gehen und Sally erklären, dass man in einem italienischen Delikatessenladen kein Sauerkraut bekommt.[7] Sobald Sie sich über die zu übergebenden Änderungen einig sind, können Sie Ihre Datei bearbeiten und die Konfliktmarken entfernen:

Top piece of bread
Mayonnaise
Lettuce
Tomato
Provolone
Salami
Mortadella
Prosciutto
Creole Mustard
Bottom piece of bread

Verwenden Sie jetzt svn resolve, und Sie sind bereit, Ihre Änderungen an das Projektarchiv zu übergeben:

$ svn resolve --accept working sandwich.txt
Konflikt von »sandwich.txt« aufgelöst
$ svn commit -m "Mach weiter mit meinem Sandwich, vergiss Sallys Änderungen."

Beachten Sie, dass svn resolve, anders als die meisten anderen Befehle, die wir in diesem Kapitel behandeln, erwartet, dass Sie ausdrücklich alle Dateien aufzählen, deren Konflikt Sie beseitigt haben. Auf alle Fälle sollten Sie sorgfältig vorgehen und svn resolve nur verwenden, falls Sie sicher sind, den Konflikt in Ihrer Datei beseitigt zu haben – sobald die temporären Dateien entfernt sind, lässt Subversion zu, dass Sie die Datei in das Projektarchiv stellen, selbst wenn sie noch Konfliktmarken enthält.

Falls Sie mal bei der Bearbeitung der konfliktbehafteten Datei verwirrt sein sollten, können Sie jederzeit in den drei Dateien nachsehen, die Subversion für Sie in der Arbeitskopie bereitstellt – dazu gehört auch Ihre Datei vor der Aktualisierung. Sie können sogar ein Zusammenführungs-Werkzeug eines Drittanbieters verwenden, um diese drei Dateien zu untersuchen.

Verwerfen Ihrer Änderungen zugunsten einer aktualisierten Revision aus dem Projektarchiv

Falls Sie einen Konflikt erhalten und entscheiden, dass Sie Ihre Änderungen verwerfen wollen, können Sie svn resolve --accept theirs-full CONFLICTED-PATH aufrufen, und Subversion wird Ihre Änderungen ignorieren und die temporären Dateien entfernen:

$ svn update
Konflikt in »sandwich.txt« entdeckt.
Auswahl: (p) zurückstellen, (df) voller Diff, (e) editieren,
         (mc) eigene konfliktbehaftete Datei, (tc) fremde konfliktbehaftete Datei
         (s) alle Optionen anzeigen: p
C    sandwich.txt
Aktualisiert zu Revision 2.
$ ls sandwich.*
sandwich.txt  sandwich.txt.mine  sandwich.txt.r2  sandwich.txt.r1
$ svn resolve --accept theirs-full sandwich.txt
Konflikt von »sandwich.txt« aufgelöst
$

Die Verwendung von svn revert

Falls Sie sich entscheiden, Ihre Änderungen zu verwerfen und erneut mit der Bearbeitung zu beginnen (ob nach einem Konflikt oder sonst zu jeder Zeit), machen Sie einfach Ihre Änderungen rückgängig:

$ svn revert sandwich.txt
Rückgängig gemacht: »sandwich.txt«
$ ls sandwich.*
sandwich.txt
$

Beachten Sie, dass Sie beim Rückgängigmachen einer konfliktbehafteten Datei nicht svn resolve zu verwenden brauchen.

Übergeben Ihrer Änderungen

Endlich! Sie haben die Bearbeitung abgeschlossen, Sie haben alle Änderungen vom Server eingearbeitet, und Sie sind bereit, Ihre Änderungen an das Projektarchiv zu übergeben.

Der Befehl svn commit schickt all Ihre Änderungen zum Projektarchiv. Wenn Sie eine Änderung übergeben, müssen Sie einen Protokolleintrag erstellen, der die Änderung beschreibt. Dieser Eintrag wird mit der von Ihnen erzeugten neuen Revision verknüpft. Wenn Ihr Eintrag kurz ist, können Sie ihn mit der Option --message (-m) in der Kommandozeile angeben:

$ svn commit -m "Anzahl Käsescheiben korrigiert."
Sende          sandwich.txt
Übertrage Daten .
Revision 3 übertragen.

Falls Sie jedoch Ihren Protokolleintrag während der Arbeit in irgendeiner Textdatei erstellen möchten, können Sie Subversion mitteilen, sich den Eintrag aus dieser Datei zu holen, indem Sie ihren Namen mit der Option --file (-F) angeben:

$ svn commit -F logmsg
Sende          sandwich.txt
Übertrage Daten .
Revision 4 übertragen.

Sollten Sie vergessen, entweder die Option --message (-m) oder die Option --file (-F) anzugeben, startet Subversion automatisch Ihren Lieblingseditor (siehe die Information zu editor-cmd in „Config“), damit Sie einen Protokolleintrag erstellen können.

[Tipp] Tipp

Wenn Sie gerade in Ihrem Editor einen Eintrag schreiben und sich entschließen, die Übergabe abzubrechen, können Sie einfach Ihren Editor beenden, ohne die Änderungen zu sichern. Falls Sie den Eintrag bereits gesichert haben sollten, löschen Sie einfach den gesamten Text, sichern Sie erneut und brechen dann ab:

$ svn commit

Logmeldung unverändert oder nicht angegeben
A)bbrechen, Weitermac)hen, E)ditieren:
a
$

Das Projektarchiv weiß nicht, ob Ihre Änderung im Ganzen einen Sinn ergeben, es ist ihm auch egal; es überprüft lediglich, ob nicht irgendjemand anderes irgendeine derselben Dateien geändert hat wie Sie, als Sie mal weggeschaut haben. Falls jemand das gemacht hat, wird die gesamte Übergabe mit einer Meldung fehlschlagen, dass eine oder mehrere Ihrer Dateien nicht mehr aktuell sind:

$ svn commit -m "Noch eine Regel hinzufügen"
Sende          rules.txt
svn: Übertragen schlug fehl (Details folgen):
svn: Datei »/rules.txt« ist veraltet
…

(Der genaue Wortlaut dieser Fehlermeldung hängt vom verwendeten Netzwerkprotokoll und vom Server ab, doch die Bedeutung ist in allen Fällen gleich.)

Zu diesem Zeitpunkt müssen Sie svn update aufrufen, sich um eventuelle Zusammenführungen oder Konflikte kümmern und die Übergabe erneut versuchen.

Das deckt den grundlegenden Arbeitszyklus für die Verwendung von Subversion ab. Subversion bietet viele andere Möglichkeiten, die Sie benutzen können, um Ihr Projektarchiv und Ihre Arbeitskopie zu verwalten, doch der größte Teil Ihrer täglichen Arbeit mit Subversion wird lediglich die in diesem Kapitel behandelten Befehle berühren. Wir werden jedoch noch ein paar mehr Befehle behandeln, die Sie ziemlich oft verwenden werden.



[6] Selbstverständlich wird nichts jemals vollständig aus dem Projektarchiv gelöscht – lediglich aus seiner HEAD-Revision. Sie können weiterhin auf das gelöschte Objekt in früheren Revisionen zugreifen. Sollten Sie den Wunsch haben, das Objekt wiederauferstehen zu lassen, so das es wieder in HEAD vorhanden ist, siehe „Zurückholen gelöschter Objekte“.

[7] Und wenn Sie danach fragen, wird man Sie wahrscheinlich auf einer Schiene aus der Stadt tragen.