Der Kommandozeilen-Client von Subversion unterstützt eine Reihe Operationen, die direkt gegen URLs eines Projektarchivs ausgeführt werden können, um einfache Änderungen ohne Arbeitskopie vorzunehmen. Einige davon werden an anderer Stelle in diesem Buch beschrieben, doch der Einfachheit halber stellen wir an dieser Stelle eine erschöpfende Liste zur Verfügung.

Die vielleicht offensichtlichste Operation, die einer Übertragung nahe kommt, ist der Befehl svn import. Wir beschreiben diesen Befehl in „Importieren von Dateien und Verzeichnissen“ im Rahmen der Erklärung, wie Sie einen vollständigen Baum an unversionierter Information in Ihr Subversion-Projektarchiv bekommen, so dass Sie damit beginnen können, versionsverwaltete Operationen darauf vorzunehmen.

Die Befehle svn mkdir und svn delete sind ebenfalls von der Art aus der ferne bedienter Übertragungen, wenn sie mit URL-Zielen verwendet werden. Diese erlauben es dem Anwender, ein oder mehrere neue Verzeichnisse zu erstellen bzw. ein oder mehrere versionierte Dateien oder Verzeichnisse (rekursiv) zu entfernen, ohne dabei eine Arbeitskopie zu verwenden. Jedes Mal, wenn Sie einen dieser Befehle aufrufen, kommuniziert der Client mit dem Server auf eine ähnliche Art wie wenn er eine Übertragung eines hinzugefügten Verzeichnisses oder eines aus der Arbeitskopie entfernten Objektes beschreiben würde. Wenn kein Problem oder Konflikt bei der gewünschten Operation auftaucht, überträgt der Server die hinzugefügten oder entfernten Objekte in einer einzelnen neuen Revision.

Sie können svn copy oder svn move mit zwei URLs verwenden, einen Kopier-/Verschiebe-Ursprung und ein Ziel, um eine Kopie und eine Verschiebung von Dateien direkt im Projektarchiv zu übertragen. Diese Operationen neigen dazu, unter die teuersten zu fallen, wenn sie in einer Arbeitskopie ausgeführt werden, doch benötigen sie nur eine konstante Zeit, wenn sie aus der Ferne mit Projektarchiv-URLs ausgeführt werden. Eigentlich wird der entfernt ausgeführte Befehl svn copy gewöhnlich verwendet, um Zweige in Subversion anzulegen, was wir später in „Erzeugen eines Zweiges“ erörtern werden.

Wie mit dem normalen Befehl svn commit können Sie jedem dieser bisher besprochenen Befehle eine Protokollnachricht mitgeben, die Ihre Änderungen beschreibt. Verwenden Sie die Option --file (-F) oder --message (-m) oder erlauben Sie stattdessen dem Client, Sie aufzufordern, eine Protokollnachricht einzugeben.

Zum Schluss gibt es noch eine Anzahl Operationen in Verbindung mit unversionierten Revisions-Eigenschaften, die direkt auf dem Projektarchiv ausgeführt werden können. Revisions-Eigenschaften sind tatsächlich etwas einzigartig in diesem Zusammenhang, da sie nicht in der Arbeitskopie gespeichert werden und somit ohne Zusammenwirken mit einer Arbeitskopie geändert werden müssen. Siehe „Eigenschaften“ für eine detailliertere Beschreibung zur Verwaltung von Eigenschaften in Subversion.

Eine Schwäche der vom Kommandozeilen-Client gelieferten Unterstützung von Übertragungs-Operationen aus der Ferne liegt darin, dass Sie im Wesentlichen auf eine Operation – oder vielmehr eine Art der Operation – pro Übertragung beschränkt sind. Es ist völlig normal und es wird auch unterstützt, wenn svn delete gefolgt von svn mkdir innerhalb einer Arbeitskopie verwendet werden, um ein bestehendes versioniertes Verzeichnis durch ein nagelneues zu ersetzen. Wenn Sie das Ergebnis dieser Operationen übertragen, wird im Projektarchiv eine einzelne Revision erzeugt, die die vollständige Ersetzung Ihres Verzeichnisses umfasst. Das Gleiche können Sie jedoch nicht durch Operationen des Kommandozeilen-Clients aus der Ferne erreichen, wenn gleichzeitig die Alles-in-einer-Revision-Haftigkeit der Änderung beibehalten werden soll – svn delete URL würde eine neue Revision erzeugen, die das Verzeichnis entfernt hätte; svn mkdir URL würde für die Neuerstellung des Verzeichnisses eine zweite Revision erzeugen.

