Beschreibung

Manchmal kann es vorkommen, dass ein Administrator den Ort des Projektarchivs (oder den anscheinenden Ort aus der Sicht des Clients) ändert. Der Inhalt des Projektarchivs ändert sich zwar nicht, jedoch der URL der Wurzel des Projektarchivs. Der Rechnername könnte sich ändern, weil Subversion nun von einem anderen Rechner bedient wird. Vielleicht ändert sich auch das Schema des URL weil auf das Projektarchiv nun über SSL zugegriffen wird (unter Verwendung von https://) anstatt über einfaches HTTP. Es gibt viele Gründe für diese Art von Projektarchiv-Verlagerungen. Doch sollte idealerweise eine „Adressänderung“ für ein Projektarchiv nicht dazu führen, dass alle darauf zeigenden Arbeitskopien für immer unbenutzbar werden. Und glücklicherweise ist dem auch nicht so. Statt bei einer Verlagerung des Projektarchivs die Anwender zu zwingen, eine neue Arbeitskopie anzulegen, stellt Subversion den Befehl svn relocate zur Verfügung, der die Verwaltungs-Metadaten der Arbeitskopie „umschreibt“, um auf den neuen Ort des Projektarchivs zu zeigen.

Die erste Form des Aufrufs von svn relocate, erlaubt Ihnen, eine oder mehrere Arbeitskopien in einer Art Suche-und-Ersetzen hinsichtlich der darin aufgezeichneten Projektarchiv-Wurzel-URLs zu aktualisieren. Subversion ersetzt dabei die Anfangszeichenkette FROM-PREFIX durch die Zeichenkette TO-PREFIX in diesen URLs. Diese Anfangszeichenketten der URLs können so lang oder so kurz sein, wie es erforderlich ist, um sie unterscheiden zu können. Um diese Aufrufsform verwenden zu können, müssen Sie offensichtlich sowohl den aktuellen Wurzel-URL des Projektarchivs kennen, auf das Ihre Arbeitskopie verweist, als auch den neuen URL des Projektarchivs. (Um ersteren herauszubekommen, können Sie svn info verwenden.

Die zweite Aufrufsform setzt nicht voraus, dass Sie den Wurzel-URL des mit der Arbeitskopie verbundenen Projektarchivs kennen, sondern nur den neuen Projektarchiv-URL (TO-URL) auf den sie verweisen soll. In dieser Form kann nur eine Arbeitskopie pro Aufruf verlagert werden.

Warnung

Anwender werden oft durch die Unterschiede zwischen svn switch und svn relocate verwirrt. Hier ist die Faustregel: Falls die Arbeitskopie ein neues Verzeichnis innerhalb des Projektarchivs widerspiegeln soll, verwenden Sie svn switch. Falls die Arbeitskopie immer noch das gleiche Verzeichnis im Projektarchiv widerspiegeln soll, sich jedoch der Ort des Projektarchivs selbst geändert hat, verwenden Sie svn relocate.

Optionen

--ignore-externals

Beispiele

Lassen Sie uns mit einer Arbeitskopie beginnen, die den URL eines lokalen Projektarchivs widerspiegelt:

$ svn info | grep ^URL:
URL: file:///var/svn/repos/trunk
$

Eines Tages beschließt der Administrator, das Verzeichnis mit dem Projektarchiv auf der Platte umzubenennen. Wir haben die Benachrichtigung nicht mitbekommen, so dass wir beim nächsten Versuch, die Arbeitskopie zu aktualisieren, einen Fehler sehen.

$ svn up
Updating '.':
svn: E180001: Unable to connect to a repository at URL 'file:///var/svn/repos/trunk'

Nachdem wir dem Administrator am Verkaufsautomaten in die Enge getrieben haben, erfahren wir von der Verschiebung des Projektarchivs und den neuen URL. Anstatt eine neue Arbeitskopie auszuchecken, fordern wir Subversion auf, die Metadaten der Arbeitskopie umzuschreiben, damit sie auf den neuen Speicherort des Projektarchivs verweist.

$ svn relocate file:///var/svn/new-repos/trunk
$

Subversion erzählt uns nicht sehr viel darüber, was es getan hat, aber, was soll's? Alles was wir benötigen ist ein fehlerfreies Funktionieren. Unsere Arbeitskopie funktioniert wieder für Online-Operationen.

$ svn up
Updating '.':
A    lib/new.c
M    src/code.h
M    src/headers.h
…

	Anmerkung
	Auch dieses Mal berührt diese Art von Verlagerung lediglich Metadaten der Arbeitskopie. Sie ändert keine Dateiinhalte versionierter oder unversionierter Dateien, führt keinerlei Versions-Kontroll-Operationen aus (etwa Übergaben oder Aktualisierungen) usw.

Ein paar Monate später wird uns mitgeteilt, dass das Unternehmen mit der Entwicklung auf getrennte Maschinen umzieht und wir für den Zugriff auf das Projektarchiv HTTP verwenden werden. Also verlagern wir unsere Arbeitskopie erneut.

$ svn relocate http://svn.company.com/repos/trunk
$

Jedes Mal, wenn wir eine derartige Verlagerung durchführen, nimmt Subversion Kontakt mit dem Projektarchiv auf – natürlich unter seinem neuen URL – und überprüft ein paar Dinge.

Zunächst versucht es, die UUID des Projektarchivs mit dem in der Arbeitskopie gespeicherten Wert zu vergleichen. Falls diese UUIDs unterschiedlich sind, wird die Verlagerung der Arbeitskopie abgelehnt. Vielleicht ist es letztlich gar nicht dasselbe Projektarchiv (nur an einem neuer Ort).

Zweitens versucht Subversion sicherzustellen, dass sich die aktualisierten Metadaten der Arbeitskopie hinsichtlich des Ortes des Verzeichnisses innerhalb des Projektarchivs befinden. Subversion wird es nicht zulassen, dass Sie versehentlich eine Arbeitskopie eines Zweigs in Ihrem Projektarchiv auf den URL eines unterschiedlichen Zweigs in demselben Projektarchiv verlagern. (Dafür ist svn switch da, beschrieben in svn switch (sw).)

Subversion erlaubt es Ihnen auch nicht, einen Teilbaum der Arbeitskopie zu verlagern. Sofern Sie die Arbeitskopie überhaupt verlagern möchten, müssen sie das ganze Ding verlagern. Das dient dem Schutz der Integrität der Metadaten und dem gesamten Verhalten der Arbeitskopie. (Es würde ohnehin wirklich schwer für Sie, eine überzeugende Begründung zu finden, warum nur ein Stück Ihrer Arbeitskopie verlagert werden sollte.)

Lassen Sie uns eine abschließende Gelegenheit für eine Verlagerung betrachten. Nachdem der Zugriff eine Zeit lang über HTTP erfolgte, verwendet das Unternehmen nun nur noch SSL-Zugriff. Die einzige Änderung an dem URL des Projektarchivs ist eine Schemaänderung von http:// nach https://. Es gibt zwei unterschiedliche Wege, die unsere Arbeitskopie diese Änderung widerspiegeln läßt. Der erste ist genau so wie eben beim Verlagern des URL des Projektarchivs.

$ svn relocate https://svn.company.com/repos/trunk
$

Hier haben wir jedoch eine zusätzliche Option. Wir können Subversion einfach auffordern, die geänderten Präfixe des URL zu tauschen.

$ svn relocate http https
$

Beide Ansätze hinterlassen eine Arbeitskopie, deren Metadaten so aktualisiert wurden, dass sie auf den richtigen Speicherort des Projektarchivs verweisen.

Standardmäßig wird svn relocate etwaige externe Arbeitskopien durchlaufen, die Sie in ihre Arbeitskopie eingebunden haben, und versucht, auch diese Arbeitskopien zu verlagern. Verwenden Sie die Option --ignore-externals, um dieses Verhalten zu unterbinden.