Das Programm svnadmin ist der beste Freund des Projektarchiv-Administrators. Neben der Fähigkeit, Subversion-Projektarchive zu erzeugen, erlaubt Ihnen dieses Programm verschiedene Wartungsarbeiten auf diesen Projektarchive auszuführen. Die Syntax von svnadmin ist ähnlich wie bei anderen Kommandozeilenprogrammen von Subversion:

$ svnadmin help
Aufruf: svnadmin UNTERBEFEHL ARCHIV_PFAD [Optionen & Parameter ...]
Geben Sie »svnadmin help <Unterbefehl>« ein, um Hilfe zu einem Unterbefehl
          zu erhalten.
Geben Sie »svnadmin --version« ein, um die Programmversion und die Datei-
          systemmodule zu sehen.

Verfügbare Unterbefehle:
   crashtest
   create
   deltify
…

Früher in diesem Kapitel (in „Anlegen des Projektarchivs“), wurde uns der Unterbefehl svnadmin create vorgestellt. Die meisten anderen Unterbefehle von svnadmin werden wir später in diesem Kapitel behandeln. Und in „svnadmin – Subversion Projektarchiv-Verwaltung“ in Kapitel 9, Die vollständige Subversion Referenz können Sie in einer vollständigen Aufstellung der Unterbefehle nachlesen, was jeder zu bieten hat.

svnlook ist ein von Subversion mitgeliefertes Dienstprogramm zum Untersuchen der mannigfaltigen Revisionen und Transaktionen (bei denen es sich um Revisionen in Entstehung handelt) in einem Projektarchiv. Kein Teil dieses Programms versucht, das Projektarchiv zu verändern. svnlook wird üblicherweise von Projektarchiv-Hooks verwendet, um die abzuliefernden Änderungen zu melden (im Fall des pre-commit-Hooks) oder die gerade an das Projektarchiv übertragen wurden (im Fall des post-commit-hooks). Ein Projektarchiv-Administrator kann dieses Programm zur Diagnose benutzen.

svnlook besitzt eine überschaubare Syntax:

$ svnlook help
Aufruf: svnlook UNTERBEFEHL ARCHIV_PFAD [Optionen & Parameter ...]
Hinweis: Alle Unterbefehle, die die Parameter »--revision« und »--transaction«
         akzeptieren, werden ohne diese Parameter die neueste
         Revision des Projektarchivs verwenden.
Geben Sie »svnlook help <Unterbefehl>« ein, um Hilfe zu einem Unterbefehl
         zu erhalten.
Geben Sie »svnlook --version« ein, um die Programmversion und die Datei-
         systemmodule zu sehen.
…

Die meisten Unterbefehle von svnlook können entweder auf einem Revisions- oder auf einem Transaktionsbaum arbeiten, indem sie Informationen über den Baum an sich ausgeben oder darüber, inwiefern er sich von einer früheren Revision des Projektarchivs unterscheidet. Sie verwenden die Optionen --revision (-r) und --transaction (-t), um die zu untersuchende Revision bzw. Transaktion anzugeben. Ohne eine der Optionen --revision (-r) und --transaction (-t) untersucht Subversion die jüngste (oder HEAD) Revision des Projektarchivs. Das heißt, die beiden folgenden Befehle machen genau dasselbe, wenn 19 die jüngste Revision im Projektarchiv unter /var/svn/repos ist:

$ svnlook info /var/svn/repos
$ svnlook info /var/svn/repos -r 19

Eine Ausnahme von diesen Regeln zu Unterbefehlen ist der Unterbefehl svnlook youngest, der keine Optionen entgegennimmt und einfach die jüngste Revisionsnummer des Projektarchivs ausgibt:

$ svnlook youngest /var/svn/repos
19
$

	Anmerkung
	Beachten Sie, dass Sie nur Transaktionen untersuchen können, die noch nicht übergeben sind. Die meisten Projektarchive haben keine derartigen Transaktionen, da Transaktionen entweder übergeben (in diesem Fall sollten Sie darauf mit der Option --revision (-r) zugreifen) oder abgebrochen und entfernt sind.

Die Ausgabe svnlook ist so gestaltet, dass sie sowohl für Menschen als auch für Maschinen lesbar ist. Nehmen wir zum Beispiel die Ausgabe des Unterbefehls svnlook info:

$ svnlook info /var/svn/repos
sally
2002-11-04 09:29:13 -0600 (Mo, 04. Nov 2002)
43
Den üblichen griechischen
Baum hinzugefügt.
$

Die Ausgabe von svnlook info besteht aus dem Folgenden in entsprechender Reihenfolge:

Diese Ausgabe ist für Menschen lesbar, d.h., Dinge wie der Zeitstempel werden als Text dargestellt statt als irgendetwas Obskures (wie die Anzahl der Nanosekunden seit der Mann von Bofrost das letzte Mal da war). Jedoch ist die Ausgabe auch maschinenlesbar – weil die Protokollnachricht mehrere Zeilen umfassen und von der Länge her unbegrenzt sein kann, liefert svnlook die Länge der Nachricht vor der eigentlichen Nachricht. Das erlaubt Skripten und anderen Programmen, die um diesen Befehl herum geschrieben wurden, intelligente Entscheidungen in Bezug auf die Protokollnachricht zu treffen, etwa wie viel Speicher für die Nachricht anzufordern ist oder zumindest wie viele Bytes zu überspringen sind, falls diese Ausgabe nicht das letzte Stück im Datenstrom sein sollte.

svnlook kann eine Auswahl anderer Abfragen ausführen: Teilmengen der bereits erwähnten Informationen ausgeben, versionierte Verzeichnisbäume rekursiv auflisten, berichten, welche Pfade in einer bestimmten Revision oder Transaktion verändert wurden, textuelle und property-basierte Unterschiede an Dateien und Verzeichnissen aufzeigen, usw. Siehe „svnlook – Subversion Projektarchiv-Untersuchung“ in Kapitel 9, Die vollständige Subversion Referenz für eine vollständige Referenz der Funktionen von svnlook.

Obwohl es nicht das am meisten verwendete Werkzeug im Sortiment des Administrators sein wird, bietet svndumpfilter eine ganz besondere Art von nützlichen Funktionen – die Fähigkeit, schnell und einfach Datenströme aus der Projektarchiv-Historie zu verändern, indem es als ein pfadbasierter Filter arbeitet.

Die Syntax von svndumpfilter lautet wie folgt:

$ svndumpfilter help
Aufruf: svndumpfilter UNTERBEFEHL [Optionen & Parameter ...]
Geben Sie »svndumpfilter help <Unterbefehl>« ein, um Hilfe zu einem
          Unterbefehl zu erhalten.
Geben Sie »svndumpfilter --version« ein, um die Programmversion zu sehen.

Verfügbare Unterbefehle:
   exclude
   include
   help (?, h)

Es gibt nur zwei interessante Unterbefehle: svndumpfilter exclude und svndumpfilter include. Sie erlauben Ihnen, zwischen einer impliziten oder expliziten Einbeziehung von Pfaden im Datenstrom zu wählen. Sie können mehr über diese Unterbefehle und den einzigartigen Zweck von svndumpfilter später in diesem Kapitel unter „Filtern der Projektarchiv-Historie“ erfahren.

Das Programm svnrdump ist einfach im Wesentlichen eine Kombination netzfähiger Ausprägungen der Unterbefehle svnadmin dump und load.

$ svnrdump help
general usage: svnrdump SUBCOMMAND URL [-r LOWER[:UPPER]]
Type 'svnrdump help <subcommand>' for help on a specific subcommand.
Type 'svnrdump --version' to see the program version and RA modules.

Available subcommands:
   dump
   load
   help (?, h)

$

Wir wedden sie Verwendung von svnrdump und dem vorher erwähnten Befehl svnadmin später in diesem Kapitel erörtern (siehe „Projektarchiv-Daten woanders hin verschieben“).