Glücklicherweise stellt Subversion ein separates Werkzeug zur Verfügung, das es nur gibt, um Anwendern zu erlauben, eine Menge von Operationen aus der Ferne zusammenzustellen und sie als atomare Änderung zu übertragen. Dieses Werkzeug ist svnmucc – Subversion Multiple URL Command Client:

$ svnmucc --help
Subversion Multi-URL-Kommando Client
Aufruf: svnmucc AKTION...

  Führt eine oder mehrere AKTIONen auf URLs von Subversion Projektarchiven aus,
  mit Übertragung des Ergebnisses als eine neue Revision.

Aktionen:
  cp REV QUELL-URL ZIEL-URL : kopiert QUELL-URL@REV nach ZIEL-URL
  mkdir URL                 : erzeugt neues Verzeichnis URL
  mv QUELL-URL ZIEL-URL     : verschiebt QUELL-URL nach ZIEL-URL
  rm URL                    : löscht URL
  put QUELL-DATEI URL       : legt Inhalt von QUELL-DATEI in URL ab, ggf. als Hinzufügung
                              (Die Angabe von \"-\" liest Inhalt aus der Standardeingabe)
  propset NAME WERT URL     : setzt Eigenschaft NAME der URL auf WERT
  propsetf NAME DATEI URL   : setzt Eigenschaft NAME der URL, liest Wert aus DATEI
  propdel NAME URL          : löscht Eigenschaft NAME von URL
…

svnmucc ist bereits seit vielen Jahren Teil des Quelltextbaums des Subversion Projekts (für die meiste Zeit als mucc), doch erst mit Subversion 1.8 wurde es vollständig unterstütztes Mitglied der Sammlung von Subversions Kommandozeilen-Werkzeugen.

Das Werkzeug svnmucc kann mit Ihren versionierten Daten jede Veränderung vornehmen, wie svn selbst. Anders als bei svn ist jedoch die Funktionalität, die svnmucc bietet, nicht auf Unterbefehle aufgebrochen. Stattdessen liefern Sie eine Liste mit Aktionen und Operanden auf einer einzelnen Kommandozeile (oder aus einem Dateistrom über die Option --extra-args (-X)). Einige der von svnmucc unterstützten Aktionen ahmen jene des Kommandozeilen-Clients nach. Sie werden in der Ausgabe des vorangegangenen Befehls Aktionen wie cp, mkdir, mv und rm entdecken, die allesamt sehr ähnlich denjenigen Befehlen sind, die wir in „Operationen mit einem Kommandozeilen-Client aus der Ferne“ erwähnt haben. Denken Sie jedoch daran, das der entscheidende Unterschied darin besteht, dass sie eine beliebige Anzahl dieser Aktionen gemeinsam in einem Befehlsaufruf verwenden können, der eine einzige übertragene Revision im Projektarchiv als Ergebnis hat.

Nehmen wir unser voriges Beispiel, bei dem versucht wurde, einfach ein Verzeichnis aus der Ferne zu ersetzen. Unter Verwendung von svnmucc würden Sie das wie folgt erreichen:

$ svnmucc rm http://svn.example.com/projects/sandbox \
          mkdir http://svn.example.com/projects/sandbox \
          -m "Replace my old sandbox with a fresh new one."
r22 committed by harry at 2013-01-15T21:45:26.442865Z
$ 

Wie Sie sehen können, erreichte svnmucc mit einer einzelnen Revision, für dessen Vervollständigung svn – ohne den Vorteil einer Arbeitskopie – zwei Revisionen benötigte.

	Warnung
	Ein weiterer Unterschied zwischen svnmucc und svn besteht darin, dass ersteres Sie momentan nicht auffordert, eine Protokollnachricht einzugeben, falls Sie versäumt haben, eine über die Kommandozeile zu liefern. Stattdessen wird es eine vorbereitete (d.h., ziemlich nutzlose) Protokollnachricht verwenden.

Das Werkzeug svnmucc ist nicht darauf beschränkt, lediglich Aktionen neu zusammenzumixen, die svn selbst machen könnte. Es führt etwas zusätzliche Funktionalität ein, die im Kommandozeilen-Client nicht vorhanden ist. So können Sie beispielsweise die Aktion put benutzen, um eine Datei im Projektarchiv hinzuzufügen oder zu ändern, indem der neue Inhalt der Datei entweder aus einer lokalen Datei Ihres Rechners oder aus Daten stammt, die über eine Pipe in den Standardeingabekanal geleitet werden. Das Werkzeug bietet ebenfalls die Aktionen propset, propsetf und propdel, die nützlich sind, um Eigenschaften auf versionierten Dateien oder Verzeichnissen zu setzen (entweder explizit oder durch das Kopieren des Eigenschaftswertes aus einer lokalen Datei) oder zu löschen. Gegenwärtig werden diese Aktionen vom Kommandozeilen-Client nicht unterstützt.

An diese Stelle erscheint es jedoch weise, zu erörtern, worin der Unterschied besteht, was mit svnmucc gemacht werden kann und was getan werden sollte. Ein Paar bemerkenswerter Zitate kommt in den Sinn:

Inhärent bei Änderungen ohne Arbeitskopie ist der Verlust genau derjenigen Schutzmaßnahmen die Konflikte erkennen und deshalb Arbeitskopien so wertvoll machen. Bei Verwendung von svn auf die typische Weise werden Änderungen gegenüber einer bestimmten Ausgangsversion einer Datei oder eines Verzeichnisses an den Server übertragen, so dass Sie nicht versehentlich Änderungen überschreiben, die gleichzeitig von einem anderen Teammitglied an demselben Objekt vorgenommen wurden. Der Server weiß, welche Version der Datei Sie hatten, bevor Sie sie geändert haben, und er weiß, ob andere Leute dieselbe Datei seit der Erstellung dieser Revision geändert haben. Das sind all die Informationen, die der Server benötigt, um Ihre Übertragung zurückzuweisen, wenn sie die Änderungen anderer zunichte machen würde, so dass Sie zunächst dazu gezwungen sind, deren Änderungen in Ihre Arbeitskopie zu integrieren und dann Ihre eigene Änderung nachzuprüfen. Da sich hier keine Arbeitskopie einmischt, gibt Ihnen svnmucc tatsächlich die Macht, diese Schutzmaßnahmen zu umgehen und so zu handeln, als sei der aktuelle Stand des Projektarchivs genau der Ausgangszustand Ihrer Arbeit. Doch es ist hoffentlich offensichtlich für Sie, dass Sie diese Macht nicht ungeniert ausüben sollten.

Glücklicherweise erlaubt Ihnen svnmucc, zurückhaltender bei der Verwendung des Werkzeugs zu handeln. Um einen Schutzmechanismus ähnlich dem einer Arbeitskopie anzubieten, bietet svnmucc eine Option --revision (-r). Mit dieser Option geben Sie manuell eine Ausgangsrevision für die Änderungen an, die Sie übertragen möchten. Die von Ihnen gewählte Ausgangsrevision ist idealerweise die letzte Revision Ihres Projektarchivs, von der Sie begründete Kenntnis haben.

	Warnung
	Anwendern wird dringend nahegelegt, die Option --revision (-r) mit svnmucc zu verwenden, und das auf korrekte Weise.

Am besten zeigt die richtige Benutzung der Aktion svnmucc put, wie diese Option --revision (-r) verwendet werden sollte. Angenommen, Harry möchte den Inhalt einer versionierten README-Datei ändern, ohne sich die Mühe zu machen, eine vollständige Arbeitskopie auszuchecken. (Wir gehen davon aus, das es keinen weiteren Grund gibt, eine Arbeitskopie für diese Operation zu verwenden, etwa das Vorhandensein von Skripten, die Harry vorher laufen lassen sollte, um sicherzustellen, das seine Übertragung sinnvoll ist.) Die erste Entscheidung, die er treffen muss ist, mit welcher Revision der Datei er arbeiten möchte. Normalerweise möchten Anwender die letzte Version einer Datei ändern. Also schaut Harry nach, in welcher die Datei zuletzt geändert wurde und verwendet diese Revision, um den Inhalt der Datei in eine temporäre lokale Datei zu holen:

$ svn info http://svn.example.com/projects/sandbox/README
Pfad: README
URL: http://svn.example.com/projects/sandbox/README
Relative URL: ^/sandbox/README
Basis des Projektarchivs: http://svn.example.com/projects
UUID des Projektarchivs: 13f79535-47bb-0310-9956-ffa450edef68
Revision: 22
Knotentyp: Datei
Letzter Autor: sally
Letzte geänderte Rev: 14
Letztes Änderungsdatum: 2012-09-02 10:34:09 -0400 (So, 02. Sep 2012)

$ svn cat -r 14 http://svn.example.com/projects/sandbox/README \
      > README.tmpfile
$

Harry besitzt nun eine Kopie der Datei README, so wie sie nach ihrer letzten Änderung aussah. Er macht seine gewünschten Änderungen an der Datei. Nachdem er fertig ist, möchte er diese Änderungen natürlich zum Projektarchiv übertragen.

Falls Harry nun so naiv ist und an dieser Stelle svnmucc put … verwendet, um den Inhalt von README im Projektarchiv mit seinem lokal geänderten Inhalt zu ersetzen, hat er genau die Macht missbraucht, die svnmucc gewährt. Was wäre, wenn nur Mikrosekunden vor seiner Übertragung auch Sally die Datei README bearbeitet hätte? Anders als das Programm svn wird svnmucc nicht irgendeine serverseitige Zusammenführung versuchen, um die Änderungen beider Anwender zu bewahren. Stattdessen wird svnmucc sorglos die aktuell letzte Version der Datei mit dem angegebenen Inhalt ersetzen. Harry bekommt davon nichts mit. Sally wird wütend sein.

$ svnmucc put README.tmpfile \
          http://svn.example.com/projects/sandbox/README \
          -m "Tweak the README file."
r24 committed by harry at 2013-01-21T16:21:23.100133Z
$
Message from sally@shell.example.com on pts/2 at 16:26 ...
Wir müssen mal ein Wörtchen wechseln. SOFORT!
EOF

Harry sollte sich stattdessen an die ursprüngliche Revision erinnern, auf die er seine Änderungen machte, und diese Revision mit der Option --revision (-r) an svnmucc zu übergeben, um damit dem Server die Möglichkeit zu geben, seine Übertragung zurückzuweisen, falls er versucht ein, durch seine (vielleicht unwissentliche) Erlaubnis, überholtes Objekt zu ändern:

$ svnmucc -r 14 put README.tmpfile \
          http://svn.example.com/projects/sandbox/README \
          -m "Tweak the README file."
svnmucc: E170004: Eintrag »/sandbox/README« ist veraltet
$

Wie bei anderen Optionen von svnmucc ist der Gültigkeitsbereich der Option --revision (-r) global für der gesamten Befehl – für jede Aktion, die in diesem Befehl angegeben wird. Das bietet Ihnen die gleiche Art an Schutzmaßnahmen, die Sie hätten, wenn Sie eine Arbeitskopie des gesamten Projektarchivs ausgecheckt hätten (und somit eine Arbeitskopie bestehend aus einer einzelnen, einheitlichen Revision), daran Änderungen vorgenommen hätten und dann all diese Änderungen auf einmal übertragen hätten.

Wie Sie sehen, ist svnmucc eine praktische Ergänzung zur Werkzeugkiste des Subversion-Anwenders. Für eine vollständige Referenz dessen, was dieses Werkzeug anzubieten hat, siehe svnmucc-Referenz – Subversion Multi-URL-Kommando Client.