Der Befehl svn switch überführt eine bestehende Arbeitskopie, so dass sie einen anderen Zweig repräsentiert. Obwohl dieser Befehl strenggenommen für die Arbeit mit Zweigen nicht notwendig ist, stellt er eine nette Abkürzung dar. In einem unserer früheren Beispiele haben Sie nach dem Anlegen Ihres eigenen privaten Zweigs eine frische Arbeitskopie des neuen Projektarchiv-Verzeichnisses ausgecheckt. Stattdessen können Sie Subversion einfach mitteilen, dass es Ihre Arbeitskopie von /calc/trunk ändern soll, um den neuen Ort des Zweigs widerzuspiegeln:

$ cd calc

$ svn info | grep URL
URL: http://svn.example.com/repos/calc/trunk
Relative URL: ^/calc/trunk
$ svn switch ^/calc/branches/my-calc-branch
U    integer.c
U    button.c
U    Makefile 
Aktualisiert zu Revision 341.

$ svn info | grep URL
URL: http://svn.example.com/repos/calc/branches/my-calc-branch
Relative URL: ^/calc/branches/my-calc-branch
$

„Das Umschalten“ einer Arbeitskopie ohne lokale Änderungen auf einen anderen Zweig hat zur Folge, dass die Arbeitskopie genau so aussieht, als sei das Verzeichnis frisch ausgecheckt worden. Es ist gewöhnlicherweise effizienter, diesen Befehl zu verwenden, da sich Zweige oftmals nur in kleinen Teilen unterscheiden. Der Server sendet nur die minimale Menge von Änderungen, die notwendig sind, damit Ihre Arbeitskopie den Inhalt des Zweig-Verzeichnisses wiedergibt.

Der Befehl svn switch versteht auch die Option --revision (-r), so dass Sie nicht immer gezwungen sind, Ihre Arbeitskopie auf den HEAD des Zweigs zu setzen.

Natürlich sind die meisten Projekte komplizierter als unser calc-Beispiel und enthalten mehrere Unterverzeichnisse. Subversion-Benutzer wenden bei der Verwendung von Zweigen häufig einen bestimmten Algorithmus an:

In anderen Worten: Wenn ein Benutzer weiß, dass die Arbeit auf dem Zweig nur in einem bestimmten Unterverzeichnis stattfinden muss, verwendet er svn switch lediglich, um dieses Unterverzeichnis auf den Zweig zu bringen. (Manchmal schalten Benutzer sogar nur eine einzelne Datei auf den Zweig um!) Auf diese Art kann ein Benutzer für einen großen Teil der Arbeitskopie weiterhin normale Aktualisierungen auf dem „Stamm“ erhalten, wohingegen die umgeschalteten Teile unberührt bleiben (es sei denn, jemand übergibt etwas an den Zweig). Diese Möglichkeit fügt dem Konzept einer „gemischten Arbeitskopie“ eine völlig neue Dimension hinzu – Arbeitskopien können nicht nur eine Mischung unterschiedlicher Revisionen enthalten, sondern auch eine Mischung unterschiedlicher Projektarchiv-Orte.

	Tipp
	Typischerweise teilen sich umgestellte Unterverzeichnisse eine gemeinsame Herkunft mit dem Ort von dem sie „wegbewegt“ werden. Allerdings kann ein Unterverzeichnis mit svn switch so umgestellt werden, dass es einen Ort im Projektarchiv widerspiegelt, mit dem es keinerlei gemeinsame Herkunft teilt. Um das zu bewerkstelligen, müssen Sie die Option --ignore-ancestry verwenden.

Falls Ihre Arbeitskopie eine Anzahl umgeschalteter Unterverzeichnisse aus unterschiedlichen Projektarchiv-Orten enthält, funktioniert sie immer noch normal. Wenn Sie aktualisieren, erhalten Sie entsprechende Patches für jeden Teilbaum. Wenn Sie übertragen, werden Ihre lokalen Änderungen nach wie vor als eine einzelne atomare Änderung auf das Projektarchiv angewendet.

Beachten Sie, dass, obwohl es normal ist, dass eine Arbeitskopie eine Mischung unterschiedlicher Projektarchiv-Orte repräsentiert, all diese Orte sich innerhalb desselben Projektarchivs befinden. Subversion-Projektarchive können noch nicht miteinander kommunizieren; diese Möglichkeit ist für die Zukunft geplant. ^[45]

Tipp

Administratoren, die den URL eines Projektarchivs ändern müssen, auf das über HTTP zugegriffen wird, sei empfohlen, ihrer Konfigurationsdatei httpd.conf eine ständige Weiterleitung vom alten URL zum neuen einzurichten (mit der Anweisung RedirectPermanent). Im Allgemeinen werden Subversion-Clients den neuen URL des Projektarchivs in Fehlermeldungen anzeigen, die erzeugt werden, falls der Anwender versucht, auf Arbeitskopien zuzugreifen, die immer noch den alten URL widerspiegeln. Seit Subversion 1.7 gehen Clients hier tatsächlich noch einen Schritt weiter, indem sie automatisch die Arbeitskopie auf den neuen URL umziehen lassen.

Da svn switch eigentlich eine Variante von svn update ist, teilt es dasselbe Verhalten; irgendwelche lokalen Änderungen Ihrer Arbeitskopie bleiben erhalten, wenn neue Daten aus dem Projektarchiv ankommen.

Tipp

Haben Sie sich jemals dabei ertappt, dass Sie (in Ihrer /trunk-Arbeitskopie) komplexe Änderungen gemacht haben und plötzlich feststellen: „Verdammt, diese Änderungen sollten auf einen eigenen Zweig!“ Es gibt eine gute Technik, um das in zwei Schritten zu bewerkstelligen: $ svn copy http://svn.example.com/repos/calc/trunk \ http://svn.example.com/repos/calc/branches/newbranch \ -m "Zweig 'newbranch' angelegt." Revision 353 übertragen. $ svn switch ^/calc/branches/newbranch Revision 353. Der Befehl svn switch bewahrt wie svn update Ihre lokalen Änderungen. An dieser Stelle spiegelt Ihre Arbeitskopie den neu erzeugten Zweig wieder, und Ihr nächster Aufruf von svn commit wird Ihre Änderungen dorthin senden.