Der Befehl svnsync, der in Subversion 1.4 neu hinzugekommen ist, bietet Funktionen zum Verwalten eines Nur-Lese-Spiegels des Subversion-Projektarchivs. Das Programm hat eine Aufgabe – die versionierte Historie eines Projektarchivs in ein anderes zu übertragen. Und während es nicht viele Möglichkeiten gibt, dies zu tun, liegt seine hauptsächliche Stärke darin, das es aus der Ferne eingesetzt werden kann – das „Quell“- und „Ziel“-Projektarchiv können auf verschiedenen Rechnern liegen und auf einem anderen Rechner als svnsync selbst.

Wie Sie vielleicht erwarten, hat svnsync eine Syntax, die allen anderen Programmen aus diesem Kapitel gleicht:

$ svnsync help
Aufruf: svnsync UNTERBEFEHL ZIEL_URL [Optionen & Parameter ...]
Geben Sie »svnsync help <Unterbefehl>« ein, um Hilfe zu einem
          Unterbefehl zu erhalten.
Geben Sie »svnsync --version« ein, um die Programmversion und die Zugriffs-
          module zu sehen.

Verfügbare Unterbefehle:
   initialize (init)
   synchronize (sync)
   copy-revprops
   info
   help (?, h)

$

Später in diesem Kapitel werden wir mehr über das Replizieren von Projektarchiven mit svnsync reden (siehe „Projektarchiv Replikation“).

Obwohl es kein offizielles Glied in der Werkzeugkette von Subversion ist, handelt es sich bei dem Skript fsfs-reshard.py (zu finden im Verzeichnis tools/server-side des Subversion-Quelltext-Paketes) um ein nützliches Werkzeug zur Leistungssteigerung für Administratoren von FSFS-basierten Subversion-Projektarchiven. Wie in der Randnotiz Revisionsdateien und Scherben beschrieben, verwenden FSFS-Projektarchive einzelne Dateien, die die zu einer Revision gehörenden Eigenschaften beherbergen. Manchmal liegen alle dieser Dateien in einem einzelnen Verzeichnis; manchmal werden sie über viele Verzeichnisse verteilt. Eine saubere Sache ist, dass die Anzahl der Verzeichnisse zur Aufnahme dieser Dateien konfiguriert werden kann.

fsfs-reshard.py mischt die Dateistruktur des Projektarchivs, indem es sie gemäß der Anzahl der gewünschten Unterverzeichnisse neu anordnet und die Konfiguration des Projektarchivs aktualisiert, um diese Änderung zu bewahren. In Verbindung mit dem Befehl svnadmin upgrade erweist sich das als besonders nützlich, wenn ein Projektarchiv aus der Zeit vor Subversion 1.5 (mit unverteilten Verwaltungsdateien) in das neueste Dateisystem-Format überführt werden soll und dessen Dateien aufteilt (was Subversion nicht automatisch für Sie macht). Dieses Skript kann ebenfalls dazu verwendet werden, um ein bereits aufgeteiltes Projektarchiv noch feiner einzustellen.

Falls Sie ein Projektarchiv verwenden, das auf Berkeley DB basiert, befindet sich die gesamte Struktur und die Daten Ihres versionierten Dateisystems in einer Menge von Datenbanktabellen innerhalb des Unterverzeichnisses db/ Ihres Projektarchivs. Dieses Unterverzeichnis ist ein gewöhnliches Verzeichnis einer Berkeley-DB-Umgebung und kann deshalb mit irgendeinem der Berkeley Datenbankwerkzeuge verwendet werden, die normalerweise mit Berkeley DB ausgeliefert werden.

Für die tägliche Arbeit mit Subversion werden diese Werkzeuge nicht benötigt. Die meisten Funktionen, die üblicherweise für Subversion-Projektarchive gebraucht werden, sind in svnadmin integriert worden. Beispielsweise liefern svnadmin list-unused-dblogs und svnadmin list-dblogs eine Teilmenge dessen, was vom Berkeley-Dienstprogramm db_archive angeboten wird, und svnadmin recover spiegelt die verbreiteten Anwendungsfälle von db_recover wieder.

Trotzdem gibt es noch ein paar Berkeley-DB-Werkzeuge, die Ihnen nützlich sein könnten. Die Programme db_dump und db_load schreiben bzw. lesen ein spezielles Dateiformat, das die Schlüssel und Werte in einer Berkeley-DB-Datenbank beschreibt. Da Berkeley-Datenbanken nicht zwischen Rechnerarchitekturen portierbar sind, stellt dieses Format ein nützliches Verfahren zur Übertragung der Datenbanken zwischen Maschinen zur Verfügung, wobei die Architektur oder das Betriebssystem keine Rolle spielen. Später in diesem Kapitel werden wir noch beschreiben, wie Sie auch svnadmin dump und svnadmin load für ähnliche Zwecke verwenden können, doch db_dump und db_load können bestimmte Aufgaben genauso gut und viel schneller erledigen. Sie können auch dabei dienlich sein, wenn der erfahrene Berkeley-DB-Hacker aus irgendwelchen Gründen die Daten in einem BDB-basierten Projektarchiv direkt vor Ort anpassen muss, was die Dienstprogramme von Subversion nicht erlauben. Ferner liefert das Dienstprogramm db_stat nützliche Informationen über den Zustand Ihrer Berkeley-DB-Umgebung, wozu ausführliche Statistiken über das Sperr- und Speicher-Teilsystem gehören.

Besuchen Sie für weitergehende Informationen zur Berkeley-Werkzeugsammlung den Dokumentationsabschnitt der Berkeley-DB-Abteilung auf der Seite von Oracle bei http://www.oracle.com/technology/documentation/berkeley-db/db/.

Um das Projektarchiv klein zu halten, verwendet Subversion innerhalb des Projektarchivs Delta-Kodierung (oder Deltaspeicherung). Unter Delta-Kodierung wird die Kodierung eines Datensatzes als eine Sammlung von Unterschieden gegenüber einem anderen Datensatz verstanden. Falls die beiden Datensätze sehr ähnlich sind, bewirkt diese Delta-Kodierung eine Einsparung an Speicherplatz für den als Delta gespeicherten Datensatz – anstatt den Platz der Originaldaten zu belegen, wird hierbei nur soviel Platz benötigt, um zu sagen: „Schau mal, ich sehe genau so aus, wie der andere Datensatz da drüben, bis auf die folgenden paar Änderungen.“ Das Ergebnis ist, dass die meisten der Daten im Projektarchiv, die normalerweise recht voluminös sind – nämlich der Inhalt versionierter Dateien – in einer viel geringeren Größe gespeichert werden als der ursprüngliche Volltext dieser Daten.

Während die delta-kodierte Speicherung bereits von Anfang an ein Teil des Designs von Subversion gewesen ist, sind im Laufe der Jahre zusätzliche Verbesserungen vorgenommen worden. Subversion Projektarchive, die mit Subversion 1.4 oder neuer erstellt worden sind, ziehen Nutzen aus der Komprimierung der Volltext-Repräsentierung von Dateiinhalten. Projektarchiv, die mit Subversion 1.6 oder neuer erstellt worden sind, genießen darüber hinaus den durch geteilte Repräsentierung gesparten Plattenplatz, eine Funktionalität, die es mehreren Dateien oder Dateirevisionen mit identischen Dateiinhalt erlaubt, auf eine einzelne geteilte Instanz dieser Daten zu verweisen, anstatt eine eigene, getrennte Kopie davon vorhalten zu müssen.

Anmerkung

Da alle delta-kodierten Daten in einem BDB-basierten Projektarchiv in einer einzigen Berkeley-DB-Datenbankdatei gespeichert werden, wird die verringerte Größe der gespeicherten Werte nicht unmittelbar die Größe der Datenbankdatei verringern. Berkeley DB führt jedoch intern Buch über unbenutzte Bereiche der Datenbankdatei und wird zunächst jene aufbrauchen, bevor die Datenbankdatei selbst vergrößert wird. Während Delta-Kodierung also nicht unmittelbare Platzersparnis bringt, kann sie jedoch das künftige Wachstum der Datenbank drastisch verlangsamen.

Obwohl es selten vorkommt, gibt es Umstände, unter denen der Übergabeprozess mit einem Fehler abbricht und die Reste einer Revision in Spe hinterlässt – eine unvollendete Transaktion samt aller Datei- und Verzeichnisänderungen, die dazugehören. Dies kann aus verschiedenen Gründen passieren: Vielleicht wurde die Operation des Clients vom Benutzer unsauber beendet oder es trat mittendrin ein Netzfehler auf. Aus welchem Grund auch immer, es können unvollendete Transaktionen auftreten. Sie verursachen keine tatsächlichen Schäden, außer Plattenplatz zu verschwenden. Ein penibler Administrator möchte sie vielleicht dennoch entfernen.

Sie können den Befehl svnadmin lstxns verwenden, um die Namen der aktuell ausstehenden Transaktionen anzuzeigen:

$ svnadmin lstxns myrepos
19
3a1
a45
$

Jeder Eintrag der Ausgabe kann dann mit dem Befehl svnlook (und seiner Option --transaction (-t)) aufgerufen werden, um festzustellen, wer die Transaktion erzeugt hat, wann sie erzeugt wurde und welche Änderungen sie beinhaltet – Informationen, die bei der Entscheidung helfen können, ob eine Transaktion ein sicherer Kandidat zum Löschen ist! Wenn Sie tatsächlich eine Transaktion löschen wollen, kann deren Name an den Befehl svnadmin rmtxns übergeben werden, der dann die Transaktion aufräumt. svnadmin rmtxns kann seine Eingabe auch direkt aus der Ausgabe von svnadmin lstxns beziehen!

$ svnadmin rmtxns myrepos `svnadmin lstxns myrepos`
$

Falls Sie auf diese Weise diese beiden Unterbefehle verwenden, sollten Sie vorübergehend das Projektarchiv für Clients unzugänglich machen. So kann niemand eine berechtigte Transaktion beginnen, bevor Sie aufgeräumt haben. Beispiel 5.1, „txn-info.sh (ausstehende Transaktionen anzeigen)“ enthält ein kleines Shell-Skript, das schnell eine Übersicht über jede ausstehende Transaktion in Ihrem Projektarchiv erzeugen kann.

#!/bin/sh

### Erzeuge Informationen über alle ausstehenden Transaktionen eines
### Subversion Projektarchivs.

REPOS="${1}"
if [ "x$REPOS" = x ] ; then
  echo "Aufruf: $0 REPOS_PATH"
  exit
fi

for TXN in `svnadmin lstxns ${REPOS}`; do 
  echo "---[ Transaktion ${TXN} ]-------------------------------------------"
  svnlook info "${REPOS}" -t "${TXN}"
done

Die Ausgabe des Skriptes ist im Grunde genommen eine Aneinanderreihung mehrerer Teile von svnlook info-Ausgaben (siehe „svnlook“) und sieht etwa so aus:

$ txn-info.sh myrepos
---[ Transaktion 19 ]-------------------------------------------
sally
2001-09-04 11:57:19 -0500 (Di, 04. Sep 2001)
0
---[ Transaktion 3a1 ]-------------------------------------------
harry
2001-09-10 16:50:30 -0500 (Mo, 10. Sep 2001)
39
Versuch, über eine schlechte Netzverbindung abzuliefern.
---[ Transaktion a45 ]-------------------------------------------
sally
2001-09-12 11:09:28 -0500 (Mi, 12. Sep 2001)
0
$

Eine vor langer Zeit aufgegebene Transaktion bedeutet normalerweise eine Art fehlgeschlagenen oder unterbrochenen Übergabeversuch. Der Zeitstempel einer Transaktion kann eine interessante Information sein – ist es beispielsweise wahrscheinlich, dass eine vor neun Monaten begonnene Operation immer noch aktiv ist?

Kurz gesagt, Entscheidungen zur Bereinigung von Transaktionen sollten klug getroffen werden. Verschiedene Informationsquellen – hierzu gehören die Fehler- und Zugriffsprotokolldateien von Apache, die operativen Protokolldateien von Subversion, die Revisions-Historie von Subversion usw. – können während des Entscheidungsprozesses hinzugezogen werden. Natürlich kann sich ein Administrator auch einfach mit dem Eigentümer einer anscheinend abgebrochenen Transaktion in Verbindung setzen (z.B., per E-Mail), um sicherzustellen, dass die Transaktion sich tatsächlich in einem Zombiezustand befindet.

Bis vor kurzer Zeit waren die größten Plattenplatzfresser bei BDB-basierten Subversion-Projektarchive die Protokolldateien, in die Berkeley DB zunächst alle Schritte hineinschreibt, bevor es die eigentlichen Datenbankdateien verändert. Diese Dateien halten alle Aktionen der Datenbank auf dem Weg von einem Zustand zum nächsten fest – während die Datenbankdateien zu jeder Zeit einen bestimmten Zustand widerspiegeln, beinhalten die Protokolldateien all die vielen Änderungen auf dem Weg zwischen den Zuständen. Somit können sie sehr schnell wachsen und sich anhäufen.

Glücklicherweise hat die Datenbankumgebung beginnend mit der Version 4.2 der Berkeley DB die Fähigkeit, ihre eigenen unbenutzten Protokolldateien automatisch zu entfernen. Alle Projektarchive, die mit einem svnadmin angelegt wurden, das mit Berkeley DB Version 4.2 oder später übersetzt wurde, werden mit automatischer Protokolldateientfernung konfiguriert. Wenn Sie diese Funktion nicht möchten, geben Sie dem Befehl svnadmin create einfach die Option --bdb-log-keep mit. Sollten Sie das vergessen oder es sich später anders überlegen, editieren Sie einfach die Datei DB_CONFIG im Verzeichnis db Ihres Projektarchivs indem Sie die Zeile mit der Direktive set_flags DB_LOG_AUTOREMOVE auskommentieren und starten dann svnadmin recover auf Ihrem Projektarchiv, um die Konfigurationsänderung zu aktivieren. Siehe „Konfiguration von Berkeley DB“ für weitere Informationen zur Datenbankkonfiguration.

Ohne eine Art automatische Protokolldateientfernung aktiviert zu haben, häufen sich die Protokolldateien während der Nutzung des Projektarchivs an. Es ist eigentlich ein Merkmal des Datenbanksystems – Sie sollten ausschließlich mit Hilfe der Protokolldateien in der Lage sein, Ihre gesamte Datenbank zu rekonstruieren, so dass diese Protokolldateien sehr nützlich für eine Wiederherstellung im Katastrophenfall sein können. Jedoch möchten Sie normalerweise die nicht mehr von Berkeley DB verwendeten Protokolldateien archivieren und sie zur Platzersparnis von der Platte entfernen. Verwenden Sie den Befehl svnadmin list-unused-dblogs, um die unbenutzten Protokolldateien anzuzeigen:

$ svnadmin list-unused-dblogs /var/svn/repos
/var/svn/repos/log.0000000031
/var/svn/repos/log.0000000032
/var/svn/repos/log.0000000033
…
$ rm `svnadmin list-unused-dblogs /var/svn/repos`

## Plattenplatz zurückgewonnen!

Warnung

BDB-basierte Projektarchive, deren Protokolldateien ein Bestandteil eines Sicherungs- oder Notfallplans sind, sollten nicht die automatische Entfernung verwenden. Die Wiederherstellung der Daten eines Projektarchivs kann nur gewährleistet werden, wenn alle Protokolldateien verfügbar sind. Falls einige der Protokolldateien von der Platte entfernt werden, bevor das Sicherungssystem die Gelegenheit bekommt, sie woandershin zu kopieren, ist die unvollständige Menge gesicherter Protokolldateien tatsächlich nutzlos.

Wie in der Anmerkung Revisionsdateien und Scherben beschrieben, erzeugen auf FSFS basierende Subversion-Projektarchive standardmäßig für jede dem Projektarchiv hinzugefügte Revision eine neue Datei auf der Platte. Wenn tausende dieser Dateien auf dem Subversion-Server liegen, kann dies ineffizient werden, selbst dann, wenn sie in getrennten Scherben-Verzeichnissen untergebracht sind.

Das erste Problem besteht darin, dass das Betriebssystem innerhalb kurzer Zeit auf viele verschiedene Dateien beziehen muss. Das führt zur ineffektiven Verwendung von Zwischenspeicherungen der Platte und hat zur Folge, dass bei großen Platten viel Zeit zum Suchen verbraucht wird. Daher kommt es beim Zugriff von Subversion auf versionierte Daten zu Leistungseinbußen.

Das zweite Problem ist etwas subtiler. Aufgrund der Art und Weise wie die meisten Dateisysteme Plattenplatz zuweisen, benötigt eine Datei mehr Platz, als sie eigentlich belegt. Der Umfang des zusätzlichen Platzes, um eine einzelne Datei unterzubringen, kann, je nach verwendetem Dateisystem durchschnittlich irgendwo zwischen 2 und 16 Kilobyte pro Datei liegen. Das bedeutet pro Revision eine Einbuße bei der Plattennutzung für Projektarchive auf FSFS Basis. Besonders deutlich wird der Effekt bei Projektarchiven mit vielen kleinen Revisionen, da hier platzmäßig die Kosten der Speicherung der Revisionsdatei schnell den Umfang der eigentlich zu speichernden Daten überschreiten.

Zur Lösung dieser Probleme führte Subversion 1.6 den Befehl svnadmin pack ein. Durch das Aneinanderfügen aller Dateien einer vollständigen Scherbe in eine einzelne „pack“-Datei und das anschließende Entfernen der ursprünglichen Dateien, die pro Revision angelegt wurden, verringert svnadmin pack die Anzahl der Dateien innerhalb einer gegebenen Scherbe auf nur eine einzelne Datei. Das kommt den Zwischenspeichern des Dateisystems entgegen und verringert die Anzahl der Kosten für Dateispeicherung auf eins.

Subversion kann bestehende zerlegte Projektarchive packen, die auf das Dateisystemformat von 1.6 oder neuer aktualisiert worden sind (siehe svnadmin upgrade in Kapitel 9, Die vollständige Subversion Referenz). Lassen Sie dafür einfach svnadmin pack über das Projektarchiv laufen:

$ svnadmin pack /var/svn/repos
Packe 0...erledigt.
Packe 1...erledigt.
Packe 2...erledigt.
…
Packe 34...erledigt.
Packe 35...erledigt.
Packe 36...erledigt.
$

Da der Packprozess die benötigten Sperren erlangt, bevor er seine Arbeit beginnt, können Sie ihn auf in Benutzung befindliche Projektarchive anwenden oder sogar als Teil eines Hooks nach der Übergabe. Das erneute Packen bereits gepackter Scherben ist legal, hat allerdings keine Auswirkungen auf den Plattenverbrauch des Projektarchivs.

svnadmin pack hat keine Auswirkungen auf Subversion-Projektarchive auf BDB-Basis.

Welche Gründe für den Umzug der Projektarchiv-Historie für Sie auch immer eine Rolle spielen, die Verwendung der Unterbefehle svnadmin dump und svnadmin load sind der direkte Weg. svnadmin dump gibt ein Intervall von Projektarchiv-Revisionen im speziellen Subversion-Auszugsformat aus. Der Auszug wird zur Standardausgabe geschrieben, während Mitteilungen an die Standardfehlerausgabe gehen. Das erlaubt Ihnen, den Ausgabestrom in eine Datei umzuleiten, während Sie Statusausgaben im Terminalfenster verfolgen können. Zum Beispiel:

$ svnlook youngest myrepos
26
$ svnadmin dump myrepos > dumpfile
* Revision 0 ausgegeben.
* Revision 1 ausgegeben.
* Revision 2 ausgegeben.
…
* Revision 25 ausgegeben.
* Revision 26 ausgegeben.

Am Ende haben Sie eine einzelne Datei (im vorangegangenen Beispiel dumpfile), die alle im Projektarchiv gespeicherten Daten aus dem gewählten Intervall von Revisionen beinhaltet. Beachten Sie, dass svnadmin dump wie jeder andere „lesende“ Prozess (z.B. svn checkout) Revisionsbäume aus dem Projektarchiv liest, so dass Sie diesen Befehl jederzeit aufrufen können.

Der andere Unterbefehl dieses Paars, svnadmin load, liest den Standardeingabestrom als eine Subversion-Projektarchiv-Auszugsdatei und spielt diese Revisionen aus dem Auszug gewissermaßen neu in das Ziel-Projektarchiv. Auch dieser Befehl erzeugt Meldungen, dieses Mal aber über die Standardausgabe:

$ svnadmin load newrepos < dumpfile
<<< Neue Transaktion basierend auf Originalrevision 1 gestartet
     * Füge Pfad hinzu: A ... erledigt.
     * Füge Pfad hinzu: A/B ... erledigt.
     …
------- Neue Revision 1 übertragen (geladen aus Original 1) >>>

<<< Neue Transaktion basierend auf Originalrevision 2 gestartet
     * Bearbeite Pfad: A/mu ... erledigt.
     * Bearbeite Pfad: A/D/G/rho ... erledigt.

------- Neue Revision 2 übertragen (geladen aus Original 2) >>>

…

<<< Neue Transaktion basierend auf Originalrevision 25 gestartet
     * Bearbeite Pfad: A/D/gamma ... erledigt.

------- Neue Revision 25 übertragen (geladen aus Original 25) >>>

<<< Neue Transaktion basierend auf Originalrevision 26 gestartet
     * Füge Pfad hinzu: A/Z/zeta ... erledigt.
     * Bearbeite Pfad: A/mu ... erledigt.

------- Neue Revision 26 übertragen (geladen aus Original 26) >>>

Das Ergebnis eines Ladevorgangs sind neue Revisionen, die dem Projektarchiv hinzugefügt wurden – dasselbe, was Sie erhalten, wenn Sie mit einem normalen Subversion-Client Übergaben an das Projektarchiv machen. Ebenso wie bei einer Übergabe können können Sie Hook-Programme verwenden, um Aktionen vor und nach jeder Übergabe während des Ladevorgangs auszuführen. Indem Sie die Optionen --use-pre-commit-hook und --use-post-commit-hook an svnadmin load übergeben, können Sie Subversion befehlen, für jede zu ladende Revision die Hook-Programme pre-commit bzw. post-commit auszuführen. Sie könnten diese beispielsweise verwenden, um sicherzustellen, dass die geladenen Revisionen dieselben Validierungsschritte durchlaufen müssen wie reguläre Übergaben. Natürlich sollten Sie diese Optionen mit Sorgfalt verwenden – wenn Ihr post-commit-Hook für jede neue Übergabe E-Mails an eine Mailing-Liste verschickt, wollen Sie bestimmt nicht, das innerhalb kürzester Zeit hunderte oder tausende Übergabe-E-Mails in diese Liste hineinhageln! Sie können mehr über Hook-Skripte in „Erstellen von Projektarchiv-Hooks“ lesen.

Beachten Sie, dass Menschen, die sich besonders gewitzt fühlen, weil svnadmin für den Auszug und den Ladevorgang den Standardeingabe- und den Standardausgabestrom benutzt, Dinge wie dieses ausprobieren können (vielleicht sogar unterschiedliche Versionen von svnadmin auf jeder Seite der Pipe):

$ svnadmin create newrepos
$ svnadmin dump oldrepos | svnadmin load newrepos

