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 unserem früheren Beispiel 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 $ svn switch http://svn.example.com/repos/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
„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:
Kopiere den vollständigen „Stamm“ des Projektes in ein neues Zweig-Verzeichnis.
Schalte nur einen Teil der Arbeitskopie vom Stamm auf den Zweig um.
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.
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 Unterbaum. Wenn Sie übergeben, werden Ihre lokalen Änderungen nach wie vor als eine einzelne atomare Änderung auf das Projektarchiv angewendet.
Während es normal ist, das eine Arbeitskopie eine Mischung unterschiedlicher Projektarchiv-Orte repräsentiert, ist darauf zu achten, dass 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. [24]
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
$ 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 http://svn.example.com/repos/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. |
[24] Sie können jedoch svn
switch mit der Option --relocate
verwenden, falls sich der URL Ihres Servers geändert hat,
und Sie die bestehende Arbeitskopie nicht aufgeben wollen.
Siehe svn switch für weitere
Informationen und ein Beispiel.