Im Normalfall wird die Auszugsdatei ziemlich groß – viel größer als das Projektarchiv selbst. Das liegt daran, dass standardmäßig jede Version jeder Datei als vollständiger Text in der Auszugsdatei dargestellt wird. Dies ist das schnellste und einfachste Verhalten, und es ist nett, wenn Sie die Auszugsdaten über eine Pipe direkt an einen weiteren Prozess weiterleiten (etwa ein Komprimierprogramm, ein Filterprogramm oder einen Prozess zum Laden). Wenn Sie jedoch eine Auszugsdatei für die Langzeitspeicherung erzeugen, möchten Sie wahrscheinlich Plattenplatz sparen, indem Sie die Option --deltas verwenden. Mit dieser Option werden aufeinanderfolgende Revisionen von Dateien als komprimierte binäre Unterschiede ausgegeben – so wie Dateirevisionen im Projektarchiv gespeichert werden. Diese Option ist langsamer, führt jedoch zu einer Größe der Auszugsdatei, die der Größe des Original-Projektarchivs näher kommt.

Wir haben eben erwähnt, dass svnadmin dump einen Bereich von Revisionen ausgibt. Verwenden Sie die Option --revision (-r), um eine einzelne Revision oder einen Bereich von Revisionen für den Auszug anzugeben. Wenn Sie diese Option weglassen, wird ein Auszug aller Projektarchiv-Revisionen erstellt.

$ svnadmin dump myrepos -r 23 > rev-23.dumpfile
$ svnadmin dump myrepos -r 100:200 > revs-100-200.dumpfile

Beim Erstellen eines Auszugs jeder Revision gibt Subversion gerade soviel Information aus, dass später ein Ladeprozess in der Lage ist, diese Revision auf der Basis der Vorgängerrevision wiederherzustellen. Mit anderen Worten: Für jede Revision befinden sich nur die Dinge in der Auszugsdatei, die sich in dieser Revision geändert haben. Die einzige Ausnahme von dieser Regel ist die erste Revision, die mit dem aktuellen svnadmin dump erstellt wird.

Standardmäßig wird Subversion den Auszug der ersten Revision nicht bloß als Unterschied ausdrücken, der auf die Vorgängerrevision anzuwenden ist. Zum Ersten gibt es keine Vorgängerrevision in der Auszugsdatei. Und zum Zweiten kann Subversion den Zustand des Projektarchivs, in das der Auszug (falls überhaupt) geladen werden soll, nicht kennen. Um sicherzustellen, dass die Ausgabe jedes Aufrufs von svnadmin dump unabhängig ist, ist der Auszug der ersten Revision standardmäßig eine vollständige Darstellung jedes Verzeichnisses, jeder Datei und jeder Eigenschaft aus dieser Revision im Projektarchiv.

Sie können dieses Standardverhalten jedoch ändern. Falls Sie die Option --incremental angeben, vergleicht svnadmin die erste Revision für die ein Auszug erstellt werden soll mit der vorhergehenden Revision im Projektarchiv – auf dieselbe Art und Weise, wie jede andere Revision behandelt wird, für die ein Auszug erstellt werden soll – indem lediglich die Änderungen aus dieser Revision erwähnt werden. Der Vorteil dabei ist, dass Sie mehrere kleinere Auszugsdateien erstellen können, die hintereinander geladen werden können, anstatt eine große:

$ svnadmin dump myrepos -r 0:1000 > dumpfile1
$ svnadmin dump myrepos -r 1001:2000 --incremental > dumpfile2
$ svnadmin dump myrepos -r 2001:3000 --incremental > dumpfile3

Diese Auszugsdateien können mit der folgenden Befehlsfolge in ein neues Projektarchiv geladen werden:

$ svnadmin load newrepos < dumpfile1
$ svnadmin load newrepos < dumpfile2
$ svnadmin load newrepos < dumpfile3

Ein weiterer toller Trick, den Sie mit der Option --incremental anwenden können besteht darin, einen neuen Bereich von Revisionsauszügen an eine existierende Revisionsdatei anzuhängen. Beispielsweise könnten Sie einen post-commit-Hook haben, der der Datei einen Auszug derjenigen Revision anfügt, die den Hook ausgelöst hat. Oder Sie haben ein Skript, das jede Nacht läuft, um Auszüge sämtlicher Revisionen seit dem letzten Lauf anzufügen. Wenn es auf diese Weise verwendet wird, stellt svnadmin dump eine Möglichkeit dar, laufend die Änderungen an Ihrem Projektarchiv für den Fall eines Systemabsturzes oder eines anderen katastrophalen Ereignisses zu sichern.

Das Auszugsformat kann auch dazu verwendet werden, um die Inhalte mehrerer verschiedener Projektarchive in ein Projektarchiv zusammenzuführen. Indem Sie die Option --parent-dir von svnadmin load benutzen, können Sie ein neues virtuelles Wurzelverzeichnis für den Ladevorgang angeben. Das heißt, falls Sie beispielsweise die Auszugsdateien von drei Projektarchiven haben – etwa calc-dumpfile, cal-dumpfile und ss-dumpfile – können Sie zunächst ein Projektarchiv anlegen, das alle beherbergt:

$ svnadmin create /var/svn/projects
$

Erstellen Sie dann neue Verzeichnisse im Projektarchiv, die den Inhalt der vorherigen drei Projektarchive aufnehmen werden:

$ svn mkdir -m "Initial project roots" \
            file:///var/svn/projects/calc \
            file:///var/svn/projects/calendar \
            file:///var/svn/projects/spreadsheet 
Revision 1 übertragen.
$ 

Laden Sie schließlich die Auszugsdateien an ihren jeweiligen Ort im neuen Projektarchiv:

$ svnadmin load /var/svn/projects --parent-dir calc < calc-dumpfile
…
$ svnadmin load /var/svn/projects --parent-dir calendar < cal-dumpfile
…
$ svnadmin load /var/svn/projects --parent-dir spreadsheet < ss-dumpfile
…
$

In Subversion 1.7 kam svnrdump zu der Menge von mitgelieferten Subversion-Werkzeugen hinzu. Es bietet eine ziemlich spezialisierte Funktionalität, im Wesentlichen als netzwerkfähige Version der Befehle svnadmin dump und svnadmin load, die wir im Detail in „Repository data migration using svnadmin“ erörtern. svnrdump dump erzeugt einen Auszugsstrom eines Fern-Projektarchivs und schreibt ihn in den Standard-Ausgabekanal; svnrdump load liest einen Auszugsstrom aus dem Standard-Eingabekanal und lädt ihn in ein Fern-Projektarchiv. Mit svnrdump können Sie inkrementelle Auszüge erstellen, wie mit svnadmin dump. Sie können sogar einen Auszug eines Teilbaums des Projektarchivs erstellen, was svnadmin dump nicht kann.

Der Hauptunterschied besteht darin, dass svnrdump ohne einen Direktzugriff auf das Projektarchiv zu benötigen, aus der Ferne arbeitet, wobei es die selben Repository Access (RA) Protokolle verwendet wie der Subversion-Client. Daher kann es sein, dass Sie Authentifizierungs-Informationen bereitstellen müssen. Darüber hinaus unterliegen Ihre Aktionen aus der Ferne den konfigurierten Autorisierungs-Einschränkungen des Subversion-Servers.

	Anmerkung
	svnrdump dump erfordert einen Fern-Server mit Subversion 1.4 oder neuer. Gegenwärtig erzeugt es nur Auszugsströme der Art wie Sie sie bekommen, wenn Sie svnadmin dump die Option --deltas mitgeben. In den typischen Anwendungsfällen ist das nicht von Interesse, jedoch kann es Auswirkungen auf bestimmte Arten besonderer Transformationen haben, die Sie auf den Auszugsstrom anwenden möchten.

	Anmerkung
	Da es nach der Übergabe neuer Revisionen die Revisions-Eigenschaften ändert, verlangt svnrdump load, dass im Ziel-Projektarchiv Änderungen an Revisions-Eigenschaften mittels des Hooks pre-revprop-change ermöglicht sind. Zu Details, siehe pre-revprop-change in Kapitel 9, Die vollständige Subversion Referenz.

Wie Sie wohl erwartet haben, können Sie svnadmin und svnrdump in Verbindung verwenden. Sie können beispielsweise svnrdump dump verwenden, um einen Auszugsstrom eines Fern-Projektarchivs zu erstellen und das Ergebnis an svnadmin load weiterleiten, um die Historie jenes Projektarchivs in das lokale Projektarchiv zu kopieren. Oder Sie können im Gegenzug die Historie eines lokalen Projektarchivs in ein fernes kopieren.

	Tipp
	Durch die Verwendung von file:// URLs kann svnrdump auch auf lokale Projektarchive zugreifen, allerdings wird hierfür auf Subversions Abstraktionsebene Repository Access (RA) zugegriffen; mit svnadmin ist in solchen Fällen der Durchsatz besser.

Angenommen, Sie haben bereits ein Projektarchiv, das Sie gerne spiegeln möchten. Als nächstes brauchen Sie ein leeres Ziel-Projektarchiv, das als Spiegel dienen soll. Dieses Projektarchiv kann irgendeins der verfügbaren Speicherverfahren benutzen (siehe „Auswahl der Datenspeicherung“) – die Abstraktionsschichten von Subversion stellen sicher, dass solche Details unerheblich sind. Doch standardmäßig darf es noch keine Versionshistorie enthalten. (Eine Ausnahme davon werden wir später in diesem Abschnitt erörtern.)

Das von svnsync verwendete Protokoll zur Übermittlung der Revisionsinformation ist sehr empfindlich gegenüber nicht übereinstimmenden Versionshistorien im Quell- und Ziel-Projektarchiv. Aus dem Grund, dass svnsync nicht verlangen kann, dass das Ziel-Projektarchiv nur lesbar ist,^[49] ist die Katastrophe programmiert, wenn erlaubt wird, die Revisions-Historie im Ziel-Projektarchiv mit anderen Mitteln als durch das Spiegeln zu verändern.

	Warnung
	Verändern Sie ein Spiegel-Projektarchiv nicht auf eine Art und Weise, die dazu führt, dass die Versionshistorie von der des Original-Projektarchivs abweicht. Die einzigen Übergaben und Änderungen an Revisions-Eigenschaften die in diesem Spiegel-Projektarchiv stattfinden, sollten ausschließlich durch den Befehl svnsync vorgenommen werden.

Eine weitere Anforderung an das Ziel-Projektarchiv ist, dass dem svnsync-Prozess erlaubt wird, Revisions-Eigenschaften zu verändern. Da svnsync im Rahmen des Hook-Systems ausgeführt wird, ist der standardmäßige Zustand des Projektarchivs (welcher keine Änderungen an Revisions-Eigenschaften zulässt; siehe pre-revprop-change in Kapitel 9, Die vollständige Subversion Referenz) nicht ausreichend. Sie müssen ausdrücklich den pre-revprop-change-Hook bereitstellen, der svnsync erlaubt, Revisions-Eigenschaften zu definieren und zu ändern. Mit diesen Vorkehrungen sind Sie gerüstet, um Projektarchiv-Revisionen zu spiegeln.

	Tipp
	Es ist eine gute Idee, Autorisierungsmaßnahmen zu ergreifen, um Ihrem Projektarchiv-Replikations-Prozess die Arbeit zu ermöglichen, wohingegen anderen Benutzern die Veränderung der Inhalte des Spiegel-Projektarchivs verwehrt wird.

Lassen Sie uns nun die Benutzung von svnsync bei einem Rundgang in einem typischen Spiegel-Szenario erklären. Wir werden diesen Diskurs mit Empfehlungen würzen, die Sie jedoch getrost missachten können, falls sie für Ihre Umgebung nicht benötigt werden oder nicht passend sind.

Wir wollen das öffentliche Subversion-Projektarchiv spiegeln, das den Quelltext des vorliegenden Buchs beherbergt, und diesen Spiegel von einer anderen Maschine als der, auf der das ursprüngliche Subversion-Quelltext-Projektarchiv untergebracht ist, im Internet veröffentlichen. Dieser entfernt liegende Rechner besitzt eine globale Konfiguration, die es anonymen Benutzern erlaubt, den Inhalt von Projektarchivs auf diesem Rechner zu lesen, aber zum Ändern dieser Projektarchive eine Authentifizierung der Benutzer erforderlich macht. (Vergeben Sie uns bitte, dass wir für den Augenblick über die Details der Subversion-Server-Konfiguration hinwegsehen – sie werden in Kapitel 6, Konfiguration des Servers behandelt.) Und aus dem alleinigen Grund, es noch interessanter machen zu wollen, werden wir den Replikations-Prozess von einer dritten Maschine aus steuern – diejenige, die wir aktuell benutzen.

Zunächst erstellen wir das Projektarchiv, das unser Spiegel sein soll. Dieser und die folgenden paar Schritte erfordern einen Shell-Zugang auf die Maschine, die das Spiegel-Projektarchiv beherbergen soll. Sobald das Projektarchiv jedoch konfiguriert ist, sollten wir nicht mehr direkt darauf zugreifen müssen.

$ ssh admin@svn.example.com "svnadmin create /var/svn/svn-mirror"
admin@svn.example.com's password: ********
$

Zu diesem Zeitpunkt haben wir unser Projektarchiv, und wegen unserer Server-Konfiguration ist das Projektarchiv nun „live“ im Internet. Da wir aber außer unserem Replikations-Prozess niemanden erlauben wollen, das Projektarchiv zu ändern, benötigen wir eine Möglichkeit, diesen Prozess von anderen potentiellen Zugriffen zu unterscheiden. Um dies zu machen, verwenden wir einen ausgezeichneten Benutzernamen für unseren Prozess. Nur Übergaben und Änderungen an Revisions-Eigenschaften unter dem Anwenderkonto syncuser werden erlaubt.

Wir verwenden das Hook-System des Projektarchivs sowohl, um dem Replikations-Prozess seine Arbeit zu ermöglichen, als auch, um sicherzustellen, dass nur er diese Dinge tut. Wir bewerkstelligen dies, indem wir zwei der Projektarchiv-Ereignis-Hooks implementieren – pre-revprop-change und start-commit. Unser pre-revprop-change-Hook-Skript finden Sie in Beispiel 5.2, „pre-revprop-change-Hook-Skript des Spiegel-Projektarchivs“; grundsätzlich stellt es sicher, dass der Benutzer, der die Eigenschaften ändern möchte, unser syncuser ist. Falls dies zutrifft, ist die Änderung erlaubt, anderenfalls wird die Änderung abgelehnt.

#!/bin/sh 

USER="$3"

if [ "$USER" = "syncuser" ]; then exit 0; fi

echo "Ausschließlich der Benutzer syncuser darf Revisions-Eigenschaften ändern" >&2
exit 1

Das deckt Änderungen an Revisions-Eigenschaften ab. Nun müssen wir sicherstellen, dass nur der Benutzer syncuser neue Revisionen an das Projektarchiv übergeben darf. Wir machen das, indem wir ein start-commit-Hook-Skript wie das in Beispiel 5.3, „start-commit-Hook-Skript des Spiegel-Projektarchivs“ benutzen.

#!/bin/sh 

USER="$2"

if [ "$USER" = "syncuser" ]; then exit 0; fi

echo "Ausschließlich der Benutzer syncuser darf neue Revisionen übergeben" >&2
exit 1

Nachdem wir unsere Hook-Skripte installiert und uns vergewissert haben, dass sie auf dem Subversion-Server ausführbar sind, sind wir mit dem Aufsetzen des Spiegel-Projektarchivs fertig. Nun kommen wir zum eigentlichen Spiegeln.

Das Erste, was wir machen müssen ist, unserem Ziel-Projektarchiv mit svnsync zu sagen, dass es ein Spiegel des Quell-Projektarchivs sein wird. Wir machen das mit dem Unterbefehl svnsync initialize. Die URLs, die wir mitgeben, zeigen auf die Wurzelverzeichnisse des Ziel- bzw. Quell-Projektarchivs. In Subversion 1.4 ist das erforderlich – nur die vollständige Spiegelung von Projektarchiven ist erlaubt. Beginnend mit Subversion 1.5 jedoch können Sie svnsync auch zum Spiegeln von Teilbäumen des Projektarchivs verwenden.

$ svnsync help init
initialize (init): Aufruf: svnsync initialize ZIEL_URL QUELL_URL

Bereitet ein Zielprojektarchiv auf die Synchronisation mit einem
anderen Projektarchiv vor.
…
$ svnsync initialize http://svn.example.com/svn-mirror \
                     https://svn.code.sf.net/p/svnbook/source \
                     --sync-username syncuser --sync-password syncpass
Eigenschaften für Revision 0 kopiert (svn:sync-* Eigenschaften übergangen).
NOTE: Normalized svn:* properties to LF line endings (1 rev-props, 0 node-props).
$

Unser Ziel-Projektarchiv wird sich nun erinnern, dass es ein Spiegel des öffentlichen Subversion-Quelltext-Projektarchivs ist. Beachten Sie, dass wir einen Benutzernamen und ein Passwort an svnsync übergeben haben – das war für den pre-revprop-change-Hook in unserem Spiegel-Projektarchiv erforderlich.

Anmerkung

In Subversion 1.4 wurden die an die Kommandozeilenoptionen --username und --password von svnsync übergebenen Werte sowohl für die Authentisierung gegenüber dem Quell-Projektarchiv als auch gegenüber dem Ziel-Projektarchiv verwendet. Das führte zu Problemen, falls die Zugangsdaten eines Benutzers nicht für beide Projektarchive identisch waren, insbesondere im nicht-interaktiven Modus (mit der Option --non-interactive). Dies ist in Subversion 1.5 mit der Einführung von zwei neuen Optionspaaren behoben worden. Benutzen Sie --source-username und --source-password für die Zugangsdaten des Quell-Projektarchivs sowie --sync-username und --sync-password für das Ziel-Projektarchiv. (Die alten Optionen --username und --password bleiben aus Kompatibilitätsgründen bestehen, doch raten wir von deren Verwendung ab.)

Und nun kommt der lustige Teil. Mit einem einfachen Unterbefehl können wir svnsync auffordern, alle bislang ungespiegelten Revisionen aus dem Quell-Projektarchiv zum Ziel zu kopieren.^[50] Der Unterbefehl svnsync synchronize wird die bereits vorher im Ziel-Projektarchiv gespeicherten besonderen Revisions-Eigenschaften untersuchen und sowohl ermitteln, welches Projektarchiv es spiegelt und dass die zuletzt gespiegelte Revision die Revision 0 war. Dann fragt es das Quell-Projektarchiv ab, welches die jüngste Revision in diesem Projektarchiv ist. Schließlich fordert es den Server des Quell-Projektarchivs auf, alle Revisionen zwischen 0 und dieser letzten Revision zu wiederholen. Sobald svnsync die entsprechende Antwort vom Quell-Projektarchiv-Server erhält, leitet es diese Revisionen als neue Übergaben an den Server des Ziel-Projektarchivs weiter.

$ svnsync help synchronize
synchronize (sync): Aufruf: svnsync synchronize ZIEL_URL

Überträgt alle laufenden Revisionen von der Quelle, mit der es
initialisiert wurde, zum Ziel.
…
$ svnsync synchronize http://svn.example.com/svn-mirror \
                      https://svn.code.sf.net/p/svnbook/source
Revision 1 übertragen.
Eigenschaften für Revision 1 kopiert.
Revision 2 übertragen.
Eigenschaften für Revision 2 kopiert.
Übertrage Daten .
Revision 3 übertragen.
Eigenschaften für Revision 3 kopiert.
…
Übertrage Daten .
Revision 4063 übertragen.
Eigenschaften für Revision 4063 kopiert.
Übertrage Daten .
Revision 4064 übertragen.
Eigenschaften für Revision 4064 kopiert.
Übertrage Daten .
Revision 4065 übertragen.
Eigenschaften für Revision 4065 kopiert.
$

Von besonderem Interesse ist hier, dass für jede gespiegelte Revision zunächst eine Übergabe der Revision an das Ziel-Projektarchiv erfolgt und dann die Änderungen der Eigenschaften folgen. Diese zweiphasige Replizierung ist notwendig, da die anfängliche Übergabe durch den Benutzer syncuser durchgeführt (und ihm auch zugeschrieben) wird und mit dem Zeitstempel der Erzeugung dieser Revision versehen wird. svnsync hat hinterher unmittelbaren Serie von Änderungen an den Eigenschaften vorzunehmen, die all die Eigenschaften dieser Revision vom Quell-Projektarchiv ins Ziel-Projektarchiv kopieren, was auch den Effekt hat, dass der Autor und der Zeitstempel so korrigiert werden, dass diese den entsprechenden Werten im Quell-Projektarchiv entsprechen.

Erwähnenswert ist ebenfalls, dass svnsync eine sorgfältige Buchführung vornimmt, die es ihm erlaubt, sicher unterbrochen und erneut gestartet zu werden, ohne die Integrität der gespiegelten Daten zu gefährden. Falls während des Spiegelns ein Netzproblem entsteht, wiederholen Sie einfach den Befehl svnsync synchronize, und er wird einfach damit weitermachen, womit er aufgehört hat. Das ist tatsächlich genau das, was Sie machen, um Ihren Spiegel aktuell zu halten, wenn neue Revisionen im Quell-Projektarchiv auftauchen.

Warnung

As part of its bookkeeping, svnsync records in the mirror repository the URL with which the mirror was initialized. Because of this, invocations of svnsync which follow the initialization step do not require that you provide the source URL on the command line again. However, for security purposes, we recommend that you continue to do so. Depending on how it is deployed, it may not be safe for svnsync to trust the source URL which it retrieves from the mirror repository, and from which it pulls versioned data.

$ svn propdel --revprop -r0 svn:sync-lock http://svn.example.com/svn-mirror
Eigenschaft »svn:sync-lock« wurde von Revision 0 im Projektarchiv gelöscht
$

$ svnsync initialize --allow-non-empty http://svn.example.com/svn-mirror \ 
                                       NEUER-QUELL-URL
Eigenschaften für Revision 4065 kopiert.
$

$ svn propset --revprop -r0 svn:sync-from-url NEUER-QUELL-URL \
      http://svn.example.com/svn-mirror 
Eigenschaft »svn:sync-from-url« wurde für Revision 0 im Projektarchiv gesetzt
$

$ svnsync help info
Aufruf: svnsync info ZIEL_URL

Gibt Informationen über das Zielprojektarchiv der Synchronisation aus,
das sich unter ZIEL_URL befindet.
…
$ svnsync info http://svn.example.com/svn-mirror
Quell-URL: https://svn.code.sf.net/p/svnbook/source
UUID des Quellprojektarchivs: 931749d0-5854-0410-9456-f14be4d6b398
Letzte zusammengeführte Revision: 4065
$

In diesem Prozess ist jedoch eine kleine Unfeinheit. Da die Revisions-Eigenschaften von Subversion jederzeit während der Lebenszeit eines Projektarchivs geändert werden können, ohne zu protokollieren, wann sie geändert wurden, müssen replizierende Prozesse ein besonderes Augenmerk auf sie richten. Wenn Sie bereits die ersten 15 Revisionen eines Projektarchivs gespiegelt haben, und dann jemand eine Revisions-Eigenschaft von Revision 12 ändert, weiß svnsync nicht, dass es zurückgehen und die Kopie der Revision 12 korrigieren muss. Sie müssen es ihm manuell mitteilen, indem Sie den Unterbefehl svnsync copy-revprops verwenden, der einfach alle Eigenschaften einer bestimmten Revision oder eines Revisionsintervalls erneut repliziert.

$ svnsync help copy-revprops
copy-revprops: usage:

    1. svnsync copy-revprops DEST_URL [SOURCE_URL]
    2. svnsync copy-revprops DEST_URL REV[:REV2]

…
$ svnsync copy-revprops http://svn.example.com/svn-mirror 12 
Eigenschaften für Revision 12 kopiert.
$

Das ist Projektarchiv-Replikation mit svnsync in aller Kürze. Sehr wahrscheinlich möchten Sie einen solchen Prozess etwas automatisieren. Während unser Beispiel ein Ziehen-und-Schieben-Szenario beschrieb, möchten Sie vielleicht, dass Ihr primäres Projektarchiv als Teil der post-commit- und post-revprop-change-Hooks Änderungen an einen oder mehrere ausgesuchte Spiegel weiterschiebt. Das würde es ermöglichen, dass der Spiegel beinahe in Echtzeit aktuell gehalten werden kann.

svnsync ist nicht darauf beschränkt, vollständige Kopien des Inhalts von Projektarchiven zu machen. Es kann auch verschiedene Spielarten der teilweisen Replizierung bewerkstelligen. Beispielsweise spiegelt svnsync, wenn dies auch nicht ein häufiger Anwendungsfall ist, Projektarchive, in denen der Anwender unter dessen Kennung es läuft, nur eingeschränkte Rechte besitzt. Es werden dann einfach nur die Teile des Projektarchivs kopiert, die der Benutzer sehen darf. Offensichtlich taugt so ein Spiegel nicht als Sicherheitskopie.

Seit Subversion 1.5 hat svnsync auch die Fähigkeit, eine Teilmenge eines Projektarchivs statt des Ganzen zu spiegeln. Das Anlegen und Pflegen eines solchen Spiegels unterscheidet sich nicht vom Spiegeln eines kompletten Projektarchivs; anstatt den Wurzel-URL des Quell-Projektarchivs bei svnsync init anzugeben, nennen Sie einfach den URL eines Unterverzeichnisses dieses Projektarchivs. Hierbei gibt es allerdings einige Einschränkungen. Als Erstes können Sie nicht mehrere disjunkte Unterverzeichnisse des Quell-Projektarchivs in ein einzelnes Ziel-Projektarchiv spiegeln – stattdessen müssen Sie ein Eltern-Verzeichnis spiegeln, das allen gemeinsam ist. Zum Zweiten ist die Filterlogik vollständig pfadbasiert, so dass bei Verzeichnissen, die in der Vergangenheit einmal umbenannt wurden, Ihr Spiegel nur die Revisionen seit dem Zeitpunkt enthält an dem das Verzeichnis unter diesem URL zu finden war. Auch wenn das Unterverzeichnis künftig umbenannt wird, werden Revisionen nur bis zu dem Zeitpunkt gespiegelt, an dem der URL ungültig wird.

Vorher erwähnten wir die Kosten der Einrichtung und der initialen Spiegelung eines bestehenden Projektarchivs. Für viele Leute sind die reinen Kosten der Übertragung tausender – oder Millionen von – Revisionen der Historie in ein neues Spiegel-Projektarchiv mit svnsync das KO-Kriterium. Glücklicherweise stellt Subversion 1.7 eine Abhilfe in Form der neuen Option --allow-non-empty für svnsync initialize zur Verfügung. Diese Option erlaubt Ihnen, ein Projektarchiv als Spiegel eines anderen zu initialisieren, wobei die Verifizierung umgangen wird, dass der zu initialisierende Spiegel keine Historie beinhaltet. Durch unsere vorhergehenden Warnungen über die Empfindlichkeit des gesamten Replizierungsprozesses, sollten Sie mit Recht wahrgenommen haben, dass diese Option nur mit großer Vorsicht verwendet werden sollte. Aber sie ist wunderbar praktisch, falls Sie administrativen Zugriff auf das Quell-Projektarchiv haben und einfach eine physikalische Kopie des Projektarchivs erstellen und diese Kopie als einen neuen Spiegel initialisieren können:

$ svnadmin hotcopy /path/to/repos /path/to/mirror-repos 
$ ### /path/to/mirror-repos/hooks/pre-revprop-change anlegen
$ svnsync initialize file:///path/to/mirror-repos \
                     file:///path/to/repos
svnsync: E000022: Destination repository already contains revision history; co
nsider using --allow-non-empty if the repository's revisions are known to mirr
or their respective revisions in the source repository
$ svnsync initialize --allow-non-empty file:///path/to/mirror-repos \
                                       file:///path/to/repos 
Eigenschaften für Revision 32042 kopiert.
$

Administratoren, die eine Version von Subversion vor 1.7 betreiben (und deshalb keinen Zugang zur --allow-non-empty-Funktionalität von svnsync initialize haben), können effektiv das selbe erreichen, indem sie sorgfältig die r0-Eigenschaften der Kopie des Projektarchivs manipulieren, dass der Spiegel des Originals werden soll. Verwenden Sie svnadmin setrevprop, um die selben Eigenschaften zur Buchhaltung zu erstellen, die svnsync dort erstellt hätte.

We've discussed a couple of ways to replicate revision history from one repository to another. So let's look now at the user end of these operations. How does replication and the various situations which call for it affect Subversion clients?

Was das Zusammenspiel von Benutzern mit Projektarchiven und Spiegeln betrifft, ist es möglich eine einzelne Arbeitskopie zu haben, die mit beiden kommuniziert, doch müssen Sie hierfür einige Verrenkungen machen. Zunächst müssen Sie sicherstellen, dass sowohl das primäre Projektarchiv als auch das Spiegel-Projektarchiv dieselbe Projektarchiv-UUID haben (was standardmäßig nicht der Fall ist). Mehr darüber unter „Verwaltung von Projektarchiv UUIDs“ später in diesem Kapitel.

Sobald beide Projektarchive dieselbe UUID haben, können Sie svn relocate benutzen, um das Projektarchiv auszuwählen, mit dem Sie arbeiten wollen; dieser Prozess ist in svn relocate in Kapitel 9, Die vollständige Subversion Referenz beschrieben. Eine mögliche Gefahr besteht allerdings, wenn das Haupt- und das Spiegel-Projektarchiv nicht zeitnah synchronisiert sind. Eine Arbeitskopie, die auf das Haupt-Projektarchiv zeigt und gegenüber diesem aktuell ist, wird nach dem Umschalten auf den nicht aktuellen Spiegel durch den plötzlichen Verlust von Revisionen, die sie dort erwartet, verwirrt werden und deshalb Fehler ausgeben. Falls dies auftritt, können Sie entweder Ihre Arbeitskopie wieder zurück auf das Haupt-Projektarchiv schalten und warten bis das Spiegel-Projektarchiv aktuell ist oder Ihre Arbeitskopie auf eine Revision zurücksetzen, von der Sie wissen, dass sie im synchronisierten Projektarchiv vorhanden ist, und dann noch einmal das Umschalten versuchen.

Zum Schluss sollte Ihnen bewusst sein, dass die von svnsync angebotene revisionsbasierte Replikation genau das ist – die Replikation von Revisionen. Nur die durch das Format der Subversion-Auszugsdateien übertragene Information ist replizierbar. Somit besitzen Werkzeuge wie svnsync (und svnrdump, das wir in „Projektarchiv-Daten-Migration mit svnrdump“ erörtern) dieselben Einschränkungen wie der Auszugsstrom und beinhalten weder Dinge wie Hook-Implementierungen, Projektarchiv- oder Server-Konfigurationen, unvollständige Transaktionen noch Anwendersperren auf Pfaden im Projektarchiv.