Versionskontrolle mit Subversion

Alle Versionskontrollsysteme haben das gleiche fundamentale Problem zu lösen: Wie soll es Anwendern erlaubt werden, Informationen zu teilen, aber sie davor zu bewahren, sich gegenseitig auf die Füße zu treten? Es ist allzu einfach, die Änderungen eines anderen im Projektarchiv zu überschreiben.

Stellen Sie sich einmal folgendes Abbildung 1.2, „Das zu vermeidende Problem“Szenario vor: Zwei Kollegen, Harry und Sally, haben sich entschieden, dieselbe Datei zur gleichen Zeit zu bearbeiten. Harry speichert seine Änderungen zuerst im Projektarchiv, es ist aber möglich, dass Sally nur einige Augenblicke später seine Datei mit ihrer überschreibt. Harrys Änderungen der Datei sind zwar nicht für immer verloren (da das System jede Änderung aufzeichnet), aber alle seine Änderungen sind in Sallys später gespeicherter Version der Datei nicht vorhanden, da Sally diese Änderungen noch gar nicht kannte. Das heißt, dass Harrys Arbeit doch verloren ist, zumindest in der neuesten Version der Datei, und das vermutlich aus Versehen. Eine solche Situation wollen wir auf alle Fälle vermeiden.

Abbildung 1.2. Das zu vermeidende Problem

Viele Versionskontrollsysteme verwenden ein Sperren - Ändern - Entsperren-Modell um zu verhindern, dass verschiedene Autoren sich gegenseitig die Änderungen löschen. Bei diesem Modell erlaubt das Projektarchiv nur jeweils einem Programmierer den Zugriff auf eine Datei. Harry müsste also die Datei sperren, ehe er anfängt, seine Änderungen einzugeben. Wenn Harry die Datei gesperrt hat, kann Sally sie nicht ebenfalls sperren und daher auch nichts ändern. Sie kann die Datei in der Zeit nur lesen und darauf warten, dass Harry mit seiner Arbeit fertig ist und die Datei entsperrt. Abbildung 1.3, „Die Sperren - Ändern - Entsperren - Lösung veranschaulicht diese einfache Möglichkeit“

Abbildung 1.3. Die Sperren - Ändern - Entsperren - Lösung veranschaulicht diese einfache Möglichkeit

Das Problem bei einem Sperren - Ändern - Entsperren - Modell liegt in seinen Beschränkungen, die oft zu schier unüberwindlichen Hindernissen führen können.

Subversion, CVS und viele andere Versionskontrollsysteme benutzen eine „Kopieren – Ändern – Zusammenfassen“ — Version als Alternative zum Sperren. In diesem Modell erschafft jeder User sich eine eigene Arbeitskopie der im Projektarchiv vorhandenen Dateien und Verzeichnisse. Dann können die User gleichzeitig und unabhängig voneinander ihre jeweiligen Änderungen eingeben und speichern. Am Ende werden dann alle Einzelkopien zu einer neuen, aktuellen Version zusammengefasst. Das Versionskontrollsystem hilft oft bei dieser Zusammenfassung, aber letztlich ist der Mensch dafür verantwortlich, das es korrekt abläuft.

Hier ist ein Beispiel: Harry und Sally haben sich jeweils eine eigene Arbeitskopie des im Projektarchiv vorhandenen Projektes geschaffen. Beide arbeiten nun am selben File A innerhalb ihrer jeweiligen Kopien. Sally speichert ihre Version zuerst im Projektarchiv ab. Wenn Harry später ebenfalls versucht, seine Änderungen zu speichern, informiert ihn das Projektarchiv, das sein File A nicht mehr aktuell ist. Das bedeutet, dass seitdem er sich seine Kopie erschaffen hat, sind irgendwelche Änderungen aufgetreten. Also bittet Harry seinen Client darum, diese neuen Änderungen in seine Arbeitskopie des File A einzuarbeiten. Die Möglichkeit besteht, dass Sallys Änderungen mit seinen nicht überlappen, wenn er also alle Änderungen eingearbeitet hat, kann er seine Arbeitskopie zurück in das Projektarchiv speichern. Die Abbildungen Abbildung 1.4, „„Kopieren – Ändern – Zusammenfassen“ - Lösung“ und Abbildung 1.5, „„Kopieren – Ändern – Zusammenfassen“ - Lösung (Fortsetzung)“ zeigen diesen Proczess.

Abbildung 1.4. „Kopieren – Ändern – Zusammenfassen“ - Lösung

Abbildung 1.5. „Kopieren – Ändern – Zusammenfassen“ - Lösung (Fortsetzung)

Was aber passiert, wenn Sallys Änderungen mit Harrys kollidieren? Diese Situation wird Konflikt genannt und ist normalerweise kein allzugroßes Problem. Wenn Harry Sallys Änderungen in seine Datei einpflegen lassen will, werden in seiner Datei die miteinander in Konflikt stehenden Änderungen gekennzeichnet, er kann sämtliche Änderungen sehen und manuell zwischen ihnen wählen. Das Programm löst solche Konfliktsituationen nicht automatisch, nur Menschen sind in der Lage, die Probleme zu erkennnen und die nötigen intelligenten Änderungen durchzuführen. Wenn Harry die Konfliktsituationen — vielleicht nach einer kurzen Diskussion mit Sally — gelöst hat, kann er seine Datei problemlos ins Projektarchiv speichern.

Dieses Kopieren – Ändern – Zusammenfassen - Modell (engl. copy-modify-merge model) klingt vielleicht ein wenig chaotisch, in der Praxis aber läuft es völlig glatt. Die einzelnen User können parallel arbeiten, ohne einander in die Quere zu kommen oder unnötig warten zu müsssen. Wenn sie an den selben Dateien arbeiten, zeigt es sich meistens, dass ihre jeweiligen Änderungen einander überhaupt nicht stören, wirkliche Konflikte sind selten. Und die Zeit, die es beansprucht, eine solche Konfliktsituation zu lösen, ist meist wesentlich kürzer als der Zeitverlust, der durch das Sperren auftritt.

Am Ende läuft alles auf einen kritischen Faktor hinaus. Die Kommunikation zwischen den Usern. Wenn diese Kommunikation eher spärlich abläuft, häufen sich sowohl semantische als auch syntaktische Konflikte. Kein System kann User dazu zwingen, vernünftig miteinander zu kommnunizieren und kein System kann semantische Konflikte erkennen. Also hat es auch keinen Sinn, sich in dem falschen Gefühl von Sicherheit zu wiegen, dass das Sperren Konflikte irgendwie vermeiden könnte. In der Praxis verringert das System des Sperrens mehr als andere die Produktivität.

Das ganze Buch hindurch verwendet Subversion URLs, um Dateien und Verzeichnisse in Subversion-Projektarchivs zu identifizieren. Meistens benutzen diese URLs die Standardsyntax, die es erlaubt, Servernamen und Portnummern als Teil des URL zu spezifizieren:

$ svn checkout http://svn.example.com:9834/repos
…

Allerdings gibt es einige bemerkenswerte Feinheiten, wie Subversion mit URLs umgeht. Beispielsweise dürfen URLs, die die file://-Zugriffsmethode enthalten (für lokale Projektarchive verwendet), gemäß Konvention entweder den Servernamen localhost oder gar keinen Servernamen enthalten:

$ svn checkout file:///var/svn/repos
…
$ svn checkout file://localhost/var/svn/repos
…

Darüber hinaus müssen Benutzer des file:// Schemas auf Windows-Plattformen eine inoffizielle „Standard“-Syntax verwenden falls auf Projektarchive auf derselben Maschine aber auf einem anderen Laufwerk zugegriffen werden soll. Beide der folgenden URL-Pfad-Syntaxen funktionieren, wobei X das Laufwerk ist, wo das Projektarchiv liegt:

C:\> svn checkout file:///X:/var/svn/repos
…
C:\> svn checkout "file:///X|/var/svn/repos"
…

Bei der zweiten Syntax muss der URL in Anführungsstriche eingeschlossen werden, damit der senkrechte Strich nicht als Pipe-Symbol interpretiert wird. Beachten Sie auch, dass in einem URL Schrägstriche verwendet werden, obwohl es unter Windows üblich ist, für Pfade umgekehrte Schrägstriche zu verwenden.

Anmerkung

Sie können die file:// URLs von Subversion nicht in einem normalen Web-Browser auf die Art und Weise verwenden wie andere file:// URLs. Falls Sie versuchen, einen file:// URL in einem gewöhnlichen Web-Browser anzusehen, wird der Inhalt der Datei von der angegebenen Stelle direkt aus dem Dateisystem gelesen und angezeigt. Allerdings befinden sich die Daten von Subversion in einem virtuellen Dateisystem (siehe „Projektarchiv-Schicht“), und der Browser wird nicht mit diesem Dateisystem umzugehen wissen.

Zuletzt sei noch angemerkt, dass der Subversion-Client, wie ein Web-Browser, nötigenfalls automatisch URLs umwandelt. Falls zum Beispiel in einem URL Leerzeichen oder Großbuchstaben vorkommen wie hier:

$ svn checkout "http://host/path with space/project/españa"

wird Subversion die unsicheren Zeichen umwandeln, als ob Sie

$ svn checkout http://host/path%20with%20space/project/espa%C3%B1a

geschrieben hätten.

Falls ein URL Leerzeichen beinhalten sollte, stellen Sie sicher, das der URL in Anführungszeichen gesetzt wird, damit die Shell alles als ein Argument für das svn Programm behandelt.

Sie haben schon über Arbeitskopien gelesen; nun werden wir zeigen, wie der Subversion-Client sie erzeugt und benutzt.

Eine Subversion-Arbeitskopie ist ein gewöhnlicher Verzeichnisbaum auf Ihrem lokalen System, der eine Ansammlung von Dateien enthält. Sie können diese Dateien nach belieben bearbeiten, und wenn es sich um Quelltexte handelt, können Sie hieraus Ihr Programm auf die übliche Weise compilieren. Ihre Arbeitskopie ist Ihr privater Arbeitsbereich: nie wird Subversion weder die Änderungen von anderen einpflegen, noch Ihre eigenen Änderungen anderen zur Verfügung stellen, bis Sie es ausdrücklich dazu auffordern. Sie können sogar mehrere Arbeitskopien desselben Projektes haben.

Nachdem Sie einige Änderungen an den Dateien Ihrer Arbeitskopie gemacht und sichergestellt haben, dass sie funktionieren, stellt Ihnen Subversion Befehle zur Verfügung, um Ihre Änderungen den anderen, die an Ihrem Projekt mitarbeiten, „publik“ zu machen (indem es ins Projektarchiv schreibt). Wenn die anderen ihre Änderungen veröffentlichen, stellt Ihnen Subversion Befehle zur Verfügung, um diese Änderungen in Ihr Arbeitsverzeichnis einzupflegen (indem es aus dem Projektarchiv liest).

Eine Arbeitskopie verfügt darüber hinaus über einige zusätzliche Dateien, die von Subversion erzeugt und gepflegt werden, um es bei diesen Befehlen zu unterstützen. Insbesondere enthält jedes Verzeichnis Ihrer Arbeitskopie ein Unterverzeichnis namens .svn, auch bekannt als das Verwaltungsverzeichnis der Arbeitskopie. Die Dateien in jedem Verwaltungsverzeichnis helfen Subversion dabei, zu erkennen, welche Dateien unveröffentlichte Änderungen enthalten und welche Dateien hinsichtlich der Arbeit anderer veraltet sind.

Oft enthält ein typisches Subversion-Projektarchiv die Dateien (oder den Quelltext) für verschiedene Projekte; für gewöhnlich ist jedes Projekt ein Unterverzeichnis im Dateisystembaum des Projektarchivs. Bei dieser Anordnung entspricht die Arbeitskopie eines Benutzers gewöhnlich einem bestimmten Unterverzeichnis des Projektarchivs.

Nehmen wir zum Beispiel an, Sie haben ein Projektarchiv, das zwei Software-Projekte beinhaltet, paint und calc. Jedes Projekt ist in einem eigenen Hauptverzeichnis abgelegt, wie in Abbildung 1.6, „Das Dateisystem des Projektarchivs“ dargestellt.

Abbildung 1.6. Das Dateisystem des Projektarchivs

Um eine Arbeitskopie zu erhalten, muss zunächst irgendein Teilbaum des Projektarchivs ausgecheckt werden(check out). (Der Begriff check out hört sich an, als habe es etwas mit dem Sperren oder Reservieren von Ressourcen zu tun, hat es aber nicht; es erzeugt lediglich eine private Kopie des Projektes für Sie.) Wenn Sie zum Beispiel /calc auschecken, bekommen Sie eine Arbeitskopie wie diese:

$ svn checkout http://svn.example.com/repos/calc
A    calc/Makefile
A    calc/integer.c
A    calc/button.c
Ausgecheckt, Revision 56.

$ ls -A calc
Makefile  button.c integer.c .svn/

Die Liste der As am linken Rand zeigt an, dass Subversion Ihrer Arbeitskopie eine Anzahl von Objekten hinzufügt (Add). Sie haben nun eine persönliche Kopie des Verzeichnisses /calc im Projektarchiv, mit einem zusätzlichen Eintrag – .svn – das, wie bereits erwähnt, die besonderen Informationen enthält, die Subversion benötigt.

Angenommen, Sie nehmen Änderungen an button.c vor. Da sich das Verzeichnis .svn den ursprünglichen Änderungszeitpunkt und den Inhalt der Datei merkt, kann Subversion erkennen, dass Sie die Datei verändert haben. Trotzdem veröffentlicht Subversion Ihre Änderungen solange nicht, bis Sie es ausdrücklich hierzu auffordern. Der Vorgang des Veröffentlichens von Änderungen über das Projektarchiv ist gemeinhin bekannter als commit (oder check in).

Um Ihre Änderungen anderen gegenüber zu veröffentlichen, können Sie den Subversion-Befehl svn commit verwenden:

$ svn commit button.c -m "Tippfehler in button.c korrigiert"
Sende          button.c
Übertrage Daten .
Revision 6 übertragen.

Nun sind Ihre Änderungen an button.c dem Projektarchiv überstellt, mitsamt einer Notiz, die Ihre Änderung beschreibt (nämlich, dass Sie einen Tippfehler beseitigt haben). Wenn eine andere Benutzerin eine Arbeitskopie von /calc auscheckt, wird sie Ihre Änderungen in der letzten Version der Datei sehen können.

angenommen, Sie haben eine Mitarbeiterin, Sally, die eine Arbeitskopie von /calc gleichzeitig mit Ihnen ausgecheckt hat. Wenn Sie Ihre Änderung an button.c committen, bleibt Sallys Arbeitskopie unverändert; Subversion ändert Arbeitskopien nur auf Wunsch des Benutzers.

Um ihr Projekt auf den neuesten Stand zu bringen, kann Sally Subversion dazu auffordern, ihre Arbeitskopie zu aktualisieren, indem sie den Befehl svn update verwendet. Das bringt sowohl Ihre als auch alle anderen Änderungen die committet wurden seit sie ausgecheckt hatte in ihre Arbeitskopie.

$ pwd
/home/sally/calc

$ ls -A
Makefile button.c integer.c .svn/

$ svn update
U    button.c
Aktualisiert zu Revision 57.

Die Ausgabe des svn update Befehls zeigt, dass Subversion den Inhalt von button.c aktualisiert hat (Update). Beachten Sie, dass Sally nicht angeben musste, welche Dateien zu aktualisieren sind; Subversion benutzt die Informationen aus dem .svn Verzeichnis und darüber hinaus weitere Informationen im Projektarchiv, um zu entscheiden, welche Dateien auf den neuesten Stand gebracht werden müssen.

Ein svn commit veröffentlicht Änderungen an einer beliebigen Anzahl von Dateien und Verzeichnissen als eine einzige atomare Transaktion. In Ihrer Arbeitskopie können Sie Dateiinhalte ändern, Dateien und Verzeichnisse erzeugen, löschen, umbenennen und kopieren und dann den gesamten Umfang der Änderungen als atomare Transaktion durch ein svn commit in das Projektarchiv einbringen.

Eine atomare Transaktion bedeutet: entweder es gehen alle Änderungen in das Projektarchiv oder keine. Angesichts von Programmabstürzen, Systemabstürzen, Netzproblemen oder anderer Benutzeraktionen hält Subversion an dieser Atomizität fest.

Jedes Mal wenn das Projektarchiv ein Commit annimmt, wird ein neuer Zustand des Dateisystem-Baums erzeugt, der Revision genannt wird. Jeder Revision wird eine einmalige natürliche Zahl zugewiesen, die um eins größer ist als die Vorgänger-Revision. Die anfängliche Revision eines frisch erzeugten Projektarchivs bekommt die Nummer 0 und besteht lediglich aus einem leeren Wurzelverzeichnis.

Abbildung 1.7, „Das Projektarchiv“ zeigt, wie man sich das Projektarchiv vorstellen kann. Stellen Sie sich eine Reihe von Revisionsnummern vor, die bei 0 startet und von links nach rechts wächst. Jede Revisionsnummer hat einen Dateisystem-Baum unter sich hängen, der ein „Schnappschuss“ des Projektarchivs nach einem Commit ist.

Abbildung 1.7. Das Projektarchiv

Es ist wichtig zu beachten, dass eine Arbeitskopie nicht immer genau einer Revision im Projektarchiv zugeordnet werden kann; sie kann Dateien aus verschiedenen Revisionen beinhalten. Nehmen wir z.B. an, Sie checken sich eine Arbeitskopie einer Datei aus einem Projektarchiv aus, deren neueste Revision 4 ist:

calc/Makefile:4
     integer.c:4
     button.c:4

In diesem Augenblick entspricht Ihre Arbeitskopie exakt der Revision im Projektarchiv. Sie machen jetzt allerdings eine Änderung an button.c und bringen diese Änderung mit einem Commit ins Projektarchiv. Angenommen, dass keine weiteren Commits vorgenommen wurden, wird Ihr Commit die Revision 5 im Projektarchiv erzeugen, und Ihre Arbeitskopie sieht so aus:

calc/Makefile:4
     integer.c:4
     button.c:5

Angenommen, zu diesem Zeitpunkt macht Sally einen Commit für eine Änderung an integer.c und erzeugt Revision 6. Wenn Sie svn update verwenden, um Ihre Arbeitskopie zu aktualisieren, sieht sie so aus:

calc/Makefile:6
     integer.c:6
     button.c:6

Sallys Änderung an integer.c erscheint in Ihrer Arbeitskopie, und Ihre Änderung ist immer noch in button.c. In diesem Beispiel ist der Text von Makefile in den Revisionen 4, 5 und 6 identisch, jedoch markiert Subversion die Arbeitskopie von Makefile mit Revision 6, um zu zeigen, dass es noch aktuell ist. Wenn Sie also ein sauberes Update von der Wurzel Ihrer Arbeitskopie her machen, sollte sie im Allgemeinen genau einer Revision im Projektarchiv entsprechen.

Für jede Datei eines Arbeitsverzeichnis merkt sich Subversion zwei essentielle Informationen im .svn/-Verwaltungsbereich:

Mit diesen Informationen kann Subversion durch Kommunikation mit dem Projektarchiv feststellen, in welchem der folgenden Zustände sich eine Arbeitsdatei befindet:

Das hört sich an, als müsse man jede Menge mitverfolgen, aber der svn status Befehl zeigt Ihnen den Zustand jedes Objektes in Ihrer Arbeitskopie. Weitergehende Informationen zu diesem Befehl finden Sie unter „Verschaffen Sie sich einen Überblick über Ihre Änderungen“.

Als allgemeingültiges Prinzip versucht Subversion, so flexibel wie möglich zu sein. Eine besondere Ausprägung der Flexibilität ist die Fähigkeit, eine Arbeitskopie bestehend aus Dateien und Verzeichnissen mit einer Mischung unterschiedlicher Revisionsnummern zu haben. Unglücklicherweise neigt diese Flexibilität dazu, eine Anzahl neuer Benutzer zu verwirren. Wenn Sie das vorangegangene Beispiel, das gemischte Revisionen vorgestellt hat, verwirrte, zeigen wir hier eine Einführung warum es diese Möglichkeit gibt und wie sie verwendet wird.

Mit dem svn import-Befehl kann ein unversionierter Verzeichnisbaum schnell in ein Projektarchiv kopiert werden, wobei benötigte Zwischenverzeichnisse nach Bedarf angelegt werden. svn import erfordert keine Arbeitskopie und pflegt Ihre Dateien sofort in das Projektarchiv ein. Typischerweise verwenden Sie diesen Befehl, wenn bereits ein Verzeichnisbaum besteht, den Sie aber in einem Subversion-Projektarchiv pflegen möchten. Zum Beispiel:

$ svnadmin create /var/svn/newrepos
$ svn import mytree file:///var/svn/newrepos/some/project \
             -m "Erstimport"
Hinzufügen     mytree/foo.c
Hinzufügen     mytree/bar.c
Hinzufügen     mytree/subdir
Hinzufügen     mytree/subdir/quux.h

Revision 1 übertragen.

Im vorstehenden Beispiel wurde der Inhalt des Verzeichnisses mytree unter dem Verzeichnis some/project im Projektarchiv abgelegt:

$ svn list file:///var/svn/newrepos/some/project
bar.c
foo.c
subdir/

Beachten Sie, dass nach dem Import der Originalbaum nicht in eine Arbeitskopie umgewandelt wird. Vor Beginn der Arbeit müssen Sie noch svn checkout ausführen, um eine frische Arbeitskopie des Baums zu erhalten.

Obwohl die Flexibilität von Subversion es Ihnen erlaubt, Ihr Projektarchiv nach Belieben aufzuteilen, empfehlen wir, ein Verzeichnis trunk für die „Hauptlinie“ der Entwicklung, ein Verzeichnis branches für Branch-Kopien und ein Verzeichnis tags für Tag-Kopien. Zum Beispiel:

$ svn list file:///var/svn/repos
/trunk
/branches
/tags

In Kapitel 4, Verzweigen und Zusammenführen werden Sie mehr über Branches und Tags erfahren. Details über das Aufsetzen mehrerer Projekte finden Sie in „Aufbau des Projektarchivs“, und in „Planung der Organisation Ihres Projektarchivs“ lesen Sie mehr über Wurzelverzeichnisse von Projekten.

Wenn Sie eine Subversion-Operation ausführen, für die Sie sich authentisieren müssen, speichert Subversion Ihre Zugangsdaten standardmäßig auf der Platte. Das geschieht zu Ihrer Annehmlichkeit, damit Sie bei künftigen Operationen nicht ständig Ihr Passwort eingeben müssen. Falls Sie wegen der Speicherung besorgt sein sollten, ^[3] können Sie das Zwischenspeichern entweder dauerhaft oder von Fall zu Fall abstellen.

Um das Passwort-Caching für einen bestimmten einmaligen Befehl zu unterbinden, übergeben Sie die --no-auth-cache-Option auf der Kommandozeile. Um das Caching dauerhaft abzustellen, können Sie der Subversion-Konfigurationsdatei Ihres lokalen Rechners die Zeile store-passwords = no hinzufügen. Für Details siehe „Zwischenspeicherung der Client-Zugangsdaten“.

Da Subversion standardmäßig Zugangsdaten speichert (sowohl den Benutzernamen als auch das Passwort), erinnert es sich bequemerweise, wer Sie das letzte Mal waren, als Sie Ihre Arbeitskopie modifizierten. Doch manchmal ist das nicht hilfreich – besonders, wenn Sie in einer gemeinsam benutzten Arbeitskopie arbeiten wie in einem Konfigurationsverzeichnis oder im Dokumenten-Wurzelverzeichnis eines Webservers. In diesem Fall brauchen Sie nur die --username-Option auf der Kommandozeile zu übergeben und Subversion versucht, sich als dieser Benutzer zu authentisieren und wird Sie, wenn nötig, zur Eingabe eines Passworts auffordern.

Wenn Sie in einem Projekt im Team zusammenarbeiten, sollten Sie Ihre Arbeitskopie aktualisieren, um die Änderungen zu bekommen, die die anderen Entwickler im Projekt seit Ihrer letzten Aktualisierung vorgenommen haben. Benutzen Sie svn update um Ihre Arbeitskopie synchron mit der letzten Revision im Projektarchiv zu bekommen:

$ svn update
U  foo.c
U  bar.c
Aktualisiert zu Revision 2.

In diesem Fall sieht es so aus, dass jemand Änderungen sowohl an foo.c als auch an bar.c übergeben hat, seit Sie das letzte Mal aktualisiert haben, und Subversion hat Ihre Arbeitskopie aktualisiert, damit sie beide Änderungen enthält.

Wenn der Server über svn update Änderungen an Ihre Arbeitskopie schickt, wird ein Buchstabencode neben jedem Objekt angezeigt, um Ihnen anzuzeigen, was Subversion gemacht hat, um die Arbeitskopie auf den neuesten Stand zu bringen. Zur Bedeutung der Buchstaben, rufen Sie svn help update auf.

Nun können Sie loslegen und Änderungen an Ihrer Arbeitskopie vornehmen. Normalerweise ist es am einfachsten, sich für eine bestimmte Änderung (oder eine Menge von Änderungen) zu entscheiden, etwa ein neues Feature zu implementieren oder einen Fehler zu beseitigen usw. Die Subversion-Befehle, die Sie hierfür verwenden werden sind svn add, svn delete, svn copy, svn move und svn mkdir. Falls Sie jedoch größtenteils Dateien editieren, die bereits mit Subversion verwaltet werden, brauchen Sie keinen dieser Befehle, bis Sie die Änderungen übergeben.

Sie können zwei Arten von Änderungen an Ihrer Arbeitskopie vornehmen: Dateiänderungen und Verzeichnisbaumänderungen. Sie brauchen Subversion nicht mitzuteilen, dass Sie beabsichtigen, eine Datei zu ändern; nehmen Sie einfach die Änderungen mit Ihrem Texteditor, Textverarbeitungsprogramm, Grafikprogramm oder sonstigen Programm vor, wie Sie es gewohnt sind. Subversion stellt automatisch fest, welche Dateien sich geändert haben und behandelt dabei Binärdateien genauso einfach wie Textdateien – und genauso effizient. Für Änderungen am Verzeichnisbaum können Sie Subversion mitteilen, Dateien und Verzeichnisse zum geplanten Entfernen, Hinzufügen, Kopieren oder Verschieben „vorzumerken“. Diese Änderungen finden sofort in Ihrer Arbeitskopie statt, doch nichts wird dem Projektarchiv hinzugefügt oder daraus entfernt, bevor Sie die Änderungen übergeben.

Hier ist ein Überblick der fünf Subversion-Unterbefehle, die Sie am häufigsten benutzen werden, um Änderungen am Verzeichnisbaum vorzunehmen:

Sobald Sie mit Ihren Änderungen fertig sind, müssen Sie sie ins Projektarchiv bringen; bevor Sie das jedoch machen, ist es normalerweise eine gute Idee, sich die Änderungen noch einmal anzusehen. Dadurch, dass Sie die Änderungen noch einmal begutachten, können Sie eine genauere Log-Nachricht schreiben. Sie könnten auch feststellen, dass Sie versehentlich eine Datei geändert haben, und hier haben Sie die Möglichkeit, vor der Übergabe die Änderung rückgängig zu machen. Zusätzlich bietet sich hierbei eine gute Gelegenheit, die Änderungen vor der Veröffentlichung noch einmal genau durchzugehen. Sie können sich mit svn status einen Überblick über Ihre Änderungen verschaffen und mit svn diff die Änderungen im Detail anzeigen lassen.

Subversion ist optimiert worden, um Ihnen bei dieser Aufgabe zu helfen, und es ist in der Lage, viele Dinge zu tun, ohne mit dem Projektarchiv kommunizieren zu müssen. Im Besonderen enthält Ihre Arbeitskopie eine versteckte „unveränderte“ Kopie jeder versionskontrollierten Datei innerhalb des .svn-Bereichs. Deswegen kann Ihnen Subversion schnell zeigen, wie sich Ihre bearbeiteten Dateien geändert haben, und es erlaubt Ihnen sogar, Ihre Änderungen zurückzunehmen, ohne Verbindung mit dem Projektarchiv aufnehmen zu müssen.

?       scratch.c           # Datei ist nicht versionskontrolliert
A       stuff/loot/bloo.h   # Datei ist zum Hinzufügen vorgemerkt
C       stuff/loot/lump.c   # Datei hat Konflikte durch einen Update
D       stuff/fish.c        # Datei ist zum Löschen vorgemerkt
M       bar.c               # Der Inhalt von bar.c hat lokale Änderungen

$ svn status stuff/fish.c
D      stuff/fish.c

$ svn status -v
M               44        23    sally     README
                44        30    sally     INSTALL
M               44        20    harry     bar.c
                44        18    ira       stuff
                44        35    harry     stuff/trout.c
D               44        19    ira       stuff/fish.c
                44        21    sally     stuff/things
A                0         ?     ?        stuff/things/bloo.h
                44        36    harry     stuff/things/gloo.c

$ svn status -u -v
M      *        44        23    sally     README
M               44        20    harry     bar.c
       *        44        35    harry     stuff/trout.c
D               44        19    ira       stuff/fish.c
A                0         ?     ?        stuff/things/bloo.h
Status bezogen auf Revision:   46

$ svn diff
Index: bar.c
===================================================================
--- bar.c   (revision 3)
+++ bar.c   (working copy)
@@ -1,7 +1,12 @@
+#include <sys/types.h>
+#include <sys/stat.h>
+#include <unistd.h>
+
+#include <stdio.h>

 int main(void) {
-  printf("Sixty-four slices of American Cheese...\n");
+  printf("Sixty-five slices of American Cheese...\n");
 return 0;
 }

Index: README
===================================================================
--- README  (revision 3)
+++ README  (working copy)
@@ -193,3 +193,4 @@
+Note to self:  pick up laundry.

Index: stuff/fish.c
===================================================================
--- stuff/fish.c    (revision 1)
+++ stuff/fish.c    (working copy)
-Welcome to the file known as 'fish'.
-Information on fish will be here soon.

Index: stuff/things/bloo.h
===================================================================
--- stuff/things/bloo.h (revision 8)
+++ stuff/things/bloo.h (working copy)
+Here is a new file to describe
+things about bloo.

$ svn diff > patchfile

Angenommen, Sie stellen beim Ansehen der Ausgabe von svn diff fest, dass alle Änderungen, die Sie an einer bestimmten Datei gemacht haben, fehlerhaft waren. Vielleicht hätten Sie die Datei überhaupt nicht ändern sollen, oder es wäre einfacher, von Anfang an unterschiedliche Änderungen zu machen.

Dies ist die perfekte Gelegenheit, svn revert zu benutzen:

$ svn revert README
Rückgängig gemacht: »README«

Subversion stellt die Datei wieder so her, wie sie vor der Änderung war, indem sie mit der „unveränderten“ Kopie aus dem Cache im .svn-Bereich überschrieben wird. Beachten Sie aber auch, dass svn revert jegliche vorgemerkten Operationen rückgängig machen kann – z.B. könnten Sie sich entscheiden, eine neue Datei erst gar nicht hinzufügen zu wollen:

$ svn status foo
?      foo

$ svn add foo
A         foo

$ svn revert foo
Rückgängig gemacht: »foo«

$ svn status foo
?      foo

	Anmerkung
	svn revert item hat genau denselben Effekt, wie item aus der Arbeitskopie zu löschen und dann svn update -r BASE item aufzurufen. Allerdings hat svn revert beim Rückgängigmachen einer Datei einen merklichen Unterschied – es muss beim Wiederherstellen der Datei nicht Verbindung mit dem Projektarchiv aufnehmen.

Oder vielleicht haben Sie die Datei versehentlich aus der Versionsverwaltung gelöscht:

$ svn status README

$ svn delete README
D         README

$ svn revert README
Rückgängig gemacht: »README«

$ svn status README

Wir haben bereits gesehen, wie svn status -u Konflikte vorhersagen kann. Angenommen, Sie starten svn update und einige interessante Dinge passieren:

$ svn update
U  INSTALL
G  README
Konflikt in »bar.c« entdeckt.
Auswahl: (p) zurückstellen, (df) voller Diff, (e) editieren,
        (h) Hilfe für weitere Optionen:

Die Codes U und G sind kein Grund zur Beunruhigung; diese Dateien haben die Änderungen aus dem Projektarchiv sauber aufgenommen. Die mit U markierten Dateien enthielten keine lokalen Änderungen, wurden jedoch mit Änderungen aus dem Projektarchiv geUpdatet. Das G steht für merGed, was bedeutet, dass die Datei zwar lokale Änderungen enthielt, die Änderungen aus dem Projektarchiv sich aber nicht damit überschnitten haben.

Die nächsten beiden Zeilen jedoch sind Teil eines Features (neu in Subversion 1.5) namens interaktive Konfliktauflösung. Das bedeutet, dass die Änderungen vom Server sich mit Ihren eigenen überschneiden, uns Sie nun die Gelegenheit haben, den Konflikt aufzulösen. Die gebräuchlichsten Optionen werden angezeigt, aber alle Optionen können sie sehen, wenn Sie h eintippen:

…
  (p)  zurückstellen      - den Konflikt erst später auflösen
  (df) voller Diff        - alle Änderungen in der zusammengeführten Datei anzeigen
  (e)  editieren          - zusammengeführte Datei in einem Editor ändern
  (r)  aufgelöst          - akzeptieren der zusammengeführten Version der Datei
  (mf) volle eigene Datei - die eigene Version der kompletten Datei akzeptieren
                            (ignorieren fremder Änderungen)
  (tf) volle fremde Datei - die fremde Version der kompletten Datei akzeptieren
                            (verlieren eigener Änderungen)
  (l)  starten            - Starten eines externen Programms zur Konfliktauflösung
  (h)  Hilfe              - diese Liste anzeigen

Bevor wir im Detail erklären, was jede Option bedeutet, gehen wir noch mal eben die Optionen durch.

Wir werden diese Befehle nun detaillierter behandeln, wobei sie nach Funktionalität gruppiert werden.

…
Select: (p) postpone, (df) diff-full, (e) edit,
        (h)elp for more options : d
--- .svn/text-base/sandwich.txt.svn-base      Tue Dec 11 21:33:57 2007
+++ .svn/tmp/tempfile.32.tmp     Tue Dec 11 21:34:33 2007
@@ -1 +1,5 @@
-Just buy a sandwich.
+<<<<<<< .mine
+Go pick up a cheesesteak.
+=======
+Bring me a taco!
+>>>>>>> .r32
…

$ svn update
Konflikt in »sandwich.txt« entdeckt.
Auswahl: (p) zurückstellen, (df) voller Diff, (e) editieren,
        (h) Hilfe für weitere Optionen: p
C  sandwich.txt
Aktualisiert zu Revision 2.
$ ls -1
sandwich.txt
sandwich.txt.mine
sandwich.txt.r1
sandwich.txt.r2

$ svn commit -m "Add a few more things"
svn: Übertragen schlug fehl (Details folgen):
svn: Übertragung abgebrochen: »/home/sally/svn-work/sandwich.txt« bleibt im Konflikt

$ svn resolve --accept working sandwich.txt
Konflikt von »sandwich.txt« aufgelöst

$ cat sandwich.txt
Top piece of bread
Mayonnaise
Lettuce
Tomato
Provolone
<<<<<<< .mine
Salami
Mortadella
Prosciutto
=======
Sauerkraut
Grilled Chicken
>>>>>>> .r2
Creole Mustard
Bottom piece of bread

<<<<<<< .mine
Salami
Mortadella
Prosciutto
=======

=======
Sauerkraut
Grilled Chicken
>>>>>>> .r2

Top piece of bread
Mayonnaise
Lettuce
Tomato
Provolone
Salami
Mortadella
Prosciutto
Creole Mustard
Bottom piece of bread

$ svn resolve --accept working sandwich.txt
Konflikt von »sandwich.txt« aufgelöst
$ svn commit -m "Mach weiter mit meinem Sandwich, vergiss Sallys Änderungen."

$ svn update
Konflikt in »sandwich.txt« entdeckt.
Auswahl: (p) zurückstellen, (df) voller Diff, (e) editieren,
        (h) Hilfe für weitere Optionen: p
C    sandwich.txt
Aktualisiert zu Revision 2.
$ ls sandwich.*
sandwich.txt  sandwich.txt.mine  sandwich.txt.r2  sandwich.txt.r1
$ svn resolve --accept theirs-full sandwich.txt
Konflikt von »sandwich.txt« aufgelöst

$ svn revert sandwich.txt
Rückgängig gemacht: »sandwich.txt«
$ ls sandwich.*
sandwich.txt

Endlich! Sie haben die Bearbeitung abgeschlossen, Sie haben alle Änderungen vom Server eingearbeitet, und Sie sind bereit, Ihre Änderungen an das Projektarchiv zu übergeben.

Der Befehl svn commit schickt all Ihre Änderungen zum Projektarchiv. Wenn Sie eine Änderung übergeben, müssen Sie einen Protokolleintrag erstellen, der die Änderung beschreibt. Dieser Eintrag wird mit der von Ihnen erzeugten neuen Revision verknüpft. Wenn Ihr Eintrag kurz ist, können Sie ihn mit der Option --message (oder -m) in der Kommandozeile angeben:

$ svn commit -m "Anzahl Käsescheiben korrigiert."
Sende          sandwich.txt
Übertrage Daten .
Revision 3 übertragen.

Falls Sie jedoch Ihren Protokolleintrag während der Arbeit erstellen möchten, können Sie Subversion mitteilen, sich den Eintrag aus einer Datei zu holen, indem Sie den Dateinamen mit der Option --file (-F) angeben:

$ svn commit -F logmsg
Sende          sandwich.txt
Übertrage Daten .
Revision 4 übertragen.

Sollten Sie vergessen, entweder die Option --message oder die --file-Option anzugeben, startet Subversion automatisch Ihren Lieblingseditor (siehe die Information zu editor-cmd in „Config“), damit Sie einen Protokolleintrag erstellen können.

Tipp

Wenn Sie gerade in Ihrem Editor einen Eintrag schreiben und sich entschließen, die Übergabe abzubrechen, können Sie einfach Ihren Editor beenden, ohne die Änderungen zu sichern. Falls Sie den Eintrag bereits gesichert haben sollten, löschen Sie einfach den Text, sichern Sie erneut und brechen dann ab: $ svn commit Logmeldung unverändert oder nicht angegeben A)bbrechen, Weitermac)hen, E)ditieren: a $

Das Projektarchiv weiß nicht, ob Ihre Änderung im Ganzen einen Sinn ergeben, es ist ihm auch egal; es überprüft lediglich, ob nicht irgendjemand anderes irgendeine derselben Dateien geändert hat wie Sie, als Sie mal weggeschaut haben. Falls jemand das gemacht hat, wird die gesamte Übergabe mit einer Meldung fehlschlagen, dass eine oder mehrere Ihrer Dateien nicht mehr aktuell sind:

$ svn commit -m "Noch eine Regel hinzufügen"
Sende          rules.txt
svn: Übertragen schlug fehl (Details folgen):
svn: Datei »/rules.txt« ist veraltet
…

(Der genaue Wortlaut dieser Fehlermeldung hängt vom verwendeten Netzwerkprotokoll und vom Server ab, doch die Bedeutung ist in allen Fällen gleich.)

Zu diesem Zeitpunkt müssen Sie svn update aufrufen, sich um eventuelle Zusammenführungen oder Konflikte kümmern und die Übergabe erneut versuchen.

Das deckt den grundlegenden Arbeitszyklus für die Verwendung von Subversion ab. Subversion bietet viele andere Möglichkeiten, die Sie benutzen können, um Ihr Projektarchiv und Ihre Arbeitskopie zu verwalten, doch der größte Teil Ihrer täglichen Arbeit mit Subversion wird lediglich die in diesem Kapitel behandelten Befehle berühren. Wir werden jedoch noch ein paar mehr Befehle behandeln, die Sie ziemlich oft verwenden werden.

Um Informationen über den Werdegang einer Datei oder eines Verzeichnisses zu bekommen, benutzen Sie den Befehl svn log. svn log versorgt Sie mit einem Eintrag, der Auskunft darüber gibt, wer Änderungen an einer Datei oder einem Verzeichnis gemacht hat, in welcher Revision die Änderung stattfand, zu welcher Zeit und welchem Datum die Revision entstand sowie – falls verfügbar – dem die Übergabe begleitenden Protokolleintrag:

$ svn log
------------------------------------------------------------------------
r3 | sally | 2008-05-15 23:09:28 -0500 (Thu, 15 May 2008) | 1 line

include-Zeilen hinzugefügt und Anzahl der Käsescheiben korrigiert.
------------------------------------------------------------------------
r2 | harry | 2008-05-14 18:43:15 -0500 (Wed, 14 May 2008) | 1 line

main()-Methoden hinzugefügt.
------------------------------------------------------------------------
r1 | sally | 2008-05-10 19:50:31 -0500 (Sat, 10 May 2008) | 1 line

Erstimport
------------------------------------------------------------------------

Beachten Sie, dass die Protokolleinträge standardmäßig in umgekehrter zeitlicher Reihenfolge ausgegeben werden. Falls Sie eine andere Folge von Revisionen in einer bestimmten Anordnung oder nur eine einzige Revision sehen möchten, übergeben Sie die Option --revision (-r):

$ svn log -r 5:19    # zeigt Protokolleintrag 5 bis 19 in chronologischer Reihenfolge

$ svn log -r 19:5    # zeigt Protokolleintrag 5 bis 19 in umgekehrter Reihenfolge

$ svn log -r 8       # zeigt Protokolleintrag für Revision 8

Sie können sich auch die Protokollgeschichte einer einzigen Datei oder eines einzigen Verzeichnisses ansehen. Zum Beispiel:

$ svn log foo.c
…
$ svn log http://foo.com/svn/trunk/code/foo.c
…

Diese Befehle zeigen nur Protokolleinträge für die Revisionen, in der sich die Arbeitsdatei (oder URL) geändert hat.

Wenn Sie noch mehr Informationen über eine Datei oder ein Verzeichnis benötigen, können Sie svn log auch die Option --verbose (-v) mitgeben. Weil Ihnen Subversion erlaubt, Dateien und Verzeichnisse zu kopieren und zu verschieben, ist es wichtig, Pfadänderungen im Dateisystem mitzuverfolgen. Daher beinhaltet bei dieser Option die Ausgabe von svn log eine Liste veränderter Pfade in einer Revision:

$ svn log -r 8 -v
------------------------------------------------------------------------
r8 | sally | 2008-05-21 13:19:25 -0500 (Wed, 21 May 2008) | 1 line
Geänderte Pfade:
   M /trunk/code/foo.c
   M /trunk/code/bar.h
   A /trunk/code/doc/README

Die Unterraumwinde gefrozzelt.

------------------------------------------------------------------------

svn log akzeptiert ebenfalls die Option --quiet (-q), die den Protokolleintrag unterdrückt. Zusammen mit der Option --verbose zeigt es nur die Namen der geänderten Dateien an.

$ svn log -r 2
------------------------------------------------------------------------
$

svn diff ist uns bereits begegnet – es zeigt Dateiunterschiede im unified-diff-Format; wir verwendeten es, um die lokalen Änderungen an unserer Arbeitskopie anzuzeigen, bevor wir sie dem Projektarchiv übergaben.

Tatsächlich stellt sich heraus, dass es drei verschiedene Verwendungsmöglichkeiten für svn diff gibt:

$ svn diff
Index: rules.txt
===================================================================
--- rules.txt   (revision 3)
+++ rules.txt   (working copy)
@@ -1,4 +1,5 @@
 Be kind to others
 Freedom = Responsibility
 Everything in moderation
-Chew with your mouth open
+Chew with your mouth closed
+Listen when others are speaking
$

$ svn diff -r 3 rules.txt
Index: rules.txt
===================================================================
--- rules.txt   (revision 3)
+++ rules.txt   (working copy)
@@ -1,4 +1,5 @@
 Be kind to others
 Freedom = Responsibility
 Everything in moderation
-Chew with your mouth open
+Chew with your mouth closed
+Listen when others are speaking
$

$ svn diff -r 2:3 rules.txt
Index: rules.txt
===================================================================
--- rules.txt   (revision 2)
+++ rules.txt   (revision 3)
@@ -1,4 +1,4 @@
 Be kind to others
-Freedom = Chocolate Ice Cream
+Freedom = Responsibility
 Everything in moderation
 Chew with your mouth open
$

$ svn diff -c 3 rules.txt
Index: rules.txt
===================================================================
--- rules.txt   (revision 2)
+++ rules.txt   (revision 3)
@@ -1,4 +1,4 @@
 Be kind to others
-Freedom = Chocolate Ice Cream
+Freedom = Responsibility
 Everything in moderation
 Chew with your mouth open
$

$ svn diff -c 5 http://svn.example.com/repos/example/trunk/text/rules.txt
…
$

Wenn Sie svn cat und svn list verwenden, können Sie sich verschiedene Revisionen von Dateien und Verzeichnissen ansehen, ohne die Revision Ihrer Arbeitskopie ändern zu müssen. Tatsächlich brauchen Sie dafür nicht einmal eine Arbeitskopie.

$ svn cat -r 2 rules.txt
Be kind to others
Freedom = Chocolate Ice Cream
Everything in moderation
Chew with your mouth open
$

$ svn cat -r 2 rules.txt > rules.txt.v2
$

svn list

Der Befehl svn list zeigt Ihnen, welche Dateien sich in einem Projektarchiv-Verzeichnis befinden, ohne die Dateien auf Ihren lokalen Rechner herunterladen zu müssen:

$ svn list http://svn.collab.net/repos/svn
README
branches/
clients/
tags/
trunk/

Falls Sie eine detailliertere Auflistung wünschen, übergeben Sie die Option --verbose (-v), um eine Ausgabe ähnlich der folgenden zu bekommen:

$ svn list -v http://svn.collab.net/repos/svn
  20620 harry            1084 Jul 13  2006 README
  23339 harry                 Feb 04 01:40 branches/
  21282 sally                 Aug 27 09:41 developer-resources/
  23198 harry                 Jan 23 17:17 tags/
  23351 sally                 Feb 05 13:26 trunk/

Die Spalten zeigen Ihnen die Revision, in der die Datei zuletzt geändert wurde, den Benutzer, der sie änderte, die Größe, falls es sich um eine Datei handelt, sowie den Namen des Objektes.

	Warnung
	Der Befehl svn list ohne Argumente verwendet standardmäßig den Projektarchiv-URL des aktuellen Arbeitsverzeichnisses und nicht das Verzeichnis der lokalen Arbeitskopie. Schließlich können Sie, falls Sie eine Auflistung des lokalen Verzeichnisses möchten, das einfache ls (oder irgendein vernünftiges nicht-unixartiges Äquivalent) benutzen.

Zusätzlich zu den obigen Befehlen können Sie svn update und svn checkout mit der Option --revision verwenden, um eine vollständige Arbeitskopie „zeitlich zurückzusetzen“: ^[7]

$ svn checkout -r 1729 # Checkt eine neue Arbeitskopie von r1729 aus
…
$ svn update -r 1729 # Aktualisiert eine bestehende Arbeitskopie auf r1729
…

Tipp

Viele Subversion-Neulinge versuchen das vorangehende svn update-Beispiel zu verwenden, um übergebene Änderungen „rückgängig“ zu machen, was allerdings nicht funktioniert, da Sie keine Änderungen übergeben können, die Sie durch das zeitliche Zurücksetzen einer Arbeitskopie erhalten haben, falls die geänderten Dateien neuere Revisionen haben. Siehe „Zurückholen gelöschter Objekte“ für eine Beschreibung, wie eine Übergabe „rückgängig“ gemacht wird.

Wenn Sie am Ende ein Release bauen und die Dateien aus Subversion zu einem Bündel schnüren möchten, ohne allerdings diese verdammten .svn-Verzeichnisse dabei zu haben, können Sie svn export verwenden, um eine lokale Kopie des gesamten oder teilweisen Projektarchivs ohne .svn-Verzeichnisse zu erhalten. Wie bei svn update und svn checkout können Sie auch hier die Option --revision an svn export übergeben:

$ svn export http://svn.example.com/svn/repos1 # Exportiert die letzte Revision
…
$ svn export http://svn.example.com/svn/repos1 -r 1729
# Exportiert Revision r1729
…

Subversion merkt sich weder den Zustand noch das Vorhandensein einer Arbeitskopie auf dem Server, so dass serverseitig kein Aufwand für Arbeitskopien anfällt. Dementsprechend besteht keine Notwendigkeit, dem Server mitzuteilen, dass Sie vorhaben, eine Arbeitskopie zu löschen.

Falls die Wahrscheinlichkeit besteht, dass Sie eine Arbeitskopie wiederverwenden möchten, ist es nicht verkehrt, sie einfach auf der Platte zu lassen, bis Sie sie wieder benutzen wollen. Zu diesem Zeitpunkt reicht lediglich ein svn update zum Aktualisieren, und sie ist gebrauchsfertig.

Falls Sie die Arbeitskopie jedoch bestimmt nicht mehr verwenden möchten, können Sie sie ruhig löschen; jedoch sollten Sie vorher darin nach unversionierten Dateien suchen. Um diese Dateien zu finden, rufen Sie svn status auf und untersuchen alle Dateien, denen ein ? voransteht, um sicherzugehen, dass sie nicht wichtig sind. Wenn Sie die Untersuchung abgeschlossen haben, können Sie Ihre Arbeitskopie ruhig löschen.

Wenn Subversion Ihre Arbeitskopie (oder irgendwelche Informationen in .svn) verändert, versucht es das so sicher wie möglich zu machen. Bevor die Arbeitskopie geändert wird, schreibt Subversion seine Absichten in eine Protokolldatei. Dann führt es die Befehle in der Protokolldatei aus, um die Änderungen anzuwenden, wobei es während der Arbeit den relevanten Teil der Arbeitskopie sperrt, um andere Clients davon abzuhalten, während der Änderung auf die Arbeitskopie zuzugreifen. Zuletzt entfernt Subversion die Protokolldatei. Architektonisch ist dies ähnlich wie bei einem Dateisystem mit Journal. Falls eine Subversion-Operation unterbrochen wird (z.B. wenn der Prozess abgeschossen wird oder der Rechner abstürzt), bleibt die Protokolldatei auf der Platte. Durch das erneute Ausführen der Protokolldatei kann Subversion die vorher begonnene Operation vervollständigen und Ihre Arbeitskopie gelangt wieder in einen konsistenten Zustand.

Genau das macht svn cleanup: Es durchsucht Ihre Arbeitskopie und führt etwaige übrig gebliebene Protokolldateien aus, wobei Sperren in der Arbeitskopie entfernt werden. Fall Ihnen Subversion jemals mitteilt, dass ein Teil Ihrer Arbeitskopie „gesperrt“ ist, sollten Sie diesen Befehl aufrufen. Darüberhinaus zeigt svn status ein L neben gesperrten Objekten an:

$ svn status
  L    somedir
M      somedir/foo.c

$ svn cleanup
$ svn status
M      somedir/foo.c

Der Subversion-Client versteht eine Reihe von Revisions-Schlüsselworten. Diese Schlüsselworte können der Option --revision (-r) anstatt ganzer Zahlen als Optionsargument übergeben werden; sie werden von Subversion zu bestimmten Revisionsnummern aufgelöst:

Wie aus den Beschreibungen abgeleitet werden kann, werden die Revisions-Schlüsselworte PREV, BASE und COMMITTED nur in Bezug auf einen Pfad der Arbeitskopie verwendet – sie sind nicht auf URLs des Projektarchivs anwendbar. HEAD kann hingegen in Verbindung mit beiden Pfadtypen verwendet werden.

Hier ein paar Beispiele zur Verwendung von Revisions-Schlüsselworten:

$ svn diff -r PREV:COMMITTED foo.c
# zeigt die letzte übergebene Änderung von foo.c an

$ svn log -r HEAD
# gibt die Protokollnachricht der letzten Übergabe an das
# Projektarchiv aus

$ svn diff -r HEAD
# vergleicht Ihre Arbeitskopie (mit allen lokalen Änderungen) mit der
# letzten Version dieses Baums im Projektarchiv

$ svn diff -r BASE:HEAD foo.c
# vergleicht die unmodifizierte Version von foo.c mit der letzten
# Version von foo.c im Projektarchiv

$ svn log -r BASE:HEAD
# gibt alle Übergabe-Protokollnachrichten des aktuellen versionierten
# Verzeichnisses seit der letzten Aktualisierung aus

$ svn update -r PREV foo.c
# macht die letzte Änderung an foo.c rückgängig, indem die
# Arbeitsrevision von foo.c vermindert wird

$ svn diff -r BASE:14 foo.c
# vergleicht die unmodifizierte Version von foo.c mit foo.c in der
# Revision 14

Revisionsnummern offenbaren nichts über die Welt außerhalb des Versionskontrollsystems, doch manchmal müssen Sie einen Zeitpunkt mit einem Moment der Versionsgeschichte korrelieren. Um das zu ermöglichen, erlaubt die Option --revision (-r) auch Datumsangaben in geschweiften Klammern ({ und }). Subversion akzeptiert die standardisierten ISO-8601 Datums- und Zeitformate und ein paar weitere. Hier sind einige Beispiele. (Denken Sie daran, bei Daten die Leerzeichen enthalten, Anführungszeichen zu verwenden.)

$ svn checkout -r {2006-02-17}
$ svn checkout -r {15:30}
$ svn checkout -r {15:30:00.200000}
$ svn checkout -r {"2006-02-17 15:30"}
$ svn checkout -r {"2006-02-17 15:30 +0230"}
$ svn checkout -r {2006-02-17T15:30}
$ svn checkout -r {2006-02-17T15:30Z}
$ svn checkout -r {2006-02-17T15:30-04:00}
$ svn checkout -r {20060217T1530}
$ svn checkout -r {20060217T1530Z}
$ svn checkout -r {20060217T1530-0500}
…

Falls Sie ein Datum angeben, wandelt Subversion dieses Datum in die letzte Revision zum Zeitpunkt dieses Datums um und verwendet dann die entsprechende Revisionsnummer:

$ svn log -r {2006-11-28}
------------------------------------------------------------------------
r12 | ira | 2006-11-27 12:31:51 -0600 (Mon, 27 Nov 2006) | 6 lines
…

Sie können auch einen Zeitraum angeben. Subversion findet dann alle Revisionen zwischen den und einschließlich der Daten:

$ svn log -r {2006-11-20}:{2006-11-29}
…

Warnung

Da der Zeitstempel einer Revision als eine unversionierte, änderbare Eigenschaft einer Revision gespeichert ist (siehe „Eigenschaften“), können Revisions-Zeitstempel geändert werden, um die wahre Chronologie zu fälschen, oder gar vollständig entfernt werden. Die Fähigkeit von Subversion, Revisionsdaten in Revisionsnummern überführen zu können, beruht auf einer sequentiellen Ordnung der Revisions-Zeitstempel – je jünger die Revision, desto jünger der Zeitstempel. Falls diese Ordnung nicht aufrechterhalten wird, werden Sie voraussichtlich feststellen, dass der Versuch, Daten zur Angabe von Revisionsbereichen in Ihrem Projektarchiv zu verwenden, nicht immer die Daten zurückliefern wird, die Sie erwartet hätten.

Ebenso wie Subversion Eigenschaften verwendet, um zusätzliche Informationen über die enthaltenen Dateien, Verzeichnisse und Revisionen zu speichern, könnten Eigenschaften auch für Sie ähnlich von Nutzen sein. Sie werden es vielleicht als nützlich ansehen, wenn Sie in der Nähe Ihrer versionierten Daten spezielle Metadaten dazu unterbringen können.

Nehmen wir mal an, Sie möchten eine Webpräsenz entwerfen, die viele digitale Fotos mit Bildunterschrift und Zeitstempel anzeigen soll. Da sich die Menge Ihrer Fotos ständig ändert, möchten Sie soviel wie möglich automatisieren. Die Fotos können ziemlich groß werden, so dass Sie den Besuchern Ihrer Seite Miniaturvorschaubilder anbieten möchten.

Natürlich können Sie diese Funktionalität auch mit herkömmlichen Dateien hinbekommen. Das bedeutet, Sie haben image123.jpg und image123-thumbnail.jpg gemeinsam in einem Verzeichnis. Oder Sie speichern die Vorschaubildchen in einem anderen Verzeichnis, etwa thumbnails/image123.jpg, falls Sie die gleichen Dateinamen beibehalten möchten. Sie können auch die Bildunterschriften und Zeitstempel auf ähnliche Weise speichern, ebenso vom Originalbild getrennt. Das Problem hierbei ist jedoch, dass sich Ihre Ansammlung an Dateien mit jedem neu hinzugefügten Bild vervielfältigt.

Betrachten Sie nun dieselbe Webpräsenz, eingerichtet unter Verwendung der Datei-Eigenschaften von Subversion. Stellen Sie sich vor, sie hätten eine einzelne Bilddatei image123.jpg mit Eigenschaften namens Unterschrift, Zeitstempel und sogar Vorschaubild. Jetzt sieht Ihr Verzeichnis viel überschaubarer aus – tatsächlich sieht es für den flüchtigen Betrachter aus, als befänden sich dort nur Bilddateien. Ihre Automatisierungs-Skripte wissen es jedoch besser. Sie wissen, dass sie svn verwenden können (oder noch besser, die Subversion-Sprachschnittstellen – siehe „Benutzung der APIs“), um die von Ihrer Webpräsenz zusätzlich benötigten Informationen herauszuholen, ohne eine Indexdatei lesen oder Pfad-Umbenennungs-Spielereien machen zu müssen.

Anmerkung

Obwohl Subversion kaum Einschränkungen für die von Ihnen verwendeten Namen und Werte für Eigenschaften macht, ist es nicht entworfen worden, um optimal mit großen Eigenschafts-Werten oder umfangreichen Eigenschafts-Mengen für eine bestimmte Datei oder ein Verzeichnis umgehen zu können. Gewöhnlich behält Subversion gleichzeitig alle Eigenschafts-Namen und -Werte im Speicher, die zu einem einzelnen Objekt gehören, was bei umfangreichen Eigenschafts-Mengen zu erheblichen Leistungseinbußen oder fehlgeschlagenen Operationen führen kann.

Spezielle Revisions-Eigenschaften sind auch sehr verbreitet. Eine übliche Verwendung ist es, eine Eigenschaft zu benutzen, deren Wert die Kennzeichnung eines Fehlers in einem Fehlerverwaltungssystem ist, mit dem die Revision in Beziehung gebracht wird, etwa weil eine mit dieser Revision vorgenommene Änderung den entsprechenden Fehler behebt. Andere Anwendungsfälle beinhalten die Vergabe anwenderfreundlicher Namen für die Revision – es könnte schwierig sein, sich zu erinnern, dass Revision 1935 vollständig getestet war. Wenn es jedoch eine Eigenschaft Testergebnis mit dem Wert alles bestanden für diese Revision gibt, ist das eine durchaus nützliche Information.

Issue(s): IZ2376, IZ1919
Reviewed by:  sally

This fixes a nasty segfault in the wort frabbing process
…

Das Programm svn gestattet es, Datei und Verzeichnis-Eigenschaften auf verschiedene Weise hinzuzufügen oder zu ändern. Für Eigenschaften mit kurzen, menschenlesbaren Werten ist es vermutlich am einfachsten, eine neue Eigenschaft zu vergeben, indem deren Name und Wert auf der Kommandozeile für den Unterbefehl svn propset angegeben wird:

$ svn propset copyright '(c) 2006 Red-Bean Software' calc/button.c
Eigenschaft »copyright« für »calc/button.c« gesetzt
$

Jedoch haben wir die von Subversion gebotene Flexibilität bei der Behandlung Ihrer Eigenschafts-Werte angepriesen; und wenn Sie planen, einen mehrzeiligen textuellen oder sogar binären Eigenschafts-Wert zu verwenden, wollen Sie diesen wahrscheinlich nicht auf den Kommandozeile angeben. Deshalb besitzt der Unterbefehl svn propset eine Option --file (-F), um den Namen einer Datei angeben zu können, deren Inhalt den neuen Eigenschafts-Wert ergibt.

$ svn propset license -F /path/to/LICENSE calc/button.c
Eigenschaft »license« für »calc/button.c« gesetzt
$

Es gibt einige Einschränkungen für die Vergabe von Namen für Eigenschaften. Ein Eigenschafts-Name muss mit einem Buchstaben, einem Doppelpunkt (:) oder einem Unterstrich (_) beginnen; danach können Sie auch Ziffern, Bindestriche (-) und Punkte (.) verwenden. ^[8]

Zusätzlich zum Befehl propset bietet das Programm svn den Befehl propedit. Dieser Befehl verwendet den konfigurierten Editor (siehe „Config“), um Eigenschaften hinzuzufügen oder zu ändern. Wenn Sie den Befehl aufrufen, startet svn Ihren Editor mit einer temporären Datei, die den gegenwärtigen Wert der Eigenschaft beinhaltet (oder leer ist, falls Sie eine neue Eigenschaft hinzufügen). Dann bearbeiten Sie diesen Wert in Ihrem Editor bis er dem Wert entspricht, den Sie für die Eigenschaft verwenden möchten, speichern die Datei und beenden den Editor. Falls Subversion feststellt, dass Sie tatsächlich den bestehenden Wert der Eigenschaft geändert haben, wird das als neuer Wert angenommen. Wenn Sie Ihren Editor ohne Änderungen beenden, wird die Eigenschaft nicht verändert:

$ svn propedit copyright calc/button.c  ### Editor ohne Änderung verlassen
Keine Änderungen der Eigenschaft »copyright« für »calc/button.c«
$

Hier sollten wir anmerken, dass die svn-Unterbefehle, die mit Eigenschaften zu tun haben, ähnlich wie bei anderen Unterbefehlen, auch auf mehrere Pfade gleichzeitig angewendet werden können. Dadurch wird es Ihnen ermöglicht, mit einem Befehl die Eigenschaften auf einer Menge von Dateien zu bearbeiten. Wir hätten beispielsweise das Folgende machen können:

$ svn propset copyright '(c) 2006 Red-Bean Software' calc/*
Eigenschaft »copyright« für »calc/Makefile« gesetzt
Eigenschaft »copyright« für »calc/button.c« gesetzt
Eigenschaft »copyright« für »calc/integer.c« gesetzt
…
$

Das ganze Hinzufügen und Bearbeiten von Eigenschaften ist nicht gerade nützlich, falls an die gespeicherten Werte nicht einfach heranzukommen ist. Also bietet das Programm svn zwei Unterbefehle zur Anzeige der Namen und Werte von Eigenschaften an Dateien und Verzeichnissen. Der Befehl svn proplist listet alle Eigenschafts-Namen auf, die für einen Pfad vergeben sind. Sobald Sie die Eigenschafts-Namen auf einem Element kennen, können Sie die Werte einzeln mittels svn propget abrufen. Wenn diesem Befehl ein Eigenschafts-Name und ein Pfad (oder eine Menge von Pfaden) mitgegeben wird, wird der Wert der Eigenschaft nach Standardausgabe geschrieben.

$ svn proplist calc/button.c
Eigenschaften zu »calc/button.c«:
  copyright
  license
$ svn propget copyright calc/button.c
(c) 2006 Red-Bean Software

Es gibt sogar eine Variante des Befehls proplist, die es erlaubt, sowohl die Namen als auch die Werte aller Eigenschaften auszugeben. Übergeben Sie einfach die Option --verbose (-v).

$ svn proplist -v calc/button.c
Eigenschaften für »calc/button.c«:
  copyright : (c) 2006 Red-Bean Software
  license : ================================================================
Copyright (c) 2006 Red-Bean Software.  All rights reserved.

Redistribution and use in source and binary forms, with or without
modification, are permitted provided that the following conditions 
are met:

1. Redistributions of source code must retain the above copyright
notice, this list of conditions, and the recipe for Fitz's famous
red-beans-and-rice.
…

Der letzte Unterbefehl, der mit Eigenschaften zu tun hat, ist propdel. Da Subversion Eigenschaften mit leeren Werten erlaubt, können Sie eine Eigenschaft nicht vollständig mit svn propedit oder mit svn propset entfernen. So hat beispielsweise dieser Befehl nicht den erwünschten Effekt:

$ svn propset license '' calc/button.c
Eigenschaft »license« für »calc/button.c« gesetzt
$ svn proplist -v calc/button.c
Eigenschaften zu »calc/button.c«:
  copyright : (c) 2006 Red-Bean Software
  license : 
$

Zum vollständigen Löschen von Eigenschaften müssen Sie den Unterbefehl propdel verwenden. Die Syntax ist den anderen Eigenschafts-Befehlen ähnlich:

$ svn propdel license calc/button.c
Eigenschaft »license« wurde von »calc/button.c« gelöscht.
$ svn proplist -v calc/button.c
Eigenschaften zu »calc/button.c«:
  copyright : (c) 2006 Red-Bean Software
$

Können Sie sich an diese unversionierten Revisions-Eigenschaften erinnern? Auch diese können Sie mit den eben beschriebenen Unterbefehlen von svn verändern. Geben Sie einfach den Kommandozeilenparameter --revprop an und die Revision, deren Eigenschaft Sie ändern möchten. Da Revisionen global sind, brauchen Sie keinen Zielpfad für diese Eigenschafts-Unterbefehle anzugeben sofern Sie sich in einer Arbeitskopie des Projektarchivs befinden, deren Revisions-Eigenschaft Sie ändern möchten. Anderenfalls können Sie den URL irgendeines Pfades im entsprechenden Projektarchiv angeben (inklusive des Wurzelverzeichnisses des Projektarchivs). Sie möchten beispielsweise die Protokollnachricht einer bestehenden Revision ändern. ^[9] Falls Ihr aktuelles Arbeitsverzeichnis Teil einer Arbeitskopie Ihres Projektarchivs ist, können Sie einfach den Befehl svn propset ohne Zielpfad aufrufen:

$ svn propset svn:log '* button.c: Fix a compiler warning.' -r11 --revprop
Eigenschaft »svn:log« wurde für Revision »11« im Projektarchiv gesetzt
$

Selbst wenn Sie keine Arbeitskopie aus diesem Projektarchiv ausgecheckt haben, können Sie dennoch die Änderung an der Eigenschaft durchführen, indem Sie den URL der Wurzel des Projektarchivs angeben:

$ svn propset svn:log '* button.c: Fix a compiler warning.' -r11 --revprop \
              http://svn.example.com/repos/project
Eigenschaft »svn:log« wurde für Revision »11« im Projektarchiv gesetzt.
$

Beachten Sie, dass die Fähigkeit, diese unversionierten Eigenschaften zu verändern, ausdrücklich vom Administrator des Projektarchivs hinzugefügt werden muss (siehe „Berichtigung des Protokolleintrags“). Das geschieht aus dem Grund, dass diese Eigenschaften nicht versioniert sind, und Sie Gefahr laufen, durch unvorsichtiges Bearbeiten Informationen zu verlieren. Der Administrator des Projektarchivs kann Schutzmaßnahmen gegen diesen Verlust ergreifen, und standardmäßig ist die Veränderung unversionierter Eigenschaften nicht freigeschaltet.

Tipp

Benutzer sollten nach Möglichkeit svn propedit statt svn propset verwenden. Während das Endergebnis dieser Befehle identisch ist, wird bei ersterem der aktuelle Wert der zu ändernden Eigenschaft angezeigt, was dabei hilft, sicherzustellen, dass die Änderung auch die beabsichtigte war. Das gilt besonders für unversionierte Revisions-Eigenschaften. Darüber hinaus ist es auch bedeutend einfacher, mehrzeilige Eigenschafts-Werte in einem Texteditor statt auf der Kommandozeile zu bearbeiten.

Jetzt, da Sie mit allen svn-Unterbefehlen vertraut sind, die mit Eigenschaften zu tun haben, wollen wir uns ansehen, welche Auswirkungen Änderungen an Eigenschaften auf den üblichen Arbeitsablauf von Subversion haben. Wie wir bereits früher erwähnten, sind Eigenschaften von Dateien und Verzeichnissen versioniert, genau so wie der Dateiinhalt. Deshalb bietet Subversion dieselben Möglichkeiten für das Zusammenführen der Änderungen anderer mit Ihren eigenen – sauber oder konfliktbehaftet.

Wie bei Dateiinhalten handelt es sich bei Ihren Eigenschafts-Änderungen um lokale Modifikationen, die erst dann dauerhaft werden, wenn Sie sie mittels svn commit an das Projektarchiv übergeben. Ihre Eigenschafts-Änderungen können auch leicht rückgängig gemacht werden – der Befehl svn revert bringt Ihre Dateien und Verzeichnisse wieder in den unbearbeiteten Zustand – und zwar Inhalt, Eigenschaften und alles andere. Auch können Sie durch die Benutzung der Befehls svn status und svn diff interessante Informationen über den Status Ihrer Datei- und Verzeichnis-Eigenschaften erhalten.

$ svn status calc/button.c
 M     calc/button.c
$ svn diff calc/button.c
Eigenschaftsänderungen: calc/button.c
___________________________________________________________________
Name: copyright
   + (c) 2006 Red-Bean Software

$

Beachten Sie, dass der Unterbefehl status das M in der zweiten statt in der ersten Spalte anzeigt. Das geschieht, da wir zwar die Eigenschaften von calc/button.c verändert haben, nicht jedoch dessen Inhalt. Hätten wir beides geändert, würden wir M auch in der ersten Spalte sehen. (svn status behandeln wir in „Verschaffen Sie sich einen Überblick über Ihre Änderungen“).

$ svn update calc
M  calc/Makefile.in
Konflikt für Eigenschaft »linecount« für »calc/button.c« entdeckt.
Auswahl: (p) zurückstellen, (df) voller Diff, (e) editieren,
         (h) Hilfe für weitere Optionen: p
 C calc/button.c
Aktualisiert zu Revision 143.
$ 

$ svn status calc
 C     calc/button.c
?      calc/button.c.prej
$ cat calc/button.c.prej 
Versuch, die Eigenschaft »linecount« von »1267« in »1301« zu ändern,
aber die Eigenschaft wurde lokal von »1267« in »1256« geändert.
$

Sie haben vielleicht auch die ungewöhnliche Art und Weise bemerkt, wie Subversion momentan Unterschiede von Eigenschaften darstellt. Sie können immer noch svn diff verwenden und dessen Ausgabe umleiten, um eine Patch-Datei zu erzeugen. Das Programm patch ignoriert Patches für Eigenschaften – es ignoriert regelmäßig alles, was es nicht versteht. Das bedeutet leider, dass für die vollständige Anwendung eines durch svn diff erzeugten Patches sämtliche Änderungen an Eigenschaften manuell nachgezogen werden müssen.

Eigenschaften sind eine mächtige Funktionalität von Subversion, die als Schlüsselkomponenten zahlreicher Subversion-Funktionen agieren, welche an anderer Stelle in diesem und in anderen Kapiteln erörtert werden – Unterstützung textueller Diffs und Zusammenführungen, Ersetzung von Schlüsselworten, Umwandlung von Zeilenenden, usw. Um jedoch den größten Nutzen aus Eigenschaften ziehen zu können, müssen sie auf den richtigen Dateien und Verzeichnissen gesetzt sein. Leider kann dieser Schritt leicht in der täglichen Routine vergessen werden, besonders deshalb, da das Versäumen des Setzens einer Eigenschaft normalerweise nicht einen offensichtlichen Fehler zur Folge hat (zumindest im Vergleich zu einer Datei, bei der versäumt wurde, sie unter Versionskontrolle zu stellen). Um Ihnen dabei zu helfen, die Eigenschaften an die Stellen zu bringen, wo sie nötig sind, bietet Subversion Ihnen ein paar einfache aber nützliche Funktionen.

Immer wenn Sie eine Datei mit svn add oder svn import unter Versionskontrolle nehmen, versucht Subversion, Sie zu unterstützen, indem es einige übliche Datei-Eigenschaften automatisch setzt. Erstens setzt Subversion auf Betriebssystemen, deren Dateisystem ein Ausführbarkeits-Erlaubnis-Bit unterstützt, automatisch die Eigenschaft svn:executable auf neu hinzugefügte oder importierte Dateien, bei denen das Ausführbarkeits-Bit gesetzt ist. (Siehe „Ausführbarkeit von Dateien“ weiter unten in diesem Kapitel für weitere Informationen zu dieser Eigenschaft.)

Zweitens versucht Subversion den MIME-Typen der Datei zu ermitteln. Falls Sie einen Laufzeitparameter mime-types-files konfiguriert haben, versucht Subversion in dieser Datei einen passenden MIME-Typen für die Endung Ihrer Datei zu finden. Wenn es fündig wird, setzt es die Eigenschaft svn:mime-type Ihrer Datei auf den gefundenen MIME-Typen. Falls keine Datei konfiguriert oder kein passender Typ für die Dateiendung gefunden wurde, wendet Subversion eine recht einfache Heuristik an, um festzustellen, ob die Datei nicht-textuellen Inhalt hat. Falls das der Fall ist, wird automatisch die Eigenschaft svn:mime-type dieser Datei auf application/octet-stream gesetzt (der allgemeine „dies ist eine Ansammlung von Bytes“-MIME-Type). Falls Subversion falsch rät, oder falls Sie den Wert der Eigenschaft svn:mime-type präziser setzen möchten – etwa image/png oder application/x-shockwave-flash – können Sie natürlich jederzeit die Eigenschaft entfernen oder bearbeiten. (Mehr zur Verwendung von MIME-Typen durch Subversion in „Datei-Inhalts-Typ“ später in diesem Kapitel.)

Darüber hinaus bietet Subversion über sein Laufzeit-Konfigurationssystem (siehe „Laufzeit-Konfigurationsbereich“) eine flexible Möglichkeit, automatisch Eigenschaften zu setzen, die es Ihnen erlaubt, Abbildungen von Dateinamensmustern auf Eigenschafts-Namen und -Werte vorzunehmen. Auch hier haben diese Abbildungen Auswirkungen auf das Hinzufügen und Importieren und können nicht nur die standardmäßigen Entscheidungen Subversions bezüglich des Mime-Typs außer Kraft setzen, sondern auch zusätzliche Subversion- oder spezielle Eigenschaften setzen. Beispielsweise könnten Sie eine Abbildung definieren, die bestimmt, dass jedes Mal wenn eine JPEG-Datei hinzugefügt wird – Dateien, deren Namen auf das Muster *.jpg passen – Subversion automatisch die Eigenschaft svn:mime-type für diese Dateien auf image/jpeg setzt. Oder vielleicht sollen alle Dateien mit dem Muster *.cpp svn:eol-style auf native und svn:keywords auf Id gesetzt bekommen. Die Unterstützung automatischer Eigenschaften ist vielleicht das praktischste Werkzeug bezüglich Eigenschaften in der Werkzeugkiste von Subversion. Siehe „Config“ für Details zur Konfiguration dieser Unterstützung.

Subversion reiht sich unter den zahlreichen Anwendungen ein, die die Multipurpose Internet Mail Extensions (MIME) Inhaltstypen erkennen und verwenden. Außer ein universeller Lagerort für den Inhaltstypen einer Datei zu sein, bestimmt der Wert der Datei-Eigenschaft svn:mime-type einige Verhaltensweisen von Subversion selbst.

Beispielsweise ist einer der Vorteile, die Subversion typischerweise mitbringt, die kontextabhängige, zeilenbasierte Zusammenführung der vom Server während einer Aktualisierung empfangenen Änderungen mit Ihrer Arbeitsdatei. Allerdings gibt es bei Dateien, deren Inhalt nicht aus Text besteht, oft nicht das Konzept einer „Zeile“. Damit versucht Subversion während einer Aktualisierung keine kontextabhängige Zusammenführungen für versionierte Dateien, deren Eigenschaft svn:mime-type auf einen nicht-textuellen MIME-Typen gesetzt ist (normalerweise etwas, das nicht mit text/ beginnt, obwohl es Ausnahmen gibt). Stattdessen wird jedes Mal, wenn eine von Ihnen lokal veränderte binäre Datei in der Arbeitskopie aktualisiert werden soll, diese Datei nicht angerührt, sondern Subversion erzeugt zwei neue Dateien. Eine davon hat die Dateiendung .oldrev und beinhaltet die BASE-Revision der Datei. Die andere Datei hat eine .newrev-Endung und beinhaltet die aktualisierte Revision der Datei. Dieses Verhalten dient tatsächlich dem Schutz des Benutzers vor fehlgeschlagenen Versuchen, kontextabhängige Zusammenführungen mit Dateien zu machen, die einfach nicht kontextabhängig zusammengeführt werden können.

Warnung

Falls die Eigenschaft svn:mime-type auf einen Wert gesetzt wird, der nicht auf textuellen Dateiinhalt schließen lässt, kann das einige unerwartete Auswirkungen in Verbindung mit anderen Eigenschaften haben. Da beispielsweise Zeilenenden (und somit die Umwandlung von Zeilenenden) bei nicht-textuellen Dateien keinen Sinn ergeben, verhindert Subversion, dass Sie die Eigenschaft svn:eol-style für diese Dateien setzen. Das ist offensichtlich, wenn es bei einer einzelnen Datei versucht wird – svn propset gibt einen Fehler aus und beendet sich. Allerdings könnte es nicht so klar sein, wenn Sie die Eigenschaften rekursiv setzen möchten, wobei Subversion stillschweigend diejenigen Dateien übergeht, die es für eine bestimmte Eigenschaft als untauglich erachtet.

Beginnend mit Subversion 1.5 können Benutzer einen neuen Laufzeitparameter mime-types-file konfigurieren, um den Ort der Datei zum Abbilden neu hinzugefügter oder importierter Dateien auf den MIME-Typen zu bestimmen.

Falls die Eigenschaft svn:mime-type gesetzt ist, verwendet auch das Subversion-Apache-Modul dessen Wert, um den HTTP-Header Content-type: zu füllen, wenn es auf GET-Anfragen antwortet. Das gibt Ihrem Web-Browser einen wichtigen Hinweis darauf, wie die Datei darzustellen ist, wenn Sie sie benutzen, um den Inhalt Ihres Subversion-Projektarchivs zu durchstöbern.

Unter vielen Betriebssystemen hängt die Fähigkeit, eine Datei als Befehl ausführen zu können, vom Vorhandensein eines Ausführbarkeits-Erlaubnis-Bits ab. Normalerweise ist dieses Bit standardmäßig nicht aktiviert und muss vom Benutzer für jede Datei gesetzt werden, die es benötigt. Es wäre aber ein Riesenstress, sich exakt diejenigen Dateien in einer frisch ausgecheckten Arbeitskopie merken zu müssen, die das Ausführbarkeits-Bit gesetzt haben sollen und es dann zu aktivieren. Deshalb stellt Subversion die Eigenschaft svn:executable zur Verfügung, um die Dateien zu markieren, die das Ausführbarkeits-Bit benötigen. Beim Auschecken berücksichtigt Subversion diesen Wunsch wenn es die Arbeitskopie mit solchen Dateien füllt.

Diese Eigenschaft hat keine Auswirkungen auf Dateisystemen, die das Konzept eines Ausführbarkeits-Bits nicht kennen, so wie FAT32 und NTFS ^[11]. Darüber hinaus erzwingt Subversion beim Setzen dieser Eigenschaft den Wert *, obwohl sie keine definierten Werte besitzt. Zum Schluss sei gesagt, dass diese Eigenschaft nur auf Dateien gültig ist, nicht auf Verzeichnissen.

Falls der Inhalt einer versionierten Datei durch deren Eigenschaft svn:mime-type nicht anders gekennzeichnet ist, nimmt Subversion an, es handele sich um menschenlesbare Daten. Im Allgemeinen verwendet Subversion dieses Wissen lediglich, um festzustellen, ob Unterschiede kontextabhängig dargestellt werden können. Ansonsten sind für Subversion Bytes einfach Bytes.

Das bedeutet, dass Subversion von sich aus überhaupt nicht auf die von Ihren Dateien benutzte Sorte von Zeilenende-Markierungen (EOL-Marker) achtet. Leider haben unterschiedliche Betriebssysteme auch unterschiedliche Konventionen hinsichtlich der Zeichenfolgen, die das Ende einer Textzeile in einer Datei repräsentieren. Beispielsweise ist die gebräuchliche Zeilenende-Kennzeichnung, die von Software auf der Windows-Plattform benutzt wird, ein Paar aus ASCII-Kontrollzeichen – ein Wagenrücklauf (CR) gefolgt von einem Zeilenvorschub (LF). Unix Software verwendet jedoch nur das Zeichen LF, um Zeilenenden zu kennzeichnen.

Nicht alle der zahlreichen Werkzeuge unter diesen Betriebssystemen können mit Dateien umgehen, die Zeilenenden in einem Format haben, das vom eigenen Zeilenende-Stil des Betriebssystems abweicht, auf dem sie laufen. Unix-Programme behandeln das in Windows-Dateien vorkommende Zeichen CR typischerweise als ein gewöhnliches Zeichen (welches normalerweise als ^M wiedergegeben wird), und Windows-Programme fügen alle Zeilen einer Unix-Datei zu einer großen Zeile zusammen, da keine Wagenrücklauf-Zeilenvorschub-Kombination (oder CRLF) zur Zeilenendemarkierung gefunden wurde.

Diese Empfindlichkeit gegenüber fremden EOL-Markern kann für Menschen frustrierend sein, die eine Datei über Betriebssystemgrenzen hinweg gemeinsam benutzen. Schauen wir uns beispielsweise eine Quelltextdatei an, die Entwickler sowohl unter Windows als auch unter Unix bearbeiten. Falls die Entwickler stets Werkzeuge verwenden, die den Zeilenende-Stil der Datei bewahren, werden keine Probleme auftreten.

In der Praxis jedoch scheitern viele verbreitete Werkzeuge daran, eine Datei mit fremden EOL-Markern richtig zu lesen, oder sie wandeln die Zeilenenden der Datei beim Schreiben in den eigenen Stil. Falls ersteres für einen Entwickler zutrifft, muss ein externes Umwandlungsprogramm verwendet werden (etwa dos2unix oder sein Gegenstück unix2dos), um die Datei für die Bearbeitung vorzubereiten. Im letzteren Fall ist keine spezielle Vorbereitung notwendig. In beiden Fällen jedoch ist das Ergebnis eine Datei, die sich buchstäblich in jeder Zeile vom Original unterscheidet. Vor der Übertragung seiner Änderungen hat der Benutzer zwei Möglichkeiten: Entweder kann er mit einem Umwandlungsprogramm den Zeilenende-Stil wiederherstellen, den die Datei vor den Änderungen aufwies, oder er überträgt die Datei einfach – neue EOL-Marker und alles andere inklusive.

Unter dem Strich bedeuten derartige Szenarien Zeitverschwendung und unnötige Änderungen an übertragenen Dateien. Zeitverschwendung ist schlimm genug. Falls jedoch durch die Übertragungen alle Zeilen einer Datei geändert werden, erschwert das die Aufgabe, herauszufinden, welche Zeilen sich auf eine nicht-triviale Art und Weise geändert haben. Wo wurde der Fehler tatsächlich behoben? In welcher Zeile hat sich ein Syntaxfehler eingeschlichen?

Die Lösung für dieses Problem ist die Eigenschaft svn:eol-style. Wird sie auf einen gültigen Wert gesetzt, benutzt Subversion sie, um festzustellen, welche besondere Behandlung für diese Datei notwendig ist, um das ständige durch unterschiedliche Betriebssysteme bedingte Hin und Her der Zeilenende-Stile bei jeder Übertragung zu vermeiden. Die gültigen Werte sind:

Im Projektarchiv von Subversion ist eine Sperre ein Metadatum, das einem Benutzer das exklusive Recht zum Ändern einer Datei erteilt. Dieser Benutzer wird Sperreigner genannt. Jede Sperre hat auch eine eindeutige Identifikation, üblicherweise eine lange Zeichenkette, Sperrmarke genannt. Das Projektarchiv verwaltet Sperren, letztendlich übernimmt es das Anlegen, das Durchsetzten und das Entfernen derselben. Falls irgendeine Übertragungstransaktion versucht, eine gesperrte Datei zu ändern oder zu löschen (oder eins der Elternverzeichnisse der Datei zu löschen), verlangt das Projektarchiv zweierlei Informationen: dass der die Übertragung ausführende Client sich als der Eigner der Sperrmarke authentisiert, und dass die Sperrmarke im Zuge der Übertragung vorgelegt wird, um zu beweisen, dass der Client weiß, welche Sperre verwendet wird.

Um das Anlegen einer Sperre zu demonstrieren, gehen wir zurück zu unserem Beispiel mit mehreren Grafikdesignern, die an derselben binären Bilddatei arbeiten. Harry hat sich entschieden, ein JPEG-Bild zu ändern. Um andere Leute daran zu hindern, Änderungen an der Datei zu übertragen, während er sie ändert (und auch, um ihnen mitzuteilen, dass er gerade Änderungen vornimmt), sperrt er die Datei im Projektarchiv mit dem Befehl svn lock.

$ svn lock banana.jpg -m "Editing file for tomorrow's release."
»banana.jpg« gesperrt durch »harry«.
$

Das vorangegangene Beispiel zeigt eine Menge neuer Dinge. Beachten Sie zunächst, dass Harry die Option --message (-m) an svn lock übergeben hat. Ähnlich wie svn commit kann der Befehl svn lock Kommentare annehmen, entweder über --message (-m) oder --file (-F), um den Grund für die Dateisperre zu beschreiben. Im Gegensatz zu svn commit verlangt svn lock jedoch nicht nach einer Nachricht, indem es Ihren bevorzugten Texteditor aufruft. Sperrkommentare sind zwar optional, aber zur Unterstützung der Kommunikation empfohlen.

Zum Zweiten war der Sperrversuch erfolgreich. Das bedeutet, dass die Datei noch nicht gesperrt war, und Harry die letzte Version der Datei hatte. Falls Harrys Arbeitskopie der Datei nicht mehr aktuell gewesen wäre, hätte das Projektarchiv die Anfrage abgelehnt und Harry dazu gezwungen, svn update aufzurufen und den Sperrbefehl dann erneut zu versuchen. Der Sperrbefehl wäre ebenso fehlgeschlagen, falls die Datei bereits von jemand anderem gesperrt worden wäre.

Wie Sie sehen können, gibt der Befehl svn lock eine Bestätigung bei einer erfolgreichen Sperrung aus. An dieser Stelle wird die Tatsache, dass die Datei gesperrt ist, durch die Ausgabe der berichtenden Unterbefehle svn status und svn info offensichtlich.

$ svn status
     K banana.jpg

$ svn info banana.jpg
Pfad: banana.jpg
Name: banana.jpg
URL: http://svn.example.com/repos/project/banana.jpg
UUID des Projektarchivs: edb2f264-5ef2-0310-a47a-87b0ce17a8ec
Revision: 2198
Knotentyp: Datei
Plan: normal
Letzter Autor: frank
Letzte geänderte Rev: 1950
Letztes Änderungsdatum: 2006-03-15 12:43:04 -0600 (Wed, 15 Mar 2006)
Text zuletzt geändert: 2006-06-08 19:23:07 -0500 (Thu, 08 Jun 2006)
Eigenschaften zuletzt geändert: 2006-06-08 19:23:07 -0500 (Thu, 08 Jun 2006)
Prüfsumme: 3b110d3b10638f5d1f4fe0f436a5a2a5
Sperrmarke: opaquelocktoken:0c0f600b-88f9-0310-9e48-355b44d4a58e
Sperreigner: harry
Sperre erzeugt: 2006-06-14 17:20:31 -0500 (Wed, 14 Jun 2006)
Sperrkommentar (1 Zeile):
Editing file for tomorrow's release.

$

Aus der Tatsache, dass der Befehl svn info, der nicht das Projektarchiv kontaktiert, wenn er mit einem Pfad der Arbeitskopie aufgerufen wird, die Sperrmarke anzeigen kann, enthüllt eine wichtige Information über diese Marken: sie werden in der Arbeitskopie zwischengespeichert. Das Vorhandensein der Sperrmarke ist kritisch. Sie erteilt der Arbeitskopie die Autorisierung, die Sperrmarke später zu verwenden. Darüber hinaus zeigt der Befehl svn status ein K neben der Datei an (kurz für locKed, gesperrt), was darauf hinweist, dass die Sperrmarke vorhanden ist.

Da Harry nun banana.jpg gesperrt hat, kann Sally diese Datei weder ändern noch löschen:

$ svn delete banana.jpg
D         banana.jpg
$ svn commit -m "Delete useless file."
Lösche         banana.jpg
svn: Übertragen schlug fehl (Details folgen):
svn: Der Server hat einen unerwarteten Rückgabewert (423 Locked) in Antwort auf die "
 Anfrage DELETE für »/repos/project/!svn/wrk/64bad3a9-96f9-0310-818a-df4224ddc35d/\
banana.jpg« zurückgeliefert"
$

Harry aber kann seine Änderungen an der Datei übertragen, nachdem er das Gelb der Banane verbessert hat. Das funktioniert, da er sich als der Sperreigner authentisiert hat, und weil seine Arbeitskopie die korrekte Sperrmarke beinhaltet:

$ svn status
M    K banana.jpg
$ svn commit -m "Make banana more yellow"
Sende          banana.jpg
Übertrage Daten .
Revision 2201 übertragen.
$ svn status
$

Beachten Sie, dass nach Abschluss der Übertragung svn status anzeigt, dass die Sperrmarke nicht mehr in der Arbeitskopie vorhanden ist. Das ist das Standardverhalten von svn commit – es durchsucht die Arbeitskopie (oder die Liste von Zielobjekten, falls angegeben) nach lokalen Änderungen und sendet im Zuge der Übertragungstransaktion alle Sperrmarken denen es begegnet an den Server. Nach dem erfolgreichem Abschluss der Übertragung, sind alle erwähnten Sperren aufgehoben – sogar für Dateien, die nicht übertragen worden sind. Das soll Benutzer davon abschrecken, beim Sperren oder beim langen Halten von Sperren schludrig zu sein. Falls Harry wahllos 30 Dateien in einem Verzeichnis namens images sperrt, weil er sich nicht sicher ist, welche Dateien er ändern muss, dann aber nur vier dieser Dateien ändert, werden trotzdem alle 30 Sperren freigegeben, wenn er svn commit images aufruft.

Dieses Verhalten der automatischen Sperrfreigabe kann mit der Option --no-unlock von svn commit unterbunden werden. Diese Option wird am besten dann verwendet, wenn Sie Änderungen übertragen möchten, aber trotzdem weitere Änderungen planen und die Sperren deshalb beibehalten werden sollen. Sie können das auch zum Standardverhalten machen, indem Sie die Laufzeitoption no-unlock setzen (siehe „Laufzeit-Konfigurationsbereich“).

Natürlich wird durch das Sperren einer Datei keine Verpflichtung eingegangen, eine Änderung übertragen zu müssen. Die Sperre kann jederzeit mit einem einfachen svn unlock freigegeben werden:

$ svn unlock banana.c
»banana.c« freigegeben.

Falls eine Übertragung aufgrund der Sperre von jemand anderen fehlschlägt, ist es ziemlich einfach, Informationen darüber zu erhalten. Die einfachste Möglichkeit ist, svn status --show-updates aufzurufen:

$ svn status -u
M              23   bar.c
M    O         32   raisin.jpg
       *       72   foo.h
Status bezogen auf Revision:     105
$

In diesem Beispiel kann Sally nicht nur sehen, dass ihre Kopie von foo.h nicht mehr aktuell ist, sondern auch, dass eine der zwei geänderten Dateien, die sie übertragen wollte, im Projektarchiv gesperrt ist. Das Symbol O steht für „Other“, was bedeutet, dass eine Sperre auf der Datei liegt, die von jemand anderen angelegt wurde. Wenn sie eine Übertragung versuchte, würde die Sperre auf raisin.jpg das verhindern. Sally fragt sich jetzt nur noch, wer die Sperre wann und warum angelegt hat. Auch hierzu liefert svn info die Antwort:

$ svn info http://svn.example.com/repos/project/raisin.jpg
Pfad: raisin.jpg
Name: raisin.jpg
URL: http://svn.example.com/repos/project/raisin.jpg
UID des Projektarchivs: edb2f264-5ef2-0310-a47a-87b0ce17a8ec
Revision: 105
Knotentyp: Datei
Letzter Autor: sally
Letzte geänderte Rev: 32
Letztes Änderungsdatum: 2006-01-25 12:43:04 -0600 (Sun, 25 Jan 2006)
Sperrmarke: opaquelocktoken:fc2b4dee-98f9-0310-abf3-653ff3226e6b
Sperreigner: harry
Sperre erzeugt: 2006-02-16 13:29:18 -0500 (Thu, 16 Feb 2006)
Sperrkommentar (1 Zeile):
Need to make a quick tweak to this image.
$

Ebenso, wie Sie svn info zum Untersuchen von Objekten in der Arbeitskopie verwenden können, erlaubt es Ihnen, Objekte im Projektarchiv zu untersuchen. Falls das Hauptargument von svn info ein Pfad der Arbeitskopie ist, wird die gesamte zwischengespeicherte Information der Arbeitskopie angezeigt; die Erwähnung irgendeiner Sperre bedeutet, dass die Arbeitskopie eine Sperrmarke hält (falls eine Datei von einem anderen Benutzer oder in einer anderen Arbeitskopie gesperrt ist, zeigt svn info mit einem Pfad der Arbeitskopie keinerlei Informationen über Sperren an). Falls das Hauptargument zu svn info ein URL ist, spiegelt die Information die letzte Version eines Objektes im Projektarchiv wider, und die Erwähnung einer Sperre beschreibt die aktuelle Sperre auf dem Objekt.

In diesem konkreten Beispiel kann Sally sehen, dass Harry die Datei am 16. Februar gesperrt hat, um „eine schnelle Optimierung“ zu machen. Da es nun Juni ist, vermutet sie, dass er wahrscheinlich die Sperre vergessen hat. Sie könnte Harry anrufen, um sich zu beschweren und ihn aufzufordern, die Datei freizugeben. Sollte er nicht erreichbar sein, könnte sie versuchen, selber die Freigabe zu erzwingen oder einen Administrator darum zu bitten.

Eine Sperre im Projektarchiv ist nicht heilig – in der Standardkonfiguration von Subversion können Sperren nicht nur durch die Personen freigegeben werden, die sie angelegt haben, sondern durch jeden. Falls jemand anderes als der ursprüngliche Erzeuger der Sperre diese zerstört, nennen wir das die Freigabe der Sperre erzwingen.

Vom Platz eines Administrators aus ist es einfach, eine Freigabe zu erzwingen. Die Programme svnlook und svnadmin können Sperren direkt aus dem Projektarchiv anzeigen sowie entfernen. (Weitere Informationen zu diesen Werkzeugen unter „Der Werkzeugkasten eines Administrators“.)

$ svnadmin lslocks /var/svn/repos
Pfad: /project2/images/banana.jpg
UUID Marke: opaquelocktoken:c32b4d88-e8fb-2310-abb3-153ff1236923
Eigentümer: frank
Erstellt: 2006-06-15 13:29:18 -0500 (Thu, 15 Jun 2006)
Läuft ab: 
Kommentar (1 Zeile):
Still improving the yellow color.

Pfad: /project/raisin.jpg
UUID Marke: opaquelocktoken:fc2b4dee-98f9-0310-abf3-653ff3226e6b
Eigentümer: harry
Erstellt: 2006-02-16 13:29:18 -0500 (Thu, 16 Feb 2006)
Läuft ab: 
Kommentar (1 Zeile):
Need to make a quick tweak to this image.

$ svnadmin rmlocks /var/svn/repos /project/raisin.jpg
Sperre für »/project/raisin.jpg« entfernt.
$

Die interessantere Option ist, es den Benutzern zu erlauben, gegenseitig über das Netz die Freigabe zu erzwingen. Um das zu machen, muss Sally dem Befehl svn unlock einfach ein --force mitgeben:

$ svn status -u
M              23   bar.c
M    O         32   raisin.jpg
       *       72   foo.h
Status bezogen auf Revision:     105
$ svn unlock raisin.jpg
svn: »raisin.jpg« ist in dieser Arbeitskopie nicht gesperrt.
$ svn info raisin.jpg | grep URL
URL: http://svn.example.com/repos/project/raisin.jpg
$ svn unlock http://svn.example.com/repos/project/raisin.jpg
svn: Sperrfreigabe gescheitert: 403 Forbidden (http://svn.example.com)
$ svn unlock --force http://svn.example.com/repos/project/raisin.jpg
»raisin.jpg« freigegeben.
$

Sallys erster Versuch, die Sperre aufzuheben, schlug fehl, da sie svn unlock direkt in ihrer Arbeitskopie ausführte und keine Sperrmarke vorhanden war. Um die Sperre direkt aus dem Projektarchiv zu entfernen, muss sie svn unlock einen URL übergeben. Ihr erster Versuch, den URL zu entsperren, schlägt fehl, da sie sich nicht als der Sperreigner authentisieren kann (sie hat ja auch nicht die Sperrmarke). Wenn sie jedoch --force übergibt, werden die Authentisierungs- und Autorisierungsanforderungen ignoriert und die entfernte Freigabe wird erzwungen.

Es kann sein, dass das einfache Erzwingen einer Freigabe nicht ausreicht. Im aktuellen Beispiel könnte Sally nicht nur beabsichtigt haben, Harrys längst vergessene Sperre zu beseitigen, sondern die Datei für sich zu sperren. Sie kann das erreichen, indem sie svn unlock mit --force aufruft und direkt anschließend svn lock; hier besteht jedoch eine geringe Wahrscheinlichkeit, dass jemand anderes die Datei zwischen den beiden Befehlen sperren könnte. Einfacher ist es, die Sperre zu stehlen, was bedeutet, die Datei in einem atomaren Schritt freizugeben und wieder zu sperren. Um das zu tun, übergibt Sally die Option --force an svn lock:

$ svn lock raisin.jpg
svn: Sperranforderung gescheitert: 423 Locked (http://svn.example.com)
$ svn lock --force raisin.jpg
»raisin.jpg« gesperrt durch »sally«.
$

Auf jeden Fall wird Harry eine Überraschung erleben, egal, ob die Freigabe erzwungen oder die Sperre gestohlen wurde. Die Arbeitskopie von Harry beinhaltet immer noch die ursprüngliche Sperrmarke, die dazugehörige Sperre gibt es jedoch nicht mehr. Die Sperrmarke wird als erloschen bezeichnet. Die durch die Sperrmarke repräsentierte Sperre wurde entweder durch eine Freigabeerzwingung zerstört (sie befindet sich nicht mehr im Projektarchiv) oder gestohlen (durch eine andere Sperre ersetzt). Egal wie, Harry kann es sehen, wenn er svn status auffordert, Kontakt zum Projektarchiv aufzunehmen:

$ svn status
     K raisin.jpg
$ svn status -u
     B         32   raisin.jpg
$ svn update
  B  raisin.jpg
$ svn status
$

Falls die Freigabe erzwungen wurde, zeigt svn status --show-updates ein B-Symbol (Broken) neben der Datei an. Falls es eine neue Sperre an Stelle der alten gibt, wird ein T-Symbol (gesTohlen) angezeigt. Zu guter Letzt entdeckt svn update irgendwelche erloschenen Sperrmarken und entfernt sie aus der Arbeitskopie.

Wir haben uns angesehen, wie svn lock und svn unlock verwendet werden können, um Sperren anzulegen, freizugeben und deren Freigabe zu erzwingen. Dies erfüllt den Zweck, den Zugriff zum Übergeben von Änderungen an einer Datei zu serialisieren. Aber wie sieht es mit dem größeren Problem aus, Zeitverschwendung zu vermeiden?

Nehmen wir beispielsweise an, dass Harry eine Bilddatei sperrt und mit deren Bearbeitung beginnt. Mittlerweile, weit entfernt, möchte Sally das Gleiche machen. Sie denkt nicht daran, svn status --show-updates aufzurufen, so dass sie nicht mitbekommt, dass Harry die Datei bereits gesperrt hat. Sie verbringt Stunden mit der Bearbeitung der Datei, und beim Versuch, ihre Änderungen zu übergeben, stellt sie fest, dass die Datei entweder gesperrt oder nicht mehr aktuell ist. Wie auch immer – ihre Änderungen lassen sich nicht mit denen Harrys zusammenführen. Eine Person von beiden muss ihre Arbeit wegwerfen, und eine Menge Zeit ist verschwendet worden.

Die Lösung von Subversion für dieses Problem besteht in einem Mechanismus, der Benutzer daran erinnert, dass eine Datei vor dem Ändern gesperrt werden sollte. Es handelt sich um eine besondere Eigenschaft: svn:needs-lock. Wenn diese Eigenschaft einer Datei zugeordnet ist (egal mit welchem Wert), versucht Subversion mit Dateisystem-Zugriffsrechten, die Datei nur lesbar zu machen – natürlich nur dann, wenn der Benutzer die Datei nicht ausdrücklich gesperrt hat. Wenn eine Sperrmarke vorhanden ist (als ein Ergebnis eines Aufrufs von svn lock), wird die Datei schreib- und lesbar. Wird die Sperre freigegeben, wird die Datei wieder nur lesbar.

Die Theorie ist die, dass Sally sofort merkt, dass irgend etwas nicht stimmt, wenn sie die mit dieser Eigenschaft versehene Bilddatei zum Ändern öffnet: Viele Anwendungen benachrichtigen Benutzer sofort, wenn eine nur lesbare Datei zum Ändern geöffnet werden soll, und fast alle verhindern es, dass Änderungen an der Datei gespeichert werden. Das erinnert sie daran, die Datei vor dem Ändern zu sperren, wobei sie die bereits bestehende Sperre entdeckt:

$ /usr/local/bin/gimp raisin.jpg
gimp: error: file is read-only!
$ ls -l raisin.jpg
-r--r--r--   1 sally   sally   215589 Jun  8 19:23 raisin.jpg
$ svn lock raisin.jpg
svn: "Sperranforderung gescheitert: 423 Locked (http://svn.example.com)
$ svn info http://svn.example.com/repos/project/raisin.jpg | grep Lock
Sperrmarke: opaquelocktoken:fc2b4dee-98f9-0310-abf3-653ff3226e6b
Sperreigner: harry
Sperre erzeugt: 2006-06-08 07:29:18 -0500 (Thu, 08 June 2006)
Sperrkommentar (1 Zeile):
Making some tweaks.  Locking for the next two hours.
$

	Tipp
	Es sei Benutzern und Administratoren gleichermaßen empfohlen, die Eigenschaft svn:needs-lock an allen Dateien anzubringen, die nicht kontextabhängig zusammengeführt werden können. Dies ist die wichtigste Technik, um ein gutes Sperrverhalten zu bestärken und vergeudeten Aufwand zu vermeiden.

Beachten Sie, dass diese Eigenschaft ein Kommunikationswerkzeug darstellt, welches unabhängig vom Sperrsystem funktioniert. Mit anderen Worten: Jede Datei kann gesperrt werden, egal, ob diese Eigenschaft vorhanden ist oder nicht. Und andersherum bedeutet das Vorhandensein dieser Eigenschaft nicht, dass das Projektarchiv bei der Übergabe eine Sperre erforderlich macht.

Leider ist dieses System nicht unfehlbar. Es ist möglich, dass die Nur-Lesbar-Erinnerung nicht immer funktioniert, auch wenn eine Datei diese Eigenschaft besitzt. Manchmal benehmen sich Anwendungen daneben und „kapern“ die nur lesbare Datei, indem sie dem Benutzer trotzdem stillschweigend das Ändern und Sichern gestatten. In dieser Situation kann Subversion nicht viel machen – letztendlich gibt es einfach keinen Ersatz für gute zwischenmenschliche Kommunikation. ^[16]

Sie können Änderungslisten mit dem Befehl svn changelist erstellen, bearbeiten und löschen. Genauer gesagt verwenden Sie diesen Befehl, um die Verbindung einer Änderungsliste mit einer Datei der Arbeitskopie herzustellen oder aufzulösen. Eine Änderungsliste wird tatsächlich erstmals dann erstellt, wenn Sie eine Datei mit diesem Änderungslisten-Label versehen; sie wird gelöscht, wenn dieses Label von der letzten damit versehenen Datei entfernt wird. Sehen wir uns einmal einen Anwendungsfall an, der diese Konzepte vorstellt.

Harry beseitigt einige Fehler in der mathematischen Logik der Rechneranwendung. Seine Arbeit veranlasst ihn, einige Dateien zu ändern:

$ svn status
M      integer.c
M      mathops.c
$

Während er die Fehlerbehebung testet, bemerkt Harry, dass seine Änderungen einen tangential in Bezug stehenden Fehler der Logik der Benutzerschnittstelle in button.c ans Tageslicht bringen. Harry entschließt sich, auch diesen Fehler als eine von seinen Mathe-Reparaturen getrennte Übergabe zu beheben. In einer kleinen Arbeitskopie mit nur einer handvoll Dateien und wenigen logischen Änderungen kann Harry wahrscheinlich seine zwei logisch gruppierten Änderungen ohne Problem im Kopf auseinander halten. Heute jedoch wird er, um den Autoren diesen Buchs einen Gefallen zu tun, die Änderungslisten von Subversion verwenden.

Harry erstellt zunächst eine Änderungsliste und stellt sie in Beziehung zu den beiden von ihm bereits geänderten Dateien. Er macht das, indem er diesen Dateien mit dem Befehl svn changelist die selbe, frei wählbare Änderungsliste zuweist:

$ svn changelist math-fixes integer.c mathops.c
Pfad »integer.c« ist nun ein Element der Änderungsliste »math-fixes«.
Pfad »mathops.c« ist nun ein Element der Änderungsliste »math-fixes«.
$ svn status

--- Änderungsliste »math-fixes«:
M      integer.c
M      mathops.c
$

Wie Sie sehen können, spiegelt die Ausgabe von svn status diese neue Gruppierung wider.

Harry legt nun los, das sekundäre Problem der Benutzerschnittstelle zu beheben. Da er weiß, welche Datei er ändern wird, weist er auch diesen Pfad einer Änderungsliste zu. Unglücklicherweise weist Harry diese dritte Datei achtlos derselben Änderungsliste wie den beiden vorigen Dateien zu:

$ svn changelist math-fixes button.c
Pfad »button.c« ist nun ein Element der Änderungsliste
»math-fixes«.
$ svn status

--- Änderungsliste »math-fixes«:
       button.c
M      integer.c
M      mathops.c
$

Zum Glück entdeckt Harry seinen Fehler. An dieser Stelle hat er zwei Optionen. Er kann die Verbindung zur Änderungsliste von button.c lösen und dann einen unterschiedlichen Listennamen zuweisen:

$ svn changelist --remove button.c
Pfad »button.c« ist nicht länger ein Element einer Änderungsliste.
$ svn changelist ui-fix button.c
msgstr "Pfad »button.c« ist nun ein Element der Änderungsliste »ui-fix«.
$

Oder er kann sich das Entfernen sparen und bloß einen neuen Änderungslisten-Namen zuweisen. In diesem Fall wird Subversion Harry warnen, dass button.c von der ersten Änderungsliste entfernt wird:

$ svn changelist ui-fix button.c
svn: warnung: Entferne »button.c« aus Änderungsliste »math-fixes«.
Pfad »button.c« ist nun ein Element der Änderungsliste »ui-fix«.
$ svn status

--- Änderungsliste »ui-fix«:
       button.c

--- Änderungsliste »math-fixes«:
M      integer.c
M      mathops.c
$

Harry hat nun zwei unterschiedliche Änderungslisten in seiner Arbeitskopie, und svn status gruppiert seine Ausgaben nach den Bezeichnungen dieser Änderungslisten. Beachten Sie, dass Harry die Datei button.c zwar noch nicht geändert hat, sie aber trotzdem als interessant in der Ausgabe von svn status erscheint, da eine Verknüpfung mit einer Änderungsliste besteht. Änderungslisten können jederzeit Dateien hinzugefügt oder entzogen werden, egal, ob sie lokale Änderungen beinhalten.

Harry behebt nun das Problem der Benutzerschnittstelle in button.c.

$ svn status

--- Änderungsliste »ui-fix«:
M      button.c

--- Änderungsliste »math-fixes«:
M      integer.c
M      mathops.c
$

Die visuelle Gruppierung, die Harry in der Ausgabe von svn status im vorangegangenenen Abschnitt sieht, ist ganz nett, jedoch nicht so richtig nützlich. Der Befehl status ist nur einer von mehreren, die er vielleicht in seiner Arbeitskopie ausführen möchte. Erfreulicherweise können viele andere Befehle von Subversion auf Änderungslisten arbeiten, wenn die Option --changelist verwendet wird.

Wenn ihnen die Option --changelist mitgegeben wird, beschränken Befehle von Subversion ihren Wirkbereich auf die Dateien, die mit einer bestimmten Änderungsliste verknüpft sind. Falls Harry nun die eigentlichen Änderungen sehen möchte, die er an Dateien in seiner Änderungsliste math-fixes vorgenommen hat, könnte er in der Kommandozeile des Befehls svn diff ausdrücklich nur die Dateien angeben, die diese Änderungsliste ausmachen.

$ svn diff integer.c mathops.c
Index: integer.c
===================================================================
--- integer.c	(revision 1157)
+++ integer.c	(working copy)
…
Index: mathops.c
===================================================================
--- mathops.c	(revision 1157)
+++ mathops.c	(working copy)
…
$

Bei ein paar Dateien funktioniert das einwandfrei, was wäre aber, wenn Harrys Änderung 20 oder 30 Dateien beträfe? Das wäre eine schrecklich lange Liste ausdrücklich aufgeführter Dateinamen. Da Harry nun jedoch Änderungslisten verwendet, kann er das explizite Aufführen der Dateimenge in seiner Änderungsliste von nun an vermeiden und stattdessen nur den Namen der Änderungsliste angeben:

$ svn diff --changelist math-fixes
Index: integer.c
===================================================================
--- integer.c	(revision 1157)
+++ integer.c	(working copy)
…
Index: mathops.c
===================================================================
--- mathops.c	(revision 1157)
+++ mathops.c	(working copy)
…
$

Und wenn es an der Zeit ist, zu übertragen, kann Harry wieder die Option --changelist verwenden, um die Übertragung auf die Dateien einer bestimmten Änderungsliste zu beschränken. Er könnte seine Fehlerbehebung an der Benutzerschnittstelle etwa so übertragen:

$ svn ci -m "Fix a UI bug found while working on math logic." \
      --changelist ui-fix
Sende          button.c
Übertrage Daten .
Revision 1158 übertragen.
$

Der Befehl svn commit verfügt über eine zweite Option in Zusammenhang mit Änderungslisten: --keep-changelists. Normalerweise werden Verknüpfungen zu Änderungslisten nach der Übertragung von Dateien aufgelöst. Wenn jedoch --keep-changelists angegeben wird, bewahrt Subversion die Verknüpfung der übertragenen (und nun unveränderten) Dateien zur Änderungsliste. In allen Fällen berührt die Übertragung von Dateien einer Änderungsliste alle anderen Änderungslisten nicht.

$ svn status

--- Änderungsliste »math-fixes«:
M      integer.c
M      mathops.c
$

Anmerkung

Die Option --changelist wirkt lediglich als ein Filter für die Objekte eines Subversion-Befehls und fügt keine neuen Objekte hinzu. Beispielsweise ist bei einem Übertragungsbefehl, der als svn commit /path/to/dir gegeben wird, das Objekt das Verzeichnis /path/to/dir und seine Kinder (unendlich tief). Wenn Sie diesem Befehl dann die Angabe einer Änderungsliste hinzufügen, werden nur die Dateien in und unterhalb von /path/to/dir als zu übertragene Objekte betrachtet, die mit dieser Änderungsliste verknüpft sind – die Übertragung wird keine Dateien von anderen Stellen (etwa /path/to/another-dir) umfassen, egal, ob sie mit der Änderungsliste verknüpft sind, auch wenn sie zur selben Arbeitskopie gehören wie die Objekte des Befehls.

Auch der Befehl svn changelist versteht die Option --changelist. Er ermöglicht Ihnen das schnelle Umbenennen oder Entfernen einer Änderungsliste:

$ svn changelist math-bugs --changelist math-fixes --depth infinity .
svn: warnung: Entferne »integer.c« aus Änderungsliste »math-fixes«.
Pfad »integer.c« ist nun ein Element der Änderungsliste »math-bugs«.
svn: warnung: Entferne »mathops.c« aus Änderungsliste »math-fixes«.
Pfad »mathops.c« ist nun ein Element der Änderungsliste »math-bugs«.
$ svn changelist --remove --changelist math-bugs --depth infinity .
Pfad »integer.c« ist nicht länger ein Element einer Änderungsliste
Pfad »mathops.c« ist nicht länger ein Element einer Änderungsliste
$

Schließlich können sie die Option --changelist mehrfach für einen Befehl auf einer einzelnen Kommandozeile angeben. Das beschränkt den auszuführenden Befehl auf Dateien, die in irgendeiner der angegebenen Änderungslisten zu finden sind.

Die Änderungslisten von Subversion sind ein praktisches Werkzeug, um Dateien in Arbeitskopien zu gruppieren; allerdings besitzen sie ein paar Einschränkungen. Änderungslisten sind Artefakte einer bestimmten Arbeitskopie, was bedeutet, dass Änderungslisten-Zuweisungen nicht an das Projektarchiv weitergegeben und auch anderweitig nicht gemeinsam von anderen Benutzern verwendet werden können. Änderungslisten lassen sich nur Dateien zuordnen – momentan unterstützt Subversion nicht die Verwendung von Änderungslisten für Verzeichnisse. Schließlich können Sie einer gegebenen Datei der Arbeitskopie höchstens eine Änderungsliste zuweisen. Hier passen die Analogien der Blog-Posts-Kategorien oder der Foto-Tags nicht mehr – sollte es notwendig sein, eine Datei mehreren Änderungslisten zuzuweisen, haben Sie Pech.

Den größten Teil seiner Zeit verbringt der Subversion-Client mit der Verwaltung von Arbeitskopien. Wenn er jedoch Informationen von einem entfernten Projektarchiv benötigt, stellt er eine Anfrage über das Netz, und der Server erwiedert mit einer passenden Antwort. Die Details des Netzwerkprotokolls sind dem Benutzer verborgen – der Client versucht, auf einen URL zuzugreifen, und abhänging vom URL-Schema wird ein bestimmtes Protokoll verwendet, um mit dem Server Verbindung aufzunehmen (siehe Anmerkung Projektarchiv-URLs).

	Tipp
	Rufen Sie svn --version auf, um zu sehen, welche URL-Schemas und Protokolle versteht.

Wenn der Server-Prozess eine Anfrage eines Clients erhält, verlangt er häufig, dass der Client sich identifiziert. Er sendet eine Authentisierungsaufforderung an den Client und der Client antwortet, indem er Zugangsdaten zurückschickt. Sobald die Authentifizierung abgeschlossen ist, antwortet der Server mit den ursprünglich vom Client angefragten Informationen. Beachten Sie, dass dieses System sich von solchen wie CVS unterscheidet, bei denen der Client von sich aus dem Server Zugangsdaten anbietet („sich anmeldet“), bevor überhaupt eine Anfrage erfolgt. In Subversion werden die Zugangsdaten vom Server „eingezogen“, indem der Client zum passenden Zeitpunkt aufgefordert wird, und nicht indem der Client sie „abliefert“. Das macht gewisse Operationen eleganter. Wenn ein Server beispielsweise so konfiguriert ist, dass jedem auf der Welt erlaubt ist, ein Projektarchiv zu lesen, wird der Server niemals eine Authentisierungsaufforderung ausgeben, wenn ein Client svn checkout versucht.

Falls die einzelnen Netzwerkanfragen des Clients zur Erstellung einer neuen Revision im Projektarchiv führen (z.B. svn commit), verwendet Subversion den mit diesen Anfragen verknüpften authentifizierten Benutzernamen als Autor der Revision. Das bedeutet, dass der Name des authentifizierten Benutzers als Wert der Eigenschaft svn:author der neuen Revision zugewiesen wird (siehe „Subversion-Eigenschaften“). Falls der Client nicht authentifiziert wurde (d.h., falls der Server niemals eine Authentisierungsaufforderung ausgegeben hat), bleibt die Revisionseigenschaft svn:author leer.

Viele Server sind so konfiguriert, dass sie vor jeder Anfrage eine Authentisierung benötigen. Für Benutzer wäre es sehr lästig, wenn sie jedes Mal das Passwort eingeben müssten. Glücklicherweise hat der Subversion-Client hierfür eine Abhilfe: ein eingebautes System zum Zwischenspeichern der Zugangsdaten auf Platte. Standardmäßig legt der Kommandozeilen-Client die Zugangsdaten immer im privaten Laufzeitkonfigurationsbereich des Benutzers ab (~/.subversion/auth/ auf Unix-ähnlichen Systemen oder %APPDATA%/Subversion/auth/ unter Windows; siehe „Laufzeit-Konfigurationsbereich“ für Details zum Laufzeitkonfigurationssystem), wenn er erfolgreich auf die Authentisierungsanfrage des Servers antwortet. Die gültigen Zugangsdaten werden auf Platte zwischengespeichert und mit einer Kombination aus dem Rechnernamen des Servers, dem Port und dem Anmeldebereich referenziert.

Wenn der Client eine Authentisierungsaufforderung empfängt, schaut er zunächst nach den passenden Zugangsdaten im Cache des Benutzers auf Platte. Falls passend erscheinende Zugangsdaten nicht verfügbar sind oder die zwischengespeicherten Zugangsdaten letzlich nicht für eine Authentisierung ausreichen sollten, wird der Client standardmäßig den Benutzer zur Eingabe der notwendigen Informationen auffordern.

Der sicherheitsbewussten Leser wird an dieser Stelle sofort einen Grund für Besorgnis erkennen. „Passwörter auf der Platte speichern? Das ist schrecklich! So etwas sollte man nie machen!“

Die Entwickler von Subversion erkennen die Zulässigkeit dieser Besorgnis, und so arbeitet Subversion mit den durch das Betriebssystem und die Umgebung bereitgestellten Mechanismen, um das Risiko der Kompromittierung dieser Daten zu minimieren. Hier ist eine Aufschlüsselung, was das für die Benutzer der verbreitetsten Betriebssysteme bedeutet:

Natürlich sind keine dieser Mechanismen perfekt für den echt Paranoiden. Für die Leute, die Bequemlichkeit für die größte Sicherheit opfern möchten, bietet Subversion verschiedene Möglichkeiten, das System der Zwischenspeicherung ganz abzuschalten.

Übergeben Sie die Option --no-auth-cache, um die Zwischenspeicherung für einen einzelnen Befehl abzuschalten:

$ svn commit -F log_msg.txt --no-auth-cache
Anmeldebereich: <svn://host.example.com:3690> example realm
Benutzername:  joe
Passwort für »joe«:

Hinzufügen     newfile
Übertrage Daten .
Revision 2324 übertragen.

# Das Passwort war nicht Zwischengespeichert, also werden wir beim zweiten Mal gefragt

$ svn delete newfile
$ svn commit -F new_msg.txt
Anmeldebereich: <svn://host.example.com:3690> example realm
Benutzername:  joe
…

Wenn Sie aber die Zwischenspeicherung der Zugangsdaten dauerhaft unterbinden wollen, können Sie die Datei config in Ihrem Laufzeitkonfigurationsbereich bearbeiten und die Option store-auth-creds auf no setzten. Das verhindert die Speicherung der Zugangsdaten für alle Ihre Interaktionen mit Subversion auf dem betroffenen Rechner. Das kann auch auf alle Benutzer ausgeweitet werden, indem der systemweite Konfigurationsbereich (beschrieben in „Aufbau des Konfigurationsbereichs“) bearbeitet wird.

[auth]
store-auth-creds = no

Manchmal möchten Benutzer bestimmte Zugangsdaten aus dem Zwischenspeicher entfernen. Hierzu müssen Sie in den auth/-Bereich gehen und die entsprechende Zwischenspeicherdatei manuell löschen. Die Zugangsdaten werden in individuellen Dateien zwischengespeichert; falls Sie in jede Datei hineinsehen, werden Sie Schlüssel und Werte entdecken. Der Schlüssel svn:realmstring beschreibt den bestimmten Anmeldebereich, zu dem die Datei gehört:

$ ls ~/.subversion/auth/svn.simple/
5671adf2865e267db74f09ba6f872c28
3893ed123b39500bca8a0b382839198e
5c3c22968347b390f349ff340196ed39

$ cat ~/.subversion/auth/svn.simple/5671adf2865e267db74f09ba6f872c28

K 8
username
V 3
joe
K 8
password
V 4
blah
K 15
svn:realmstring
V 45
<https://svn.domain.com:443> Joe's repository
END

Sobald Sie die passende Datei gefunden haben, können Sie sie einfach löschen.

Ein letztes Wort zum Authentifizierungsverhalten von svn, im Besonderen bezüglich der Optionen --username und --password. Viele Unterbefehle des Clients akzeptieren diese Optionen, jedoch ist es wichtig, zu verstehen, dass durch die Verwendung dieser Optionen nicht automatisch Zugangsdaten an den Server gesendet werden. Wie bereits erörtert wurde, werden die Zugangsdaten vom Server „eingezogen“, falls er es für notwendig hält; der Client kann sie nicht nach belieben „abliefern“. Wurde ein Benutzername und/oder ein Passwort als Optionen mitgegeben, werden sie dem Server nur auf Verlangen vorgelegt. Üblicherweise werden diese Optionen verwendet, um sich als ein anderer Benutzer zu authentisieren als derjenige, den Subversion standardmäßig gewählt hätte (etwa Ihr Anmeldename), oder falls Sie die interaktive Abfrage vermeiden möchten (etwa beim Aufruf von svn aus einem Skript).

	Anmerkung
	Ein verbreiteter Fehler ist die Fehlkonfigurierung eines Servers, so dass er nie eine Aufforderung zur Authentisierung ausgibt. Falls Benutzer dann die Optionen --username und --password an den Client übergeben, wundern sie sich, dass sie nie verwendet werden, d.h., es sieht so aus, dass neue Revisionen anonym übergeben worden sind!

An dieser Stelle sei abschließend zusammengefasst, wie sich ein Subversion-Client bei Erhalt einer Aufforderung zur Authentisierung verhält.

Falls sich der Client durch irgendeine dieser Methoden erfolgreich authentisiert, versucht er, die Zugangsdaten auf der Platte zwischenzuspeichern (sofern der Benutzer dieses Verhalten nicht, wie oben beschrieben, unterbunden hat).

Es ist sehr einfach, einen Zweig zu erzeugen – Sie erstellen mit dem Befehl svn copy eine Kopie des Projektes im Projektarchiv. Subversion kann nicht nur Dateien, sondern auch komplette Verzeichnisse kopieren. In diesem Fall möchten Sie eine Kopie des Verzeichnisses /calc/trunk machen. Wo soll die neue Kopie angelegt werden? Wo Sie wünschen – es ist eine Frage der Projektkonventionen. Sagen wir mal, dass Ihr Team die Konvention vereinbart hat, Zweige im Bereich /calc/branches des Projektarchivs anzulegen, und Sie Ihren Zweig my-calc-branch nennen möchten. Sie werden ein neues Verzeichnis /calc/branches/my-calc-branch anlegen, das als Kopie von /calc/trunk beginnt.

Sie haben vielleicht schon gesehen, wie mit svn copy in einer Arbeitskopie eine Datei auf eine andere kopiert wird. Es kann allerdings auch verwendet werden, um eine „entfernte“ Kopie innerhalb des Projektarchivs durchzuführen. Kopieren Sie einfach einen URL auf einen anderen:

$ svn copy http://svn.example.com/repos/calc/trunk \
           http://svn.example.com/repos/calc/branches/my-calc-branch \
      -m "Privaten Zweig von /calc/trunk angelegt."

Revision 341 übertragen.

Dieser Befehl bewirkt eine fast sofortige Übergabe im Projektarchiv, wobei in Revision 341 ein neues Verzeichnis erzeugt wird. Das neue Verzeichnis ist eine Kopie von /calc/trunk. Dies wird in Abbildung 4.3, „Projektarchiv mit neuer Kopie“ gezeigt. ^[20] Obwohl es auch möglich ist, einen Zweig zu erzeugen, indem svn copy verwendet wird, um ein Verzeichnis innerhalb der Arbeitskopie zu duplizieren, wird dieses Vorgehen nicht empfohlen. Es kann in der Tat sehr langsam sein! Das client-seitige Kopieren eines Verzeichnisses besitzt einen linearen Zeitaufwand, da wirklich jede Datei und jedes Verzeichnis auf der lokalen Platte dupliziert werden muss. Das Kopieren eines Verzeichnisses auf dem Server jedoch besitzt einen konstanten Zeitaufwand und ist die Art und Weise, auf die die meisten Leute Zweige erstellen.

Abbildung 4.3. Projektarchiv mit neuer Kopie

Da Sie nun einen Zweig des Projektes erzeugt haben, können Sie eine neue Arbeitskopie auschecken, um ihn zu benutzen:

$ svn checkout http://svn.example.com/repos/calc/branches/my-calc-branch
A  my-calc-branch/Makefile
A  my-calc-branch/integer.c
A  my-calc-branch/button.c
Ausgecheckt, Revision 341.

An dieser Arbeitskopie ist nichts besonders; sie spiegelt bloß ein anderes Verzeichnis im Projektarchiv wieder. Wenn Sie Änderungen übergeben, wird sie Sally jedoch nicht sehen, wenn sie aktualisiert, da sie eine Arbeitskopie von /calc/trunk hat. (Stellen Sie sicher, dass Sie „Zweige durchlaufen“ weiter unten in diesem Kapitel lesen: Der Befehl svn switch ist eine Alternative für die Bereitstellung einer Arbeitskopie eines Zweiges.)

Tun wir mal so, als ob eine Woche ins Land geht und die folgenden Übergaben stattfinden:

Nun finden zwei unabhängige Entwicklungslinien (siehe Abbildung 4.4, „Die Verzweigung der Geschichte einer Datei“) auf integer.c statt.

Abbildung 4.4. Die Verzweigung der Geschichte einer Datei

Es wird interessant, wenn Sie die Geschichte der Änderungen an Ihrer Kopie von integer.c betrachten:

$ pwd
/home/user/my-calc-branch

$ svn log -v integer.c
------------------------------------------------------------------------
r343 | user | 2002-11-07 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines
Geänderte Pfade:
   M /calc/branches/my-calc-branch/integer.c

* integer.c:  Wazjub gefrozzelt.

------------------------------------------------------------------------
r341 | user | 2002-11-03 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines
Geänderte Pfade:
   A /calc/branches/my-calc-branch (from /calc/trunk:340)

Privaten Zweig von /calc/trunk angelegt.

------------------------------------------------------------------------
r303 | sally | 2002-10-29 21:14:35 -0600 (Tue, 29 Oct 2002) | 2 lines
Geänderte Pfade:
   M /calc/trunk/integer.c

* integer.c:  Einen Docstring geändert.

------------------------------------------------------------------------
r98 | sally | 2002-02-22 15:35:29 -0600 (Fri, 22 Feb 2002) | 2 lines
Geänderte Pfade:
   A /calc/trunk/integer.c

* integer.c:  Diese Datei dem Projekt hinzugefügt.

------------------------------------------------------------------------

Beachten Sie, dass Subversion die Geschichte von integer.c auf Ihrem Zweig über die gesamte Zeit zurück verfolgt, und dabei sogar über den Punkt hinweg geht, an dem es kopiert wurde. Es zeigt die Erzeugung des Zweigs als ein Ereignis in der Geschichte, da integer.c implizit kopiert wurde, als alles andere in /calc/trunk/ kopiert wurde. Sehen Sie nun, was passiert, wenn Sally den gleichen Befehl auf Ihre Arbeitskopie der Datei anwendet:

$ pwd
/home/sally/calc

$ svn log -v integer.c
------------------------------------------------------------------------
r344 | sally | 2002-11-07 15:27:56 -0600 (Thu, 07 Nov 2002) | 2 lines
Changed paths:
   M /calc/trunk/integer.c

* integer.c:  fix a bunch of spelling errors.

------------------------------------------------------------------------
r303 | sally | 2002-10-29 21:14:35 -0600 (Tue, 29 Oct 2002) | 2 lines
Changed paths:
   M /calc/trunk/integer.c

* integer.c:  changed a docstring.

------------------------------------------------------------------------
r98 | sally | 2002-02-22 15:35:29 -0600 (Fri, 22 Feb 2002) | 2 lines
Changed paths:
   A /calc/trunk/integer.c

* integer.c:  adding this file to the project.

------------------------------------------------------------------------

Sally sieht ihre eigene Änderung in Revision 344, aber nicht die Änderung, die Sie in Revision 343 gemacht haben. Was Subversion angeht, hatten diese beiden Übergaben Auswirkungen auf unterschiedliche Dateien an unterschiedlichen Projektarchiv-Orten. Dennoch zeigt Subversion doch, dass die beiden Dateien einen Teil der Geschichte gemeinsam haben. Bevor die Kopie des Zweiges in Revision 341 gemacht wurde, waren die Dateien dieselbe Datei. Deshalb sehen sowohl Sie als auch Sally die Änderungen, die in den Revisionen 303 und 98 gemacht wurden.

Sie sollten sich zwei Lektionen aus diesem Abschnitt merken. Erstens besitzt Subversion kein internes Konzept für einen Zweig – es weiß lediglich, wie Kopien angelegt werden. Wenn Sie ein Verzeichnis kopieren, ist das entstehende Verzeichnis bloß ein „Zweig“, weil Sie ihm diese Bedeutung geben. Sie mögen über das Verzeichnis anders denken oder es anders behandeln, doch für Subversion ist es einfach ein gewöhnliches Verzeichnis, das nebenbei mit einigen zusätzlichen historischen Informationen ausgestattet ist.

Zweitens bestehen die Zweige von Subversion, bedingt durch den Kopiermechanismus, als normale Dateisystemverzeichnisse im Projektarchiv. Das ist ein Unterschied zu anderen Versionskontrollsystemen, bei denen Zweige typischerweise definiert werden, indem auf einer eigenen Ebene den Dateisammlungen „Etiketten“ hinzugefügt werden. Der Ort Ihres Zweig-Verzeichnisses spielt für Subversion keine Rolle. Die meisten Teams folgen der Konvention, alle Zweige in einem Verzeichnis namens /branches abzulegen, jedoch steht es Ihnen frei, eine Vorgehensweise nach Ihren Wünschen zu erfinden.

Bevor wir weitermachen, sollten wir Sie warnen, dass Sie auf den kommenden Seiten viele Erörterungen zum Thema „Änderungen“ erwarten. Viele mit Versionskontrollsystemen erfahrene Leute benutzen die Begriffe „Änderung“ und „Änderungsmenge“ (Changeset) austauschbar, so dass wir klären sollten, was Subversion unter einer Änderungsmenge versteht.

Jeder scheint eine etwas unterschiedliche Definition für den Begriff Änderungsmenge zu haben oder zumindest eine unterschiedliche Erwartung darüber, was es für ein Versionskontrollsystem bedeutet, so etwas zu besitzen. Für unsere Zwecke reicht es aus, zu sagen, dass eine Änderungsmenge lediglich eine Sammlung von Änderungen mit einem eindeutigen Namen ist. Die Änderungen können aus der Bearbeitung an Textdateien, Modifizierungen an der Baumstruktur oder Justierungen an Metadaten bestehen. In einfachen Worten ist eine Änderungsmenge einfach ein Patch mit einem Namen, auf den Sie sich beziehen können.

In Subversion bezeichnet eine globale Revisionsnummer N einen Baum im Projektarchiv: Sie beschreibt das Aussehen des Projektarchivs nach der N-ten Übergabe. Sie ist auch der Name einer impliziten Änderungsmenge: Wenn Sie den Baum N mit dem Baum N−1 vergleichen, können Sie genau den Patch ableiten, der übergeben wurde. Daher ist es einfach, sich Revision N nicht nur als Baum sondern auch als Änderungsmenge vorzustellen. Falls Sie ein Fehlerverwaltungssystem verwenden, können Sie die Revisionsnummern benutzen, um auf bestimmte Patches zu verweisen, die Fehler beheben – zum Beispiel: „Dieser Fehler wurde durch r9238 behoben“. Dann kann jemand svn log -r 9238 aufrufen, um den Protokolleintrag zu genau der Änderungsmenge zu lesen, die den Fehler behoben hat, und sich mit svn diff -c 9238 den eigentlichen Patch ansehen. Und auch (wie Sie bald sehen werden) der Subversion Befehl svn merge kann Revisionsnummern verwenden. Sie können bestimmte Änderungsmengen von einem Zweig mit einem anderen zusammenführen, indem sie in den Argumenten zum entsprechenden Kommando benannt werden: Die Übergabe von -c 9238 an svn merge würde das Änderungsmenge r9238 mit Ihrer Arbeitskopie zusammenführen.

Machen wir mit unserem Beispiel weiter und nehmen an, dass eine Woche vergangen ist seitdem Sie begonnen haben, auf Ihrem privaten Zweig zu arbeiten. Ihre Arbeit ist noch nicht beendet, jedoch wissen Sie, dass gleichzeitig andere Leute in Ihrem Team weiterhin wichtige Änderungen im /trunk des Projektes gemacht haben. Es ist in Ihrem Interesse, diese Änderungen in Ihren Zweig zu übernehmen, um sicherzustellen, dass sie sich gut mit Ihren Änderungen vertragen. Dies ist tatsächlich eine der besten Vorgehensweisen: Ihren Zweig regelmäßig mit der Hauptentwicklungslinie zu synchronisieren hilft, „überraschende“ Konflikte zu vermeiden, wenn es an der Zeit ist, Ihre Änderungen zurück auf den Stamm zu bringen.

Subversion kennt die Geschichte Ihres Zweigs und weiß, wann Sie ihn vom Stamm abgezweigt haben. Um die letzten, aktuellsten Änderungen vom Stamm auf Ihren Zweig zu bringen, sollten Sie zunächst sicherstellen, dass die Arbeitskopie des Zweigs „sauber“ ist – dass sie keine lokalen Änderungen hat, die durch svn status angezeigt werden. Dann rufen Sie einfach die folgenden Befehle auf:

$ pwd
/home/user/my-calc-branch

$ svn merge http://svn.example.com/repos/calc/trunk
--- Zusammenführen von r345 bis r356 in ».«:
U    button.c
U    integer.c

Diese einfache Syntax – svn merge URL – fordert Subversion auf, alle neuen Änderungen von dem URL mit dem aktuellen Arbeitsverzeichnis (welches typischerweise das Wurzelverzeichnis Ihrer Arbeitskopie ist) zusammenzuführen. Nach dem Ausführen des vorangegangenen Beispiels enthält Ihre Arbeitskopie nun neue lokale Änderungen, die Nachbildungen all der Änderungen auf dem Stamm seit der Erstellung Ihres Zweiges sind:

$ svn status
 M     .
M      button.c
M      integer.c

Zu diesem Zeitpunkt ist es weise, sich die Änderungen mithilfe von svn diff sorgfältig anzusehen, und anschließend die Software von Ihrem Zweig zu bauen und zu testen. Beachten Sie, dass auch das aktuelle Arbeitsverzeichnis („.“) verändert wurde; svn diff zeigt an, dass seine Eigenschaft svn:mergeinfo entweder angelegt oder modifiziert wurde. Das ist ein wichtiges Metadatum in Zusammenhang mit Zusammenführungen, das Sie nicht anfassen sollten, da es von künftigen svn merge-Befehlen benötigt wird. (Wir werden später in diesem Kapitel mehr über diese Metadaten erfahren.)

Nach der Übernahme kann es möglich sein, dass Sie noch einige Konflikte auflösen müssen (wie bei svn update) oder möglicherweise noch einige kleinere Bearbeitungen durchzuführen haben, damit alles wieder funktioniert. (Denken Sie daran, dass die Abwesenheit syntaktischer Konflikte nicht bedeutet, dass keine semantischen Konflikte vorhanden sind!) Falls ernsthafte Probleme auftauchen, können Sie jederzeit die lokalen Änderungen mit svn revert . -R wieder rückgängig machen und eine lange „was geht hier eigentlich vor“-Unterredung mit Ihren Mitarbeitern führen. Falls jedoch alles gut aussieht, können Sie die Änderungen an das Projektarchiv übergeben:

$ svn commit -m "Die letzten Änderungen von trunk mit my-calc-branch zusammengeführt."
Sende          .
Sende          button.c
Sende          integer.c
Übertrage Daten ..
Revision 357 übertragen.

An dieser Stelle ist Ihr Zweig „synchron“ mit dem Stamm, und Sie können sich ruhig zurücklehnen in der Gewissheit, dass Sie sich nicht zu weit von der Arbeit aller anderen entfernen, während Sie isoliert weiterarbeiten.

$ cd my-calc-branch
$ svn diff -r 341:HEAD http://svn.example.com/repos/calc/trunk > patchfile
$ patch -p0  < patchfile
Patching file integer.c using Plan A...
Hunk #1 succeeded at 147.
Hunk #2 succeeded at 164.
Hunk #3 succeeded at 241.
Hunk #4 succeeded at 249.
done

Nehmen wir an, noch eine Woche sei ins Land gegangen. Sie haben weitere Änderungen an Ihren Zweig übergeben, und Ihre Kollegen haben damit weitergemacht, den Stamm zu verbessern. Nun möchten Sie mal wieder die letzten Änderungen vom Stamm mit Ihrem Zweig abgleichen, damit Sie wieder synchron sind. Starten Sie einfach noch einmal den svn merge-Befehl!

$ svn merge http://svn.example.com/repos/calc/trunk
--- Zusammenführen von r357 bis r380 in ».«:
U    integer.c
U    Makefile
A    README

Subversion weiß, welche Änderungen Sie bereits mit Ihrem Zweig abgeglichen haben, so dass es sorgfältig nur die Änderungen berücksichtigt, die Sie noch nicht haben. Einmal mehr müssen Sie bauen, testen und die lokalen Änderungen an Ihren Zweig mit svn commit übergeben.

Was passiert jedoch, wenn Sie schließlich Ihre Arbeit abgeschlossen haben? Ihre neue Funktion ist fertig, und Sie sind bereit, die Änderungen von Ihrem Zweig zurück auf den Stamm zu überführen (so dass Ihr Team die Früchte Ihrer Arbeit genießen kann). Die Vorgehensweise ist einfach. Zunächst synchronisieren Sie Ihren Zweig noch einmal mit dem Stamm, wie Sie es bisher gemacht haben:

$ svn merge http://svn.example.com/repos/calc/trunk
--- Zusammenführen von r381 bis r385 in ».«:
U    button.c
U    README

$ # bauen, testen, ...

$ svn commit -m "Letzte Zusammenführung der Änderungen von trunk changes in my-calc-branch."
Sende          .
Sende          button.c
Sende          README
Übertrage Daten ..
Revision 390 übertragen.

Nun verwenden Sie svn merge, um Ihre Änderungen vom Zweig zurück auf den Stamm zu überführen. Sie benötigen eine aktuelle Arbeitskopie von /trunk. Sie bekommen sie entweder durch svn checkout, indem Sie von irgendwo auf Ihrer Platte eine alte Arbeitskopie vom Stamm hervorholen, oder den Befehl svn switch (siehe „Zweige durchlaufen“) verwenden. Wie auch immer Sie Ihre Arbeitskopie bereitstellen, denken Sie daran, dass Sie die Überführung in einer Arbeitskopie durchführen, die keine lokalen Änderungen beinhaltet und jüngst aktualisiert wurde (d.h., keine Mischung aus lokalen Revisionen ist). Falls Ihre Arbeitskopie nicht „sauber“ in diesem Sinn ist, könnte es Ihnen einige unnötige konfliktbezogene Kopfschmerzen bereiten, und svn merge wird wahrscheinlich einen Fehler ausgeben.

Sobald Sie eine saubere Arbeitskopie des Stamms haben, sind Sie bereit, Ihren Zweig damit zusammenzuführen:

$ pwd
/home/user/calc-trunk

$ svn update  # (stellen Sie sicher, dass die Arbeitskopie aktuell ist)
Revision 390.

$ svn merge --reintegrate http://svn.example.com/repos/calc/branches/my-calc-branch
-- Zusammenführen der Unterschiede zwischen Projektarchiv-URLs in ».«:
U    button.c
U    integer.c
U    Makefile
 U   .

$ # bauen, testen, überprüfen, ...

$ svn commit -m "Merge my-calc-branch back into trunk!"
Sende          .
Sende          button.c
Sende          integer.c
Sende          Makefile
Übertrage Daten ..
Revision 391 übertragen.

Gratulation! Ihr Zweig ist nun zurück in die Hauptentwicklungslinie überführt worden. Beachten Sie, dass dieses Mal die Option --reintegrate verwendet wurde. Diese Option ist kritisch, wenn Änderungen von einem Zweig in die ursprüngliche Entwicklungslinie reintegriert werden – vergessen Sie sie nicht! Sie wird benötigt, da diese Art der „Rücküberführung“ etwas anderes ist, als was Sie bisher gemacht haben. Vorher haben wir svn merge aufgefordert, die „nächste Änderungsmenge“ von einer Entwicklungslinie (dem Stamm) zu holen und sie mit einer anderen (Ihrem Zweig) abzugleichen. Das ist recht überschaubar, und Subversion weiß jedesmal, wo es wieder ansetzen soll. Bei unseren vorangehenden Beispielen können Sie sehen, dass es erst die Intervalle 345:356 vom Stamm auf den Zweig überführte; später fuhr es mit dem nächsten verfügbaren aufeinanderfolgenden Intervall 356:380 fort. Wenn Sie die letzte Synchronisierung machen, wird es das Intervall 380:385 zusammenführen.

Wenn Sie jedoch den Zweig auf den Stamm zurückführen, sehen die dem zugrundeliegenden Berechnungen ganz anders aus. Ihr Zweig ist nun ein Mischmasch aus abgeglichenen Änderungen vom Stamm und privaten Änderungen auf dem Zweig, so dass es kein einfaches, aufeinanderfolgendes Intervall mit Revisionen zum Herüberkopieren gibt. Indem Sie die Option --reintegrate angeben, fordern Sie Subversion auf, sorgfältig nur die Änderungen von Ihrem Zweig zu replizieren. (Und tatsächlich macht es das so, dass es die letzte Version auf dem Stamm mit der letzten Version auf dem Zweig vergleicht: Der Unterschied macht genau die Änderung auf dem Zweig aus!)

Nachdem nun Ihr privater Zweig mit dem Stamm zusammengeführt wurde, können Sie ihn aus dem Projektarchiv löschen:

$ svn delete http://svn.example.com/repos/calc/branches/my-calc-branch \
      -m "Remove my-calc-branch."
Revision 392 übertragen.

Aber halt! Ist die Geschichte des Zweigs nicht wertvoll? Was, wenn jemand sich eines Tages die Evolution Ihrer Funktion ansehen möchte und hierfür auf die Änderungen des Zweiges schauen möchte? Keine Sorge! Denken Sie daran, dass, obwohl Ihr Zweig nicht mehr im Verzeichnis /branches sichtbar ist, seine Existenz gleichwohl ein unveränderbarer Teil der Geschichte des Projektarchivs ist. Ein einfacher Befehl svn log auf dem /branches URL wird die gesamte Geschichte des Zweiges anzeigen. Ihr Zweig kann eines Tages sogar wiederbelebt werden, sollten Sie dieses wünschen (siehe „Zurückholen gelöschter Objekte“).

Sobald in Subversion 1.5 eine Zusammenführung mit --reintegrate vom Zweig auf den Stamm durchgeführt wurde, kann der Zweig nicht mehr für weitere Arbeiten verwendet werden. Er kann weder Änderungen vom Stamm korrekt absorbieren, noch kann er ordentlich auf den Stamm zurückintegriert werden. Aus diesem Grund sollten Sie ihn zerstören und erneut aus dem Stamm erzeugen, wenn Sie weiter auf dem Zweig arbeiten wollen:

$ svn delete http://svn.example.com/repos/calc/branches/my-calc-branch \
      -m "my-calc-branch löschen."
Revision 392 übertragen.

$ svn copy http://svn.example.com/repos/calc/trunk \
           http://svn.example.com/repos/calc/branches/new-branch
      -m "Einen neuen Zweig von trunk anlegen."
Revision 393 übertragen.

$ cd my-calc-branch

$ svn switch http://svn.example.com/repos/calc/branches/new-branch
Aktualisiert zu Revision 393.

Der letzte Befehl des vorangegangenen Beispiels – svn switch – ist eine Art, ein bestehendes Arbeitsverzeichnis auf ein unterschiedliches Projektarchiv-Verzeichnis zu aktualisieren. Wir werden das genauer in „Zweige durchlaufen“ besprechen.

Der grundsätzliche Mechanismus, den Subversion verwendet, um Änderungsmengen zu verfolgen – d.h. welche Änderungen auf welchen Zweig übertragen worden sind – besteht aus dem Festhalten von Daten in Eigenschaften. Daten über das Zusammenführen werden speziell in der Eigenschaft svn:mergeinfo vermerkt, die an Dateien und Verzeichnissen hängt. (Falls Sie mit Subversion-Eigenschaften nicht vertraut sind, ist es nun an der Zeit, „Eigenschaften“ zu überfliegen.)

Sie können sich die Eigenschaft ansehen, wie jede andere auch:

$ cd my-calc-branch
$ svn propget svn:mergeinfo .
/trunk:341-390

Es wird nicht empfohlen, dass Sie selbst den Wert dieser Eigenschaft ändern, es sei denn, Sie wissen wirklich, was Sie tun. Diese Eigenschaft wird automatisch von Subversion gepflegt, sobald Sie den Befehl svn merge ausführen. Ihr Wert gibt Aufschluss darüber, welche Änderungen (von einem gegebenen Pfad) mit dem in Frage kommenden Verzeichnis abgeglichen wurden. In diesem Fall ist der Pfad /trunk, und das Verzeichnis, das die bestimmten Änderungen erhalten hat, ist /branches/my-calc-branch.

Es gibt auch einen Unterbefehl, svn mergeinfo, der hilfreich dabei ist, nicht nur die Änderungsmengen anzuzeigen, die ein Verzeichnis absorbiert hat, sondern auch, welche Änderungsmengen für einen Abgleich noch in Frage kommen. Das ergibt eine Art Vorschau der nächsten Änderungsmengen, die svn merge auf Ihren Zweig abgleichen wird.

$ cd my-calc-branch

# Welche Änderungen wurden bereits vom Stamm auf den Zweig abgeglichen?
$ svn mergeinfo http://svn.example.com/repos/calc/trunk
r341
r342
r343
…
r388
r389
r390

# Welche Änderungen kommen für einen Abgleich vom Stamm auf den Zweig noch in Frage?
$ svn mergeinfo http://svn.example.com/repos/calc/trunk --show-revs eligible
r391
r392
r393
r394
r395

Der Befehl svn mergeinfo erwartet einen „Quell“-URL (woher die Änderungen kommen würden) und einen optionalen „Ziel“-URL (wohin die Änderungen abgeglichen würden). Falls kein Ziel-URL angegeben ist, wird angenommen, dass das aktuelle Arbeitsverzeichnis das Ziel ist. Weil wir im vorangegangenen Beispiel unser Arbeitsverzeichnis vom Zweig abfragen, geht der Befehl davon aus, dass wir daran interessiert sind, Änderungen für /branches/mybranch vom angegebenen Stamm-URL zu erhalten.

Eine andere Methode, eine genauere Vorschau auf einen Abgleich zu bekommen, ist die Verwendung der Option --dry-run:

$ svn merge http://svn.example.com/repos/calc/trunk --dry-run
U    integer.c

$ svn status
#  es wird nichts ausgegeben, die Arbeitskopie ist unverändert

Die Option --dry-run macht tatsächlich überhaupt keine lokalen Änderungen an der Arbeitskopie. Sie zeigt nur Status-Codes, die ausgegeben würden, wenn ein echter Abgleich stattfände. Sie ist nützlich, um eine Vorschau für einen möglichen Abgleich auf „hoher Ebene“ zu erhalten, falls svn diff zu detailliert wäre.

Tipp

Nach dem Durchführen eines Abgleichs, aber vor der Übergabe des Ergebnisses, können Sie svn diff --depth=empty /pfad/zum/abgleichs/ziel verwenden, um nur die Änderungen am unmittelbaren Ziel des Abgleichs zu sehen. Falls das Ziel ein Verzeichnis war, werden nur Unterschiede von Eigenschaften angezeigt. Das ist eine praktische Methode, um sich die Änderungen an der Eigenschaft svn:mergeinfo anzusehen, die dort durch den Abgleich vermerkt wurden, und die Sie daran erinnern, was Sie eben abgeglichen haben.

Natürlich ist die beste Methode, eine Vorschau eines Abgleichs zu erhalten, ihn zu machen! Denken Sie daran, dass der Aufruf von svn merge an sich nichts Riskantes ist (es sei denn, sie haben lokale Änderungen an Ihrer Arbeitskopie gemacht – aber wir haben bereits betont, dass Sie in eine derartige Umgebung nicht abgleichen sollten). Falls Ihnen das Ergebnis des Abgleichs nicht gefallen sollte, rufen Sie einfach svn revert . -R auf, um die Änderungen an Ihrer Arbeitskopie rückgängig zu machen, und versuchen Sie den Befehl erneut mit unterschiedlichen Optionen. Der Abgleich ist solange nicht endgültig, bis Sie mit svn commit das Ergebnis übergeben.

Tipp

Während es vollkommen in Ordnung ist, durch wiederholte Aufrufe von svn merge und svn revert mit Abgleichen zu experimentieren, könnte es allerdings sein, dass Sie über einige lästige (aber leicht zu umgehende) Fallstricke stolpern. Wenn zum Beispiel durch den Abgleich eine neue Datei hinzugefügt wird (d.h., sie wird zum Hinzufügen markiert), so wird svn revert sie nicht wirklich entfernen; es entfernt lediglich die Markierung zum Hinzufügen. Was übrig bleibt, ist eine unversionierte Datei. Wenn Sie dann den Abgleich erneut versuchen, könnten Sie einen Konflikt bekommen, weil die unversionierte Datei „im Weg steht“. Die Lösung? Nach dem Rückgängigmachen sollten Sie die Arbeitskopie aufräumen und unversionierte Dateien und Verzeichnisse entfernen. Die Ausgabe von svn status sollte so sauber wie möglich sein und idealerweise gar nichts anzeigen.

Sehr häufig wird svn merge verwendet, um eine Änderung rückgängig zu machen, die bereits an das Projektarchiv übergeben worden war. Nehmen wir einmal an, Sie arbeiten fröhlich in einer Arbeitskopie von /calc/trunk und entdecken, dass die damalige Änderung an integer.c in Revision 303 völlig falsch war. Sie hätte nie übergeben werden sollen. Sie können svn merge verwenden, um die Änderung in Ihrer Arbeitskopie „zurückzunehmen“, und dann die lokale Änderung an das Projektarchiv übergeben. Alles, was Sie hierfür tun müssen, ist, eine umgekehrte Differenz anzugeben. (Sie machen das durch die Angabe von --revision 303:302 oder durch das äquivalente --change -303.)

$ svn merge -c -303 http://svn.example.com/repos/calc/trunk
--- Reverse-merging r303 into 'integer.c':
-- Rückwärtiges Zusammenführen von r303 in »integer.c«:
U    integer.c

$ svn status
 M     .
M      integer.c

$ svn diff
…
# überprüfen, ob die Änderung entfernt wurde
…

$ svn commit -m "Änderung aus in r303 rückgängig machen."
Sende          integer.c
Übertrage Daten .
Revision 350 übertragen.

Wie wir früher bereits erwähnten, kann man eine Projektarchiv-Version als eine bestimmte Änderungsmenge betrachten. Bei Verwendung der Option -r wird svn merge aufgefordert, eine Änderungsmenge oder ein ganzes Intervall von Änderungsmengen auf Ihre Arbeitskopie anzuwenden. In unserem Fall, bei dem wir eine Änderung zurücknehmen, fordern wir svn merge auf, die Änderungsmenge #303 rückwärts auf unsere Arbeitskopie anzuwenden.

Merken Sie sich, dass ein solches Rückgängigmachen wie jeder andere svn merge-Vorgang ist, so dass Sie svn status und svn diff benutzen sollten, um sicherzustellen, dass Ihre Arbeit in dem Zustand ist, den Sie haben möchten, und verwenden Sie anschließend svn commit, um die endgültige Version in das Projektarchiv zu bringen. Nach der Übergabe wird sich diese bestimmte Änderungsmenge nicht mehr in der HEAD-Revision wiederfinden.

Nun denken Sie vielleicht: Gut, aber das hat doch nicht wirklich die Übergabe rückgängig gemacht, oder? Die Änderung besteht immer noch in Revision 303. Falls jemand eine Version des Projektes calc zwischen den Revisionen 303 und 349 auscheckt, wird doch trotzdem die fehlerhafte Änderung sichtbar, oder nicht?

Ja, das stimmt. Wenn wir davon sprechen, eine Änderung zu „entfernen“, sprechen wir eigentlich darüber, sie aus der HEAD-Revision zu entfernen. Die ursprüngliche Änderung besteht immer noch in der Geschichte des Projektarchivs. Für die meisten Situationen ist das ausreichend. Die meisten Leute sind sowieso nur am HEAD eines Projektes interessiert. Es gibt jedoch Spezialfälle, in denen Sie wirklich alle Beweise der Übergabe vernichten möchten. (Vielleicht hat jemand ein vertrauliches Dokument in das Projektarchiv übergeben.) Das ist leider nicht so einfach, da Subversion absichtlich so konstruiert wurde, dass es niemals Informationen verliert. Revisionen sind unveränderliche Bäume, die aufeinander aufbauen. Die Beseitigung einer Revision aus der Geschichte würde einen Dominoeffekt auslösen, Chaos in allen nachfolgenden Revisionen anrichten und möglicherweise alle Arbeitskopien ungültig machen. ^[21]

Das Tolle an Versionskontrollsystemen ist, dass Informationen nie verlorengehen. Selbst wenn Sie eine Datei oder ein Verzeichnis löschen, ist es zwar nicht mehr in der HEAD-Revision vorhanden, jedoch noch in früheren Revisionen. Eine der häufigsten Fragen neuer Benutzer ist: „Wie bekomme ich meine alte Datei oder mein altes Verzeichnis zurück?“

Der erste Schritt ist es, genau zu definieren welches Objekt Sie zurückholen möchten. Hier ist eine nützliche Metapher: Sie können sich vorstellen, dass jedes Objekt im Projektarchiv in einem zweidimensionalen Koordinatensystem befindet. Die erste Koordinate ist ein bestimmter Revisionsbaum und die zweite Koordinate ist ein Pfad innerhalb dieses Baumes. So kann jede Version Ihrer Datei oder Ihres Verzeichnisses durch ein bestimmtes Koordinatenpaar definiert werden. (Erinnern Sie sich an die Syntax einer „Peg-Revision“ – foo.c@224 – die in „Peg- und operative Revisionen“ erwähnt wurde.)

Zunächst sollten Sie svn log benutzen, um das exakte Koordinatenpaar zu ermitteln, das Sie zurückholen wollen. Eine gute Strategie ist es, svn log --verbose in einem Verzeichnis aufzurufen, in dem das gelöschte Objekt einmal enthalten war. Die Option --verbose (-v) gibt eine Liste aller geänderten Objekte in jeder Revision aus; Sie müssen nur noch die Revision finden, in der Sie die Datei oder das Verzeichnis gelöscht haben. Sie können das visuell tun oder ein Werkzeug zur Untersuchung der Protokollausgaben einsetzen (mit grep oder vielleicht durch eine inkrementelle Suche in einem Editor).

$ cd parent-dir
$ svn log -v
…
------------------------------------------------------------------------
r808 | joe | 2003-12-26 14:29:40 -0600 (Fri, 26 Dec 2003) | 3 lines
Geänderte Pfade:
   D /calc/trunk/real.c
   M /calc/trunk/integer.c

Schnelle Funktionen zur Fourier-Transformation zu integer.c hinzugefügt.
real.c gelöscht, da Code jetzt in double.c.
…

In diesem Beispiel nehmen wir an, dass Sie nach der gelöschten Datei real.c suchen. Beim Durchsehen der Protokolle des Elternverzeichnisses haben Sie entdeckt, dass diese Datei in Revision 808 gelöscht wurde. Daher war die letzte Revision in der die Datei noch vorhanden war die unmittelbare Vorgänger-Revision. Die Schlussfolgerung: Sie möchten den Pfad /calc/trunk/real.c aus Revision 807 zurückholen.

Das war der schwierige Teil – die Nachforschung. Nun, da Sie wissen, was Sie wiederherstellen wollen, haben Sie die Wahl zwischen zwei verschiedenen Methoden.

Die eine Option ist, svn merge zu verwenden, um Revision 808 „rückwärts“ anzuwenden. (Wir haben bereits in „Änderungen rückgängig machen“ besprochen, wie Änderungen rückgängig gemacht werden.) Das hätte den Effekt, real.c als lokale Änderung erneut hinzuzufügen. Die Datei würde zum Hinzufügen ins Projektarchiv markiert, und nach der Übergabe wäre die Datei wieder in HEAD vorhanden.

In diesem besonderen Beispiel ist das aber wahrscheinlich nicht die beste Strategie. Die Rückwärts-Anwendung von Revision 808 würde nicht nur real.c zum Hinzufügen markieren, sondern, wie aus den Protokollmeldungen hervorgeht, dass ebenso bestimmte Änderungen an integer.c zurücknehmen, was Sie aber nicht wollen. Sie können sicherlich Revision 808 rückwärts anwenden und dann mit svn revert die lokalen Änderungen an integer.c zurücknehmen; allerdings ist diese Technik nicht sehr effektiv. Was wäre, wenn 90 Dateien in Revision 808 geändert worden wären?

Eine zweite, zielorientiertere, Strategie ist es, den Befehl svn merge überhaupt nicht zu verwenden, sondern stattdessen svn copy. Kopieren Sie einfach das exakte „Koordinatenpaar“ aus Revision und Pfad vom Projektarchiv in Ihre Arbeitskopie:

$ svn copy http://svn.example.com/repos/calc/trunk/real.c@807 ./real.c

$ svn status
A  +   real.c

$ svn commit -m "real.c aus revision 807 wiederhergestellt, /calc/trunk/real.c."
Hinzufügen     real.c
Übertrage Daten .
Revision 1390 übertragen.

Das Plus-Zeichen in der Statusausgabe zeigt an, dass das Objekt nicht bloß zu Hinzufügen vorgemerkt ist, sondern zum Hinzufügen „mit Geschichte“. Subversion merkt sich, woher es kopiert wurde. Künftig wird beim Anwenden von svn log auf diese Datei die gesamte Geschichte, über das Zurückholen hinweg, inklusive der Geschichte vor Revision 807 durchlaufen. In anderen Worten, dieses neue real.c ist nicht wirklich neu; es ist ein direkter Nachfahre der ursprünglichen, gelöschten Datei. Dies ist normalerweise eine gute und nützliche Sache. Falls Sie jedoch die Datei ohne geschichtliche Verbindung zur alten Datei zurückholen wollen, funktioniert diese Technik ebensogut:

$ svn cat http://svn.example.com/repos/calc/trunk/real.c@807 > ./real.c

$ svn add real.c
A         real.c

$ svn commit -m "real.c aus Revision 807 wiederhergestellt."
Hinzufügen     real.c
Übertrage Daten .
Revision 1390 übertragen.

Obwohl unser Beispiel zeigt, wie eine Datei zurückgeholt wird, sollten sie beachten, dass dieselben Techniken auch beim Wiederherstellen von gelöschten Verzeichnissen funktionieren. Beachten Sie auch, dass die Wiederherstellung nicht unbedingt in Ihrer Arbeitskopie passieren muss – sie kann auch vollständig im Projektarchiv ausgeführt werden:

$ svn copy http://svn.example.com/repos/calc/trunk/real.c@807 \
           http://svn.example.com/repos/calc/trunk/ \
      -m "real.c aus Revision 807 wiederhergestellt."
Revision 1390 übertragen.

$ svn update
A    real.c
Aktualisiert zu Revision 1390.

Genauso oft wie der Begriff „Änderungsmenge“ wird die Wendung die Rosinen herauspicken in Versionskontrollsystemen verwendet. Das bezieht sich darauf, eine bestimmte Änderungsmenge von einem Zweig auszuwählen und sie auf einen anderen anzuwenden. Die Rosinen herauszupicken kann sich auch darauf beziehen, eine bestimmte Menge von (nicht notwendigerweise angrenzenden) Änderungsmengen von einem auf einen anderen Zweig zu duplizieren. Dies steht im Gegensatz zu den üblicheren Zusammenführungs-Szenarien, bei denen der „nächste“ zusammenhängende Bereich von Revisionen automatisch dupliziert wird.

Warum sollte jemand nur eine einzelne Änderung wollen? Das kommt häufiger vor, als Sie denken. Gehen wir beispielsweise einmal zurück in die Vergangenheit und stellen uns vor, dass Sie Ihren Zweig noch nicht wieder mit dem Stamm zusammengeführt hätten. In der Kaffeeküche bekommen Sie mit, dass Sally eine interessante Änderung an integer.c auf dem Stamm gemacht hat. Als Sie sich die Geschichte der Übergaben auf dem Stamm ansehen, entdecken Sie, dass sie in Revision 355 einen kritischen Fehler beseitigt hat, der direkte Auswirkungen auf die Funktion hat, an der Sie gerade arbeiten. Es kann sein, dass Sie noch nicht bereit sind, alle Änderungen vom Stamm zu übernehmen, jedoch benötigen Sie diese bestimmte Fehlerbehebung, um mit Ihrer Arbeit weitermachen zu können.

$ svn diff -c 355 http://svn.example.com/repos/calc/trunk

Index: integer.c
===================================================================
--- integer.c   (revision 354)
+++ integer.c   (revision 355)
@@ -147,7 +147,7 @@
     case 6:  sprintf(info->operating_system, "HPFS (OS/2 or NT)"); break;
     case 7:  sprintf(info->operating_system, "Macintosh"); break;
     case 8:  sprintf(info->operating_system, "Z-System"); break;
-    case 9:  sprintf(info->operating_system, "CP/MM");
+    case 9:  sprintf(info->operating_system, "CP/M"); break;
     case 10:  sprintf(info->operating_system, "TOPS-20"); break;
     case 11:  sprintf(info->operating_system, "NTFS (Windows NT)"); break;
     case 12:  sprintf(info->operating_system, "QDOS"); break;

Ebenso wie Sie svn diff im vorigen Beispiel benutzt haben, um sich Revision 355 anzusehen, können Sie die gleiche Option an svn merge übergeben:

$ svn merge -c 355 http://svn.example.com/repos/calc/trunk
U    integer.c

$ svn status
M      integer.c

Sie können nun Ihre üblichen Tests durchführen, bevor Sie diese Änderung an den Zweig übergeben. Nach der Übergabe merkt sich Subversion, dass r355 mit dem Zweig zusammengeführt wurde, so dass künftige „magische“ Zusammenführungen, die Ihren Zweig mit dem Stamm synchronisieren, r355 überspringen. (Das Zusammenführen derselben Änderung auf denselben Zweig führt fast immer zu einem Konflikt!)

$ cd my-calc-branch

$ svn propget svn:mergeinfo .
/trunk:341-349,355

# Beachten Sie, dass r355 nicht als Zusammenführungs-Kandidat aufgeführt wird
# da es bereits zusammengeführt wurde.
$ svn mergeinfo http://svn.example.com/repos/calc/trunk --show-revs eligible
r350
r351
r352
r353
r354
r356
r357
r358
r359
r360

$ svn merge http://svn.example.com/repos/calc/trunk
--- Zusammenführen von r350 bis r354 in ».«:
 U   .
U    integer.c
U    Makefile
--- Zusammenführen von r356 bis r360 in ».«:
 U   .
U    integer.c
U    button.c

Dieser Anwendungsfall des Abgleichens (oder Nachziehens) von Fehlerbehebungen von einem Zweig zu einem anderen ist vielleicht der gängigste Grund für Änderungen, die Rosinen herauszupicken; es kommt ständig vor, beispielsweise, wenn ein Team einen „Software-Release-Zweig“ verwendet. (Wir erörtern dieses Muster in „Release-Zweige“.)

Warnung

Haben Sie bemerkt, wie im letzten Beispiel der Aufruf von svn merge dazu geführt hat, zwei unterschiedliche Abgleichsintervalle anzuwenden? Der Befehl führte zwei unabhängige Patches auf Ihrer Arbeitskopie aus, um die Änderungsmenge 355 zu überspringen, die Ihr Zweig bereits beinhaltete. An und für sich ist daran nichts falsch, bis auf die Tatsache, dass die Möglichkeit besteht, eine Konfliktauflösung komplizierter zu machen. Falls das erste Änderungsintervall Konflikte erzeugt, müssen Sie diese interaktiv auflösen, um die Zusammenführung fortzusetzen und das zweite Änderungsintervall anzuwenden. Wenn Sie die Konfliktauflösung der ersten Phase aufschieben, wird der komplette Zusammenführungsbefehl mit einer Fehlermeldung abbrechen. [22]

Ein Wort zur Warnung: Während svn diff und svn merge vom Konzept her sehr ähnlich sind, haben sie in vielen Fällen eine unterschiedliche Syntax. Gehen Sie sicher, dass Sie Details hierzu in Kapitel 9, Die komplette Subversion Referenz nachlesen oder svn help fragen. Zum Beispiel benötigt svn merge einen Pfad in der Arbeitskopie als Ziel, d.h., einen Ort, an dem es den erzeugten Patch anwenden kann. Falls das Ziel nicht angegeben wird, nimmt es an, dass Sie eine der folgenden häufigen Operationen durchführen möchten:

Falls Sie ein Verzeichnis zusammenführen und keinen Zielpfad angegeben haben, nimmt svn merge den ersten Fall an und versucht, die Änderungen auf Ihr aktuelles Arbeitsverzeichnis anzuwenden. Falls Sie eine Datei zusammenführen und diese Datei (oder eine gleichnamige Datei) in Ihrem aktuellen Arbeitsverzeichnis existiert, nimmt svn merge den zweiten Fall an und wendet die Änderungen auf eine lokale Datei gleichen Namens an.

Sie haben nun einige Beispiele zum Befehl svn merge gesehen und werden bald einige mehr sehen. Falls Sie verwirrt darüber sind, wie das Zusammenführen genau funktioniert, sind Sie nicht alleine. Viele Anwender (besonders diejenigen, für die Versionskontrolle etwas Neues ist) sind anfangs verwirrt darüber, wie die korrekte Syntax des Befehls lautet und wann das Feature verwendet werden soll. Aber, keine Angst, dieser Befehl ist tatsächlich viel einfacher als Sie denken! Es gibt eine einfache Technik, die verstehen hilft, wie sich svn merge genau verhält.

Die Hauptquelle der Verwirrung ist der Name des Befehls. Der Begriff „merge“ (Zusammenführung, Mischung) deutet irgendwie an, dass Zweige miteinander verschmolzen werden, oder dass irgendeine geheimnisvolle Mischung der Daten erfolgt. Das ist nicht der Fall. Ein besserer Name für den Befehl wäre vielleicht svn ermittele-die-Unterschiede-und-wende-sie-an gewesen, da das alles ist, was passiert: Die Bäume im Projektarchiv werden verglichen und die Unterschiede in eine Arbeitskopie eingearbeitet.

Falls Sie svn merge benutzen, um einfache Kopien von Änderungen zwischen Zweigen vorzunehmen, wird es üblicherweise automatisch das Richtige machen. Beispielsweise wird ein Befehl wie der folgende:

$ svn merge http://svn.example.com/repos/calc/some-branch

versuchen, alle Änderungen, die auf some-branch gemacht worden sind, in Ihr aktuelles Arbeitsverzeichnis zu kopieren, welches vermutlich eine Arbeitskopie ist, die mit dem Zweig irgendeine historische Verbindung teilt. Der Befehl ist klug genug, nur die Änderungen zu kopieren, die Ihre Arbeitskopie noch nicht hat. Wenn Sie diesen Befehl einmal die Woche wiederholen, wird er nur die „neuesten“ Änderungen vom Zweig kopieren, die seit Ihrem letzten Zusammenführen stattfanden.

Wenn Sie den Befehl svn merge in seiner ganzen Pracht wählen, indem Sie ihm bestimmte Revisionsintervalle zum kopieren übergeben, benötigt der Befehl drei Hauptargumente:

Sobald diese drei Argumente angegeben sind, werden die zwei Bäume miteinander verglichen und die Unterschiede als lokale Änderungen auf die Ziel-Arbeitskopie angewendet. Wenn der Befehl fertig ist, sieht das Ergebnis so aus, als hätten Sie die Dateien manuell editiert oder verschiedene svn add- oder svn delete-Befehle ausgeführt. Wenn Ihnen das Ergebnis gefällt, können Sie es übergeben. Falls nicht, können Sie einfach mit svn revert alle Änderungen rückgängig machen.

Die Syntax von svn merge erlaubt Ihnen, die drei notwendigen Argumente auf eine recht flexible Weise anzugeben. Hier sind einige Beispiele:

$ svn merge http://svn.example.com/repos/branch1@150 \
            http://svn.example.com/repos/branch2@212 \
            my-working-copy

$ svn merge -r 100:200 http://svn.example.com/repos/trunk my-working-copy

$ svn merge -r 100:200 http://svn.example.com/repos/trunk

Die erste Syntax führt alle drei Argumente explizit auf, indem jeder Baum mit dem Format URL@REV bezeichnet und die Ziel-Arbeitskopie angegeben wird. Die zweite Syntax kann als Kurzform verwendet werden, wenn Sie zwei unterschiedliche Revisionen desselben URL vergleichen. Die letzte Syntax zeigt, dass das Arbeitskopie-Argument optional ist; entfällt es, wird das aktuelle Verzeichnis genommen.

Obwohl das erste Beispiel die „vollständige“ Syntax von svn merge zeigt, muss sie sehr sorgfältig verwendet werden; es können hierbei Zusammenführungen entstehen, bei denen keinerlei svn:mergeinfo Metadaten aufgezeichnet werden. Der nächste Abschnitt geht näher darauf ein.

Subversion versucht immer wenn es kann, Metadaten über das Zusammenführen zu erzeugen, um spätere Aufrufe von svn merge schlauer zu machen. Trotzdem gibt es Situationen, in denen svn:mergeinfo-Daten nicht erzeugt oder geändert werden. Denken Sie daran, vor diesen Szenarien auf der Hut zu sein:

Wie der Befehl svn update wendet auch svn merge Änderungen auf Ihre Arbeitskopie an. Und deshalb kann er auch Konflikte erzeugen. Die von svn merge hervorgerufenen Konflikte sind jedoch manchmal anders geartet, und dieser Abschnitt erklärt diese Unterschiede.

Zunächst gehen wir davon aus, dass Ihre Arbeitskopie keine lokalen Änderungen enthält. Wenn Sie mit svn update auf eine bestimmte Revision aktualisieren, werden die vom Server gesendeten Änderungen immer „sauber“ auf Ihre Arbeitskopie angewendet. Der Server erzeugt das Delta, indem er zwei Bäume vergleicht: eine virtuelle Momentaufnahme Ihrer Arbeitskopie und der Revisionsbaum, an dem Sie interessiert sind. Da die linke Seite des Vergleichs völlig gleich zu dem ist, was Sie bereits haben, wird das Delta garantiert Ihre Arbeitskopie korrekt in den rechten Baum überführen.

svn merge jedoch kann das nicht gewährleisten und kann viel chaotischer sein: Der fortgeschrittene Benutzer kann den Server auffordern, irgendwelche zwei Bäume miteinander zu vergleichen, sogar solche, die nicht mit der Arbeitskopie in Beziehung stehen! Das bedeutet, dass ein hohes Potenzial für menschliche Fehler besteht. Benutzer werden manchmal die falschen zwei Bäume miteinander vergleichen, so dass ein Delta erzeugt wird, das sich nicht sauber anwenden lässt. svn merge wird sein Bestes geben, um soviel wie möglich vom Delta anzuwenden, doch bei einigen Teilen kann das unmöglich sein. So wie der Unix-Befehl patch sich manchmal über „failed hunks“ beschwert, wird sich svn merge ähnlich über „skipped targets“ beschweren:

$ svn merge -r 1288:1351 http://svn.example.com/repos/branch
U    foo.c
U    bar.c
Fehlendes Ziel: »baz.c« übersprungen.
U    glub.c
U    sputter.h

Konflikt in »glorb.h« entdeckt.
Auswahl: (p) zurückstellen, (df) voller Diff, (e) editieren,
        (h) Hilfe für weitere Optionen:

Im vorangegangenen Beispiel kann es der Fall gewesen sein, dass baz.c in beiden Momentaufnahmen des Zweiges vorkommt, die verglichen werden, und das resultierende Delta den Inhalt der Datei verändern will, die in der Arbeitskopie aber nicht vorhanden ist. Wie auch immer, die „skipped“-Nachricht bedeutet, dass der Benutzer höchstwahrscheinlich die falschen Bäume miteinander vergleicht; es ist das klassische Zeichen für einen Anwenderfehler. Falls dies passiert, ist es einfach, alle durch das Zusammenführen hervorgerufenen Änderungen rekursiv rückgängig zu machen (svn revert . --recursive), alle unversionierten Dateien oder Verzeichnisse zu löschen, die nach dem Rückgängigmachen zurückgeblieben sind, und svn merge noch einmal mit unterschiedlichen Argumenten aufzurufen.

Beachten Sie auch, dass das vorangegangene Beispiel einen Konflikt in glorb.h anzeigt. Wir bemerkten bereits, dass die Arbeitskopie keine lokalen Änderungen besitzt: Wie kann da ein Konflikt entstehen? Noch einmal: Weil der Benutzer svn merge dazu verwenden kann, ein altes Delta zu definieren und auf die Arbeitskopie anzuwenden, kann es sein, dass dieses alte Delta textuelle Änderungen enthält, die nicht sauber in eine Arbeitsdatei eingearbeitet werden können, selbst dann nicht, wenn die Datei keine lokalen Änderungen vorzuweisen hat.

Ein weiterer kleiner Unterschied zwischen svn update und svn merge sind die Namen der erzeugten Textdateien, falls ein Konflikt entsteht. In „Konflikte auflösen (Änderungen anderer einarbeiten)“ sahen wir, dass bei einer Aktualisierung die Dateien namens filename.mine, filename.rOLDREV und filename.rNEWREV erzeugt werden. Falls svn merge einen Konflikt hervorruft, erstellt es jedoch drei Dateien namens filename.working, filename.left und filename.right. In diesem Fall beschreiben die Begriffe „left“ (links) und „right“ (rechts) von welcher Seite des Vergleichs zwischen den beiden Bäumen die Datei hergeleitet wurde. Auf alle Fälle werden Ihnen diese unterschiedlichen Namen dabei helfen, zwischen Konflikten zu unterscheiden, die durch eine Aktualisierung entstanden, und solchen die durch eine Zusammenführung hervorgerufen wurden .

Manchmal gibt es eine bestimmte Änderungsmenge, die Sie nicht automatisch zusammengeführt haben wollen. Beispielsweise ist vielleicht die Vorgehensweise Ihres Teams dergestalt, dass Neuentwicklungen auf /trunk gemacht werden, aber konservativer, wenn es darum geht, Änderungen auf einen stabilen Zweig zurückzuportieren, den sie zur Veröffentlichung benutzen. Auf der einen Seite können Sie die Rosinen in Form von einzelnen Änderungsmengen manuell aus dem Stamm herauspicken und in den Zweig einpflegen – nur die Änderungen, die stabil genug sind, um die Qualitätsprüfung zu bestehen. Vielleicht ist es ja auch nicht ganz so streng, und Sie möchten normalerweise, dass svn merge die meisten Änderungen vom Stamm automatisch mit dem Zweig zusammenführt. In diesem Fall könnten Sie ein Verfahren gebrauchen, dass es Ihnen erlaubt, einige bestimmte Änderungen auszulassen, d.h. zu vermeiden, dass sie automatisch in den Zweig eingebracht werden.

Die einzige Möglichkeit, mit Subversion 1.5 eine Änderungsmenge zu blockieren, besteht darin, dem System vorzugaukeln, dass die Änderung bereits eingearbeitet wurde. Dazu können Sie den Befehl mit der Option --record-only aufrufen:

$ cd my-calc-branch

$ svn propget svn:mergeinfo .
/trunk:1680-3305

# In den Metadaten r3328 als bereits zusammengeführt vermerken.
$ svn merge -c 3328 --record-only http://svn.example.com/repos/calc/trunk

$ svn status
M     .

$ svn propget svn:mergeinfo .
/trunk:1680-3305,3328

$ svn commit -m "Das Zusammenführen von r3328 mit dem Zweig verhindern."
…

Diese Technik funktioniert zwar, sie ist allerdings auch ein wenig gefährlich. Das Hauptproblem ist, dass wir nicht klar unterscheiden zwischen „ich habe diese Änderung bereits“ und „ich habe diese Änderung nicht“. Wir belügen das System gewissermaßen, indem wir es glauben lassen, dass die Änderung schon eingearbeitet sei. Das schiebt die Verantwortung, sich daran zu erinnern, dass die Änderung tatsächlich gar nicht übernommen wurde sondern nicht gewünscht war, auf Sie – den Benutzer. Es gibt keine Möglichkeit, Subversion nach einer Liste „blockierter Änderungen“ zu fragen. Wenn Sie sie verfolgen möchten (so dass Sie eines Tages die Blockierung aufheben können) müssen Sie sie irgendwo in eine Textdatei schreiben oder in einer erfundenen Eigenschaft festhalten. Leider ist das in Subversion 1.5 die einzige Möglichkeit mit blockierten Revisionen umzugehen; ein besseres Interface dafür ist für künftige Versionen geplant.

Ein Hauptmerkmal jedes Versionskontrollsystems ist es, darüber Buch zu führen, wer was wann geändert hat. Die Befehle svn log und svn blame sind die geeigneten Werkzeuge hierfür: Wenn sie auf individuelle Dateien angewendet werden, zeigen sie nicht nur die Geschichte der Änderungsmengen, die in diese Datei hineinflossen, sondern auch, welcher Benutzer wann welche Zeile im Quelltext geschrieben hat.

Wenn jedoch Änderungen über Zweige hinweg dupliziert werden, wird es schnell kompliziert. Wenn Sie z.B. svn log nach der Geschichte Ihres Zweigs fragen, wird es Ihnen exakt jede Revision anzeigen, die je in den Zweig hineingeflossen ist:

$ cd my-calc-branch
$ svn log -q
------------------------------------------------------------------------
r390 | user | 2002-11-22 11:01:57 -0600 (Fr, 22. Nov 2002) | 1 line
------------------------------------------------------------------------
r388 | user | 2002-11-21 05:20:00 -0600 (Do, 21. Nov 2002) | 2 lines
------------------------------------------------------------------------
r381 | user | 2002-11-20 15:07:06 -0600 (Mi, 20. Nov 2002) | 2 lines
------------------------------------------------------------------------
r359 | user | 2002-11-19 19:19:20 -0600 (Di, 19. Nov 2002) | 2 lines
------------------------------------------------------------------------
r357 | user | 2002-11-15 14:29:52 -0600 (Fr, 15. Nov 2002) | 2 lines
------------------------------------------------------------------------
r343 | user | 2002-11-07 13:50:10 -0600 (Do, 07. Nov 2002) | 2 lines
------------------------------------------------------------------------
r341 | user | 2002-11-03 07:17:16 -0600 (So, 03. Nov 2002) | 2 lines
------------------------------------------------------------------------
r303 | sally | 2002-10-29 21:14:35 -0600 (Di, 29. Oct 2002) | 2 lines
------------------------------------------------------------------------
r98 | sally | 2002-02-22 15:35:29 -0600 (Fr, 22. Feb 2002) | 2 lines
------------------------------------------------------------------------

Aber ist das wirklich eine genaue Wiedergabe aller Änderungen, die auf dem Zweig stattgefunden haben? Was hier ausgelassen wird, ist, dass die Revisionen 390, 381 und 357 tatsächlich Ergebnisse des Zusammenführens von Änderungen aus dem Stamm waren. Wenn Sie sich eins dieser Protokolle im Detail anschauen, können Sie die verschiedenen Änderungsmengen vom Stamm, die die Änderungen auf dem Zweig ausmachen, nirgendwo sehen:

$ svn log -v -r 390
------------------------------------------------------------------------
r390 | user | 2002-11-22 11:01:57 -0600 (Fri, 22 Nov 2002) | 1 line
Geänderte Pfade:
   M /branches/my-calc-branch/button.c
   M /branches/my-calc-branch/README

Letzte Zusammenführung der Änderungen von trunk changes in my-calc-branch.

Wir wissen, dass diese Zusammenführung in den Zweig nichts anderes war als eine Zusammenführung von Änderungen vom Stamm. Wie können wir zusätzlich diese Änderungen sehen? Die Antwort lautet, die Option --use-merge-history (-g) zu verwenden. Diese Option expandiert diejenigen „Teil“-Änderungen, aus denen die Zusammenführung bestand.

$ svn log -v -r 390 -g
------------------------------------------------------------------------
r390 | user | 2002-11-22 11:01:57 -0600 (Fri, 22 Nov 2002) | 1 line
Geänderte Pfade:
   M /branches/my-calc-branch/button.c
   M /branches/my-calc-branch/README

Letzte Zusammenführung der Änderungen von trunk changes in my-calc-branch.
------------------------------------------------------------------------
r383 | sally | 2002-11-21 03:19:00 -0600 (Thu, 21 Nov 2002) | 2 lines
Geänderte Pfade:
   M /branches/my-calc-branch/button.c
Zusammengeführt mittels: r390

Inverse Grafik auf Knopf behoben.
------------------------------------------------------------------------
r382 | sally | 2002-11-20 16:57:06 -0600 (Wed, 20 Nov 2002) | 2 lines
Geänderte Pfade:
   M /branches/my-calc-branch/README
Zusammengeführt mittels: r390

Meine letzte Änderung in README dokumentiert.

Dadurch, dass wir die Protokoll-Operation aufgefordert haben, die Geschichte der Zusammenführungen zu verwenden, sehen wir nicht nur die Revision, die wir abgefragt haben (r390), sondern auch die zwei Revisionen, die hier mitkamen – ein paar Änderungen, die Sally auf dem Stamm gemacht hat. Das ist ein wesentlich vollständigeres Bild der Geschichte!

Auch der svn blame-Befehl versteht die Option --use-merge-history (-g). Falls diese Option vergessen wird, könnte jemand, der sich die zeilenweisen Anmerkungen von button.c ansieht, fälschlicherweise davon ausgehen, dass Sie für die Zeilen verantwortlich sind, die einen bestimmten Fehler beseitigt haben:

$ svn blame button.c
…
   390    user    retval = inverse_func(button, path);
   390    user    return retval;
   390    user    }
…

Obwohl es zutrifft, dass Sie diese drei Zeilen in Revision 390 übergeben haben, sind zwei davon tatsächlich von Sally in Revision 383 geschrieben worden:

$ svn blame button.c -g
…
G    383    sally   retval = inverse_func(button, path);
G    383    sally   return retval;
     390    user    }
…

Nun wissen wir, wer wirklich für die zwei Zeilen Quelltext verantwortlich ist!

Wenn Sie sich mit einem Subversion-Entwickler unterhalten, wird wahrscheinlich auch der Begriff Abstammung erwähnt. Dieses Wort wird verwendet, um die Beziehung zwischen zwei Objekten im Projektarchiv zu beschreiben: Wenn sie in Beziehung zueinander stehen, heißt es, dass ein Objekt vom anderen abstammt.

Nehmen wir an, Sie übergeben Revision 100, die eine Änderung an der Datei foo.c beinhaltet. Dann ist foo.c@99 ein „Vorfahre“ von foo.c@100. Wenn Sie dagegen in Revision 101 die Löschung von foo.c übergeben und in Revision 102 eine neue Datei mit demselben Namen hinzufügen, hat es zwar den Anschein, dass foo.c@99 und foo.c@102 in Beziehung zueinander stehen (sie haben denselben Pfad), es handelt sich allerdings um völlig unterschiedliche Objekte im Projektarchiv. Sie haben weder eine gemeinsame Geschichte noch „Abstammung“.

Wir erwähnen das, um auf einen wichtigen Unterschied zwischen den Befehlen svn diff und svn merge hinzuweisen. Der erstere Befehl ignoriert die Abstammung, wohingegen letzterer diese beachtet. Wenn Sie beispielsweise mit svn diff die Revisionen 99 und 102 von foo.c vergleichen, werden Sie zeilenbasierte Unterschiede sehen; der Befehl diff vergleicht blind zwei Pfade. Wenn Sie aber dieselben Objekte mit svn merge vergleichen, wird es feststellen, dass sie nicht in Beziehung stehen und versuchen, die alte Datei zu löschen und dann die neue hinzuzufügen; die Ausgabe wird eine Löschung gefolgt von einer Hinzufügung anzeigen:

D    foo.c
A    foo.c
      

Die meisten Zusammenführungen vergleichen Bäume, die von der Abstammung her miteinander in Beziehung stehen, deshalb verhält sich svn merge auf diese Weise. Gelegentlich möchten Sie jedoch mit dem merge-Befehl zwei Bäume vergleichen, die nicht miteinander in Beziehung stehen. Es kann z.B. sein, dass Sie zwei Quelltext-Bäume importiert haben, die unterschiedliche Lieferantenstände eines Software-Projektes repräsentieren (siehe „Lieferanten-Zweige“). Falls Sie svn merge dazu aufforderten, die beiden Bäume miteinander zu vergleichen, würden Sie sehen, dass der vollständige erste Baum gelöscht und anschließend der vollständige zweite Baum hinzugefügt würde! In diesen Situationen möchten Sie, dass svn merge lediglich einen pfadbasierten Vergleich vornimmt und Beziehungen zwischen Dateien und Verzeichnissen außer Acht lässt. Fügen Sie die Option --ignore-ancestry dem merge-Befehl hinzu, und er wird sich verhalten wie svn diff. (Auf der anderen Seite wird die Option --notice-ancestry den Befehl svn diff dazu veranlassen, sich wie svn merge zu verhalten.

Es ist ein verbreiteter Wunsch, Software zu refaktorieren, besonders in Java-basierten Software-Projekten. Dateien und Verzeichnisse werden hin und her geschoben und umbenannt, was häufig zu erheblichen Beeinträchtigungen für alle Projektmitarbeiter führt. Das hört sich an, als sei das der klassische Fall, um nach einem Zweig zu greifen, nicht wahr? Sie erzeugen einfach einen Zweig, schieben das Zeug herum und führen anschließend den Zweig mit dem Stamm zusammen.

Leider funktioniert dieses Szenario im Augenblick noch nicht so richtig und gilt als einer der Schwachpunkte von Subversion. Das Problem ist, das der Subversion-Befehl svn update nicht so stabil ist, wie er sein sollte, besonders wenn es um Kopier- und Verschiebeoperationen geht.

Wenn Sie svn copy zum Duplizieren einer Datei verwenden, merkt sich das Projektarchiv, woher die neue Datei kam, versäumt aber, diese Information an den Client zu senden, der svn update oder svn merge ausführt. Statt dem Client mitzuteilen: „Kopiere die Datei, die du bereits hast an diesen neuen Ort“, sendet es eine völlig neue Datei. Das kann zu Problemen führen, besonders, weil dasselbe mit umbenannten Dateien passiert. Eine weniger bekannte Tatsache über Subversion ist, dass es keine „echten Umbenennungen“ hat – der Befehl svn move ist weiter nichts als eine Verbindung von svn copy und svn delete.

Nehmen wir beispielsweise an, dass Sie während Ihrer Arbeit auf Ihrem privaten Zweig integer.c in whole.c umbenennen. Tatsächlich haben Sie eine neue Datei auf Ihrem Zweig erzeugt, die eine Kopie der ursprünglichen Datei ist, und letztere gelöscht. Zwischenzeitlich hat Sally einige Verbesserungen an integer.c in trunk übergeben. Nun entscheiden Sie sich, Ihren Zweig mit dem Stamm zusammenzuführen:

$ cd calc/trunk

$ svn merge --reintegrate http://svn.example.com/repos/calc/branches/my-calc-branch
-- Zusammenführen der Unterschiede zwischen Projektarchiv-URLs in ».«:
D   integer.c
A   whole.c
U   .
      

Auf den ersten Blick sieht es gar nicht schlecht aus, jedoch ist es nicht das, was Sie und Sally erwartet hätten. Die Zusammenführung hat die letzte Version der Datei integer.c gelöscht (diejenige, die Sallys Änderungen beinhaltet) und blindlings Ihre neue Datei whole.c hinzugefügt – die ein Duplikat der älteren Version von integer.c ist. Das Endergebnis ist, dass durch die Zusammenführung Ihrer „Umbenennung“ auf dem Zweig mit dem Stamm Sallys jüngste Änderungen aus der letzten Revision entfernt wurden.

Es ist kein echter Datenverlust. Sallys Änderungen befinden sich noch immer in der Geschichte des Projektarchivs, allerdings mag es nicht sofort ersichtlich sein, dass es passiert ist. Die Lehre, die es aus dieser Geschichte zu ziehen gilt, lautet, dass Sie sehr vorsichtig mit dem Zusammenführen von Kopien und Umbenennungen zwischen Zweigen sein sollten, solange sich Subversion an dieser Stelle nicht verbessert hat.

Wenn Sie gerade Ihren Server auf Subversion 1.5 oder größer umgestellt haben, besteht ein signifikantes Risiko, dass Subversion-Clients einer kleineren Version als 1.5 Ihre automatische Zusammenführungs-Verfolgung durcheinander bringen können. Warum? Wenn ein älterer Subversion-Client svn merge ausführt, modifiziert er nicht den Wert der Eigenschaft svn:mergeinfo. Obwohl die anschließende Übergabe das Ergebnis einer Zusammenführung ist, wird dem Projektarchiv nichts über die duplizierten Änderungen mitgeteilt – diese Information ist verloren. Wenn später Clients, die Zusammenführungsinformationen auswerten, automatische Zusammenführungen versuchen, werden Sie wahrscheinlich in alle möglichen Konflikte laufen, die durch wiederholte Zusammenführungen hervorgerufen wurden.

Wenn Sie und Ihr Team auf die Zusammenführungs-Verfolgung von Subversion angewiesen sind, sollten Sie Ihr Projektarchiv dergestalt konfigurieren, dass ältere Clients daran gehindert werden, Änderungen zu übergeben. Die einfache Methode hierfür ist es, den „Fähigkeiten“-Parameter im start-commit Hook-Skript zu untersuchen. Wenn der Client meldet, dass er mit mergeinfo umgehen kann, kann das Skript den Beginn der Übergabe erlauben. Wenn der Client diese Fähigkeit nicht meldet, wird die Übergabe abgelehnt. Wir werden mehr über Hook-Skripte im nächsten Kapitel erfahren; siehe „Erstellen von Projektarchiv-Hooks“ und start-commit für Details.

Unter dem Strich bedeutet das, dass die Fähigkeit von Subversion zur Zusammenführungs-Verfolgung eine höchst komplexe interne Implementierung besitzt und die Eigenschaft svn:mergeinfo das einzige Fenster zu diesem Räderwerk ist. Da diese Fähigkeit relativ neu ist, kann eine Anzahl von Randfällen und mögliche unerwartete Verhaltensweisen auftauchen.

So kann zum Beispiel Mergeinfo manchmal durch einen einfachen svn copy- oder svn move-Befehl erzeugt werden. Manchmal wird Mergeinfo an Dateien auftauchen, von denen Sie nicht erwartet hätten, dass sie durch die Operation berührt worden wären. Manchmal wird Mergeinfo überhaupt nicht erzeugt, obwohl Sie es erwartet hätten. Darüberhinaus umgibt die Verwaltung der Mergeinfo-Metadaten eine ganze Menge von Systematiken und Verhalten, wie „explizite“ gegenüber „implizite“ Mergeinfo, „operative“ gegenüber „inoperativen“ Revisionen, besondere Mechanismen von Mergeinfo-„Auslassung“ und sogar „Vererbung“ von Eltern- zu Kindverzeichnissen.

Wir haben uns entschieden, diese detaillierten Themen aus einer Reihe von Gründen nicht in diesem Buch zu behandeln. Erstens ist der Detaillierungsgrad für einen normalen Benutzer absolut erdrückend. Zweitens glauben wir, dass das Verständnis diese Konzepte für einen typischen Benutzer nicht unbedingt erforderlich sein sollte während Subversion sich verbessert; letztendlich werden sie als nervige Implementierugsdetails in den Hintergrund treten. Wenn Sie, nachdem dies gesagt ist, diese Dinge mögen, können Sie einen fantastischen Überblick in einer Arbeit nachlesen, die auf der Webseite von CollabNet veröffentlicht ist:http://www.collab.net/community/subversion/articles/merge-info.html.

Fürs Erste empfiehlt CollabNet, sich an die folgenden bewährten Praktiken zu halten, wenn Sie Fehler und merkwürdiges Verhalten bei automatischen Zusammenführungen vermeiden wollen:

Wieder einmal hilft Ihnen svn copy bei der Arbeit. Wenn Sie eine Momentaufnahme von /calc/trunk machen wollen, genau so, wie es in der Revision HEAD aussieht, machen Sie davon eine Kopie:

$ svn copy http://svn.example.com/repos/calc/trunk \
           http://svn.example.com/repos/calc/tags/release-1.0 \
      -m "Ein Tag für die Ausgabe 1.0 des 'calc' Projektes anlegen."

Revision 902 übertragen.

Dieses Beispiel geht davon aus, dass ein Verzeichnis /calc/tags bereits besteht. (Falls nicht, können Sie es mit svn mkdir erstellen.) Nach Abschluss der Kopie ist das neue Verzeichnis release-1.0 für immer eine Momentaufnahme des Verzeichnisses /trunk in der Revision HEAD zum Zeitpunkt, an dem Sie die Kopie erstellt haben. Natürlich können Sie auch angeben, welche Revision Sie genau kopieren möchten, für den Fall, dass jemand anderes Änderungen an das Projekt übergeben haben könnte, während Sie nicht hingeschaut haben. Wenn Sie also wissen, dass Revision 901 von /calc/trunk genau die Momentaufnahme ist, die Sie möchten, können Sie sie mit der Option -r 901 an den Befehl svn copy übergeben.

Moment mal: ist die Erstellung eines Tags nicht dasselbe Vorgehen wie bei der Erstellung eines Zweigs? Ja, es ist es tatsächlich. In Subversion gibt es keinen Unterschied zwischen einem Tag und einem Zweig. Beides sind gewöhnliche Verzeichnisse, die durch Kopieren erzeugt werden. Genauso wie bei Zweigen, ist der einzige Grund warum ein kopiertes Verzeichnis ein „Tag“ ist, weil Menschen sich entschieden haben, es so zu betrachten: Solange niemand etwas an das Verzeichnis übergibt, bleibt es für immer eine Momentaufnahme. Wenn jemand damit beginnt, etwas dorthin zu übergeben, wird es ein Zweig.

Wenn Sie ein Projektarchiv verwalten, gibt es zwei Ansätze für den Umgang mit Tags. Der erste Ansatz ist „Hände weg“: Als Vereinbarung im Projekt entscheiden Sie, wohin Sie Ihre Tags kopieren möchten; stellen Sie sicher, dass alle Benutzer wissen, wie sie ihre zu kopierenden Verzeichnisse behandeln sollen, d.h., stellen Sie sicher, dass sie nichts dorthin übergeben. Der zweite Ansatz ist etwas paranoider: Sie können eins der Zugriffskontrollskripte verwenden, die mit Subversion ausgeliefert werden, um zu verhindern, dass irgendjemand etwas anderes im Tag-Bereich macht, als dort neue Kopien zu erzeugen (siehe Kapitel 6, Die Administration eines Subversion-Servers). Der paranoide Ansatz ist normalerweise nicht notwendig. Falls ein Benutzer versehentlich eine Änderung an ein Tag-Verzeichnis übergeben hat, können Sie die Änderung einfach rückgängig machen, wie im vorhergehenden Abschnitt beschrieben. Schließlich handelt es sich um Versionskontrolle!

Manchmal möchten Sie vielleicht eine „Momentaufnahme“ machen, die komplizierter ist als ein einzelnes Verzeichnis mit einer einzigen Revision.

Stellen Sie sich beispielsweise vor, Ihr Projekt sei viel größer als unser calc Beispiel: Nehmen wir an, es enthalte eine große Zahl von Unterverzeichnissen und viel mehr Dateien. Während Ihrer Arbeit könnte es sein, dass Sie sich entscheiden, eine Arbeitskopie anzulegen, die bestimmte Merkmale und Fehlerbehebungen beinhaltet. Sie können dies hinbekommen, indem Sie selektiv Dateien oder Verzeichnisse auf bestimmte Revisionen zurückdatieren (unter Verwendung von svn update mit der Option -r), indem Sie Dateien und Verzeichnisse auf bestimmte Zweige umschalten (mit svn switch) oder sogar, indem Sie ein paar lokale Änderungen vornehmen. Wenn Sie fertig sind, ist Ihre Arbeitskopie ein Mischmasch aus Projektarchiv-Quellen verschiedener Revisionen. Nach dem Testen wissen Sie jedoch, dass das genau die Kombination ist, die Sie mit einem Tag versehen möchten.

Nun ist es an der Zeit, eine Momentaufnahme zu machen. Einen URL auf einen anderen zu kopieren hilft hier nicht weiter. In diesem Fall möchten Sie eine Momentaufnahme der exakten Anordnung Ihrer Arbeitskopie machen und sie im Projektarchiv speichern. Glücklicherweise besitzt svn copy vier verschiedene Anwendungsfälle (über die Sie in Kapitel 9, Die komplette Subversion Referenz nachlesen können), zu denen auch die Fähigkeit gehört, einen Arbeitskopie-Baum ins Projektarchiv zu kopieren:

$ ls
my-working-copy/

$ svn copy my-working-copy \
           http://svn.example.com/repos/calc/tags/mytag \
           -m "Ein Tag für den Zustand meines Arbeitsverzeichnisses anlegen."

Revision 940 übertragen.

Nun gibt es ein neues Verzeichnis im Projektarchiv, /calc/tags/mytag, das eine exakte Momentaufnahme Ihrer Arbeitskopie ist – gemischte Revisionen, URLs, lokale Änderungen, usw.

Andere Benutzer haben interessante Anwendungsfälle für diese Fähigkeit von Subversion gefunden. Manchmal gibt es Situationen, in denen Sie ein paar lokale Änderungen in Ihrer Arbeitskopie gemacht haben, die ein Mitarbeiter sehen soll. Statt svn diff aufzurufen und eine Patch-Datei zu versenden (die allerdings weder Änderungen an Verzeichnissen, symbolischen Links oder Eigenschaften beinhaltet), können Sie svn copy verwenden, um Ihre Arbeitskopie in einen privaten Bereich des Projektarchivs „abzulegen“. Ihr Mitarbeiter kann dann entweder eine exakte Kopie Ihrer Arbeitskopie auschecken oder svn merge verwenden, um genau Ihre Änderungen zu empfangen.

Obwohl dies eine nette Methode ist, schnell eine Momentaufnahme Ihrer Arbeitskopie anzulegen, sollten Sie beachten, dass es keine gute Vorgehensweise ist, einen Zweig zu erstellen. Die Erzeugung eines Zweigs sollte ein Ereignis für sich sein, wohingegen diese Methode die Erzeugung eines Zweigs mit zusätzlichen Änderungen an Dateien innerhalb einer einzelnen Revision verbindet. Das macht es später sehr schwer, eine einzelne Revisionsnummer als Verzweigungspunkt zu identifizieren.

Es gibt einige empfohlene Standards, ein Projektarchiv zu organisieren. Die meisten Leute erzeugen ein trunk-Verzeichnis, um die Hauptlinie der Entwicklung aufzunehmen, ein branches-Verzeichnis für Zweig-Kopien und ein tags-Verzeichnis für Tag-Kopien. Falls ein Projektarchiv nur ein Projekt beinhaltet, werden oft diese Verzeichnisse auf der obersten Ebene angelegt:

/trunk
/branches
/tags

Falls ein Projektarchiv mehrere Projekte enthält, teilen Administratoren das Projektarchiv üblicherweise nach den Projekten ein (lesen Sie in „Planung der Organisation Ihres Projektarchivs“ mehr über „Projekt-Wurzelverzeichnisse“):

/paint/trunk
/paint/branches
/paint/tags
/calc/trunk
/calc/branches
/calc/tags

Natürlich ist es Ihnen freigestellt, diese verbreiteten Strukturen zu ignorieren. Sie können alle möglichen Variationen erzeugen, die am besten für Sie oder Ihr Team funktionieren. Denken Sie daran, dass es, wie auch immer Sie sich entscheiden, nicht für die Ewigkeit sein muss. Sie können jederzeit Ihr Projektarchiv umorganisieren. Da Zweige und Tags gewöhnliche Verzeichnisse sind, kann der Befehl svn move sie nach Belieben verschieben oder umbenennen. Die Umstrukturierung ist einfach eine Sache von serverseitigen Verschiebebefehlen. Wenn Ihnen der Aufbau des Projektarchivs nicht zusagt, jonglieren Sie einfach mit den Verzeichnissen herum.

Obwohl es einfach ist, Verzeichnisse zu verschieben, sollten Sie Rücksicht auf Ihre Benutzer nehmen. Ihr Jonglieren kann verwirrend für Benutzer mit bestehenden Arbeitskopien sein. Falls ein Benutzer eine Arbeitskopie eines bestimmten Projektarchiv-Verzeichnisses hat, könnte Ihre svn move-Operation den Pfad von der letzten Revision entfernen. Wenn der Benutzer beim nächsten Mal svn update aufruft, wird ihm mitgeteilt, dass die Arbeitskopie einen Pfad repräsentiere, der nicht mehr bestehe, so dass er gezwungen ist, mit svn switch auf den neuen Ort umzuschalten.

Eine weitere nette Eigenschaft des Subversion-Modells ist die Möglichkeit, Zweigen und Tags eine begrenzte Lebensdauer zu geben, so wie jedem anderen versionierten Objekt. Nehmen wir beispielsweise an, dass Sie letztendlich Ihre Arbeit auf dem persönlichen Zweig des calc-Projektes abschließen. Nachdem Sie all Ihre Änderungen zurück nach /calc/trunk gebracht haben, braucht Ihr privater Zweig nicht mehr herumzuliegen:

$ svn delete http://svn.example.com/repos/calc/branches/my-calc-branch \
             -m "Veralteten Zweig des Projekts calc gelöscht."

Revision 375 übertragen.

Nun ist Ihr Zweig verschwunden. Selbstverständlich ist er nicht wirklich verschwunden: das Verzeichnis fehlt einfach in der HEAD-Revision, so dass es niemanden mehr ablenken kann. Wenn Sie svn checkout, svn switch oder svn list verwenden, um sich eine frühere Revision anzusehen, werden Sie immer noch Ihren alten Zweig sehen.

Falls es nicht ausreichen sollte, im gelöschten Verzeichnis zu stöbern, können Sie es jederzeit wieder zurückholen. Das Wiederbeleben von Daten in Subversion ist sehr einfach. Falls ein gelöschtes Verzeichnis (oder eine gelöschte Datei) wieder nach HEAD gebracht werden soll, verwenden Sie einfach svn copy zum Kopieren aus der alten Revision:

$ svn copy http://svn.example.com/repos/calc/branches/my-calc-branch@374 \
           http://svn.example.com/repos/calc/branches/my-calc-branch \
           -m "my-calc-branch wiederhergestellt."

Revision 376 übertragen.

In unserem Beispiel hatte Ihr persönlicher Zweig eine relativ kurze Lebensdauer: Sie haben ihn vielleicht angelegt, um einen Fehler zu beseitigen oder eine neue Funktion einzubauen. Wenn Ihr Arbeitspaket abgeschlossen ist, kann auch der Zweig geschlossen werden. In der Softwareentwicklung ist es allerdings auch üblich, zwei „Haupt“-Zweige zu haben, die für lange Zeit nebeneinander bestehen. Es ist zum Beispiel an der Zeit, eine stabile Version des calc-Projektes zu veröffentlichen, und Sie wissen, dass es wohl noch ein paar Monate dauern wird, um Fehler aus der Software zu entfernen. Sie wollen weder, dass dem Projekt neue Funktionen hinzugefügt werden, noch möchten Sie alle Entwicklern auffordern, das Programmieren einzustellen. Stattdessen erstellen Sie einen „stabilen“ Zweig der Software, auf dem sich nicht viel verändern wird:

$ svn copy http://svn.example.com/repos/calc/trunk \
           http://svn.example.com/repos/calc/branches/stable-1.0 \
           -m "Stabilen Zweig für Projekt calc angelegt."

Revision 377 übertragen.

Nun können Entwickler die neuesten (oder experimentellen) Funktionen /calc/trunk hinzufügen, während Sie zum Grundsatz erklären, dass ausschließlich Fehlerbehebungen an /calc/branches/stable-1.0 übergeben werden. Das heißt, während auf dem Stamm weitergearbeitet wird, überträgt jemand selektiv Fehlerbehebungen auf den stabilen Zweig. Selbst wenn die Software von hier bereits ausgeliefert worden ist, werden Sie diesen Zweig wahrscheinlich noch für eine lange Zeit pflegen – das heißt, so lange, wie Sie diese Auslieferung beim Kunden unterstützen werden. Wir werden das im nächsten Abschnitt näher erörtern.

Die meiste Software hat einen typischen Lebenszyklus: Erstellung, Test, Freigabe und wieder von vorne. Bei diesem Prozess gibt es zwei Probleme. Erstens müssen Entwickler neue Funktionen schreiben, während das Qualitätssicherungsteam sich Zeit zum Testen der vermeintlich stabilen Software nimmt. Die Arbeit kann allerdings nicht liegenbleiben während die Software getestet wird. Zweitens muss das Team fast immer ältere, bereits an den Kunden herausgegebene Software unterstützen; falls im neuesten Quelltext ein Fehler entdeckt wird, besteht der Fehler wahrscheinlich auch in der herausgegebenen Version. Die Kunden möchten dann eine Fehlerbehebung, ohne auf ein größeres, neues Release zu warten.

Hier kann Versionskontrolle helfen. Die typische Vorgehensweise ist wie folgt:

Der gesamte Prozess wiederholt sich während die Software reift: Wenn die Arbeit an 2.0 fertig ist, wird ein neuer 2.0 Release-Zweig erstellt, getestet, markiert und schließlich freigegeben. Nach einigen Jahren füllt sich das Projektarchiv mit einer Anzahl von Release-Zweigen, die weiterhin „gepflegt“ werden, und einer Zahl von Tags, die den endgültigen, ausgelieferten Versionen entsprechen.

Ein Funktions-Zweig ist die Art von Zweig, wie er im Hauptbeispiel dieses Kapitels vorkam (der Zweig, auf dem Sie gearbeitet haben, während Sally auf /trunk arbeitete). Es ist ein vorübergehender Zweig, der angelegt wird, um an einer komplexen Änderung zu arbeiten, ohne /trunk zu stören. Anders als Release-Zweige (die vielleicht ewig gepflegt werden müssen), werden Funktions-Zweige erstellt, eine Zeit lang genutzt, zurück in den Stamm integriert und schließlich gelöscht. Sie haben einen zeitlich begrenzten Nutzen.

In Projekten gehen die Meinungen oft auseinander, wann der richtige Zeitpunkt zum Anlegen eines Funktions-Zweiges gekommen ist. Manche Projekte benutzen nie Funktions-Zweige: jeder darf Änderungen in /trunk übergeben. Der Vorteil hier ist, dass es einfach ist – niemand benötigt eine Schulung im Verzweigen und Zusammenführen. Der Nachteil ist, dass der Code oft instabil oder nicht nutzbar ist. Andere Projekte verwenden ausschließlich Zweige: Eine Änderung darf niemals direkt in /trunk übergeben werden. Selbst die trivialsten Änderungen werden auf einem kurzlebigen Zweig durchgeführt, sorgfältig geprüft und in den Stamm zurückgeführt. Danach wird der Zweig gelöscht. Dieses Vorgehen garantiert einen außerordentlich stabilen und nutzbaren Stamm, jedoch zum Preis eines erheblichen Prozessaufwands.

Die meisten Projekte bewegen sich irgendwo dazwischen. Gewöhnlich bestehen sie darauf, dass /trunk stets compilierfähig bleibt und Regressionstests besteht. Ein Funktions-Zweig wird nur dann benötigt, falls eine Änderung eine große Anzahl destabilisierender Übergaben erfordert. Eine gute Faustregel ist, diese Frage zu stellen: Wäre, falls ein Entwickler nach Tagen isolierter Entwicklung die große Änderung auf einmal übergäbe (so dass /trunk nie instabil würde), die Änderung zu umfangreich zum Überprüfen? Falls die Antwort auf diese Frage „ja“ lautet, sollte die Änderung auf einem Funktions-Zweig durchgeführt werden. Während der Entwickler schrittweise Änderungen in den Zweig übergibt, können sie auf einfache Weise von den Kollegen geprüft werden.

Schließlich stellt sich die Frage, wie ein Funktions-Zweig am besten mit dem Stamm „synchron“ gehalten werden kann während die Arbeit weitergeht. Wie wir vorher bereits bemerkten, besteht ein großes Risiko, wenn wochen- oder monatelang auf dem Zweig gearbeitet wird; währenddessen ändert sich auch der Stamm, so dass ein Punkt erreicht werden kann, an dem sich die beiden Entwicklungslinien so sehr unterscheiden, dass es zu einem Albtraum ausarten kann, den Zweig zurück auf den Stamm zu führen.

Diese Situation wird am besten vermieden, indem regelmäßig Änderungen vom Stamm in den Zweig eingearbeitet werden. Machen Sie es zur Gewohnheit: Arbeiten Sie wöchentlich die Änderungen der vergangenen Woche vom Stamm in den Zweig ein.

Irgendwann werden Sie dann bereit sein, den „synchronisierten“ Funktions-Zweig zurück in den Stamm zu führen. Hierzu arbeiten Sie ein letztes Mal die jüngsten Änderungen vom Stamm in den Zweig ein. Danach werden die letzten Versionen auf dem Stamm und dem Zweig, bis auf Ihre Änderungen auf dem Zweig, absolut gleich sein. Dann werden Sie den Zweig mit der Option --reintegrate wieder mit dem Stamm zusammenführen:

$ cd trunk-working-copy

$ svn update
Revision 1910.

$ svn merge --reintegrate http://svn.example.com/repos/calc/branches/mybranch
-- Zusammenführen der Unterschiede zwischen Projektarchiv-URLs in ».«:
U    real.c
U    integer.c
A    newdirectory
A    newdirectory/newfile
 U   .
…

Aus einem anderen Winkel betrachtet ist dieser wöchentliche Abgleich vom Stamm auf den Zweig analog zum Ausführen von svn update in einer Arbeitskopie, wobei das finale Zusammenführen svn commit in einer Arbeitskopie entspricht. Ist denn letztendlich eine Arbeitskopie nicht ein sehr flacher privater Zweig? Es ist ein Zweig, der nur eine Änderung gleichzeitig aufnehmen kann.

Die Verwaltung von Lieferanten-Zweigen funktioniert im Allgemeinen so: Zunächst erzeugen Sie ein übergeordnetes Hauptverzeichnis (etwa /vendor), um Lieferanten-Zweige aufzunehmen. Dann importieren Sie den Code des Drittanbieters in ein Unterverzeichnis des Hauptverzeichnisses. Anschließend kopieren Sie dieses Unterverzeichnis an die passende Stelle Ihres Hauptentwicklungszweigs (z.B. /trunk). Ihre lokalen Änderungen nehmen Sie stets im Hauptentwicklungszweig vor. Jede erneut veröffentlichte Version des von Ihnen verfolgten Codes pflegen Sie in den Lieferanten-Zweig ein und überführen die Änderungen nach /trunk, wobei eventuelle Konflikte zwischen Ihren lokalen Änderungen und dem Code des Zulieferers aufgelöst werden.

Ein Beispiel hilft, um dieses Vorgehen zu erklären. Wir gehen von einem Szenario aus, in dem Ihr Entwicklerteam ein Taschenrechner-Programm entwickelt, dass mit einer Bibliothek eines Drittanbieters für die Arithmetik mit komplexen Zahlen, namens libcomplex, verlinkt wird. Wir beginnen mit dem Anlegen des Lieferanten-Zweiges und dem Import der ersten Zulieferung. Wir nennen unser Verzeichnis für den Lieferanten-Zweig libcomplex, und die Lieferungen werden in einem Unterverzeichnis namens current abgelegt. Da svn import alle dazwischen liegenden Elternverzeichnisse erzeugt, können wir all diese Schritte mit einem einzigen Befehl bewerkstelligen:

$ svn import /path/to/libcomplex-1.0 \
             http://svn.example.com/repos/vendor/libcomplex/current \
             -m 'Importing der ersten 1.0 Zulieferung'
…

Nun haben wir die aktuelle Version des Quelltextes von libcomplex in /vendor/libcomplex/current. Jetzt erzeugen wir ein Tag aus dieser Version (siehe „Tags“) und kopieren sie dann in den Hauptentwicklungszweig. Unsere Kopie erzeugt ein neues Verzeichnis libcomplex im bestehenden calc Projektverzeichnis. In dieser kopierten Version der Lieferantendaten werden wir unsere Anpassungen vornehmen:

$ svn copy http://svn.example.com/repos/vendor/libcomplex/current  \
           http://svn.example.com/repos/vendor/libcomplex/1.0      \
           -m 'Tag libcomplex-1.0'
…
$ svn copy http://svn.example.com/repos/vendor/libcomplex/1.0  \
           http://svn.example.com/repos/calc/libcomplex        \
           -m 'libcomplex-1.0 in den Huptzweig bringen'
…

Wir checken nun den Hauptzweig unseres Projektes aus – der nun eine Kopie der ersten Zulieferung enthält – und fangen damit an, den Quelltext von libcomplex anzupassen. Ehe wir uns versehen, ist unsere angepasste Version von libcomplex vollständig in unser Taschenrechner-Programm integriert. ^[25]

Ein paar Wochen später veröffentlichen die Entwickler von libcomplex eine neue Version ihrer Bibliothek – Version 1.1 – die die Funktionalität enthält, die wir dringend benötigen. Wir möchten die neue Version verwenden, ohne jedoch unsere Anpassungen zu verlieren, die wir in der bestehenden Version vorgenommen haben. Unterm Strich möchten wir die bestehende Baseline-Version libcomplex 1.0 durch eine Kopie von libcomplex 1.1 ersetzen und die vorher gemachten Anpassungen an dieser Bibliothek erneut auf die neue Version anwenden. Tatsächlich gehen wir das Problem allerdings aus der anderen Richtung an, indem wir die Änderungen an libcomplex zwischen Version 1.0 und 1.1 in unsere angepasste Kopie einpflegen.

Um diesen Wechsel auf die neue Version durchzuführen, checken wir eine Kopie des Lieferanten-Zweigs aus und ersetzen den Code im Verzeichnis current mit dem neuen Quelltext von libcomplex 1.1. Wir kopieren im wahrsten Sinne des Wortes die neuen Dateien über die bestehenden, indem wir etwa das Archiv von libcomplex 1.1 in das bestehende Verzeichnis entpacken. Das Ziel ist, dass das Verzeichnis current nur den Code von libcomplex 1.1 enthält, und dass dieser Code unter Versionskontrolle steht. Oh, und wir wollen, dass das alles mit der geringsten Störung an der Versionskontroll-Historie passiert.

Nachdem wir den 1.0 Code mit dem 1.1 Code ersetzt haben, wird uns svn status sowohl Dateien mit lokalen Änderungen als auch einige unversionierte Dateien anzeigen. Wenn wir das getan haben, was wir tun sollten, sind die unversionierten Dateien nur die mit Version 1.1 von libcomplex hinzugekommenen neuen Dateien – wir rufen für diese svn add auf, um sie unter Versionskontrolle zu bringen. Falls der Code von 1.1 bestimmte Dateien nicht mehr beinhaltet, die noch im Baum von 1.0 vorhanden waren, kann es schwierig sein, sie zu identifizieren; Sie müssten die beiden Bäume mit einem externen Werkzeug vergleichen und dann mit svn delete Dateien entfernen, die in 1.0 jedoch nicht in 1.1 vorhanden sind. (Es könnte ebenso in Ordnung sein, diese Dateien ungenutzt beizubehalten!) Sobald letztendlich unsere Arbeitskopie von current nur den Code von libcomplex 1.1 enthält, übergeben wir die Änderungen, die uns hierher gebracht haben.

Unser current-Zweig enthält nun die neue Zulieferung. Wir erzeugen nun ein Tag 1.1 (genauso, wie wie es mit der Zulieferung 1.0 gemacht haben) und arbeiten dann die Unterschiede zwischen dem Tag der vorherigen Version und der neuen aktuellen Version in unseren Hauptentwicklungszweig ein:

$ cd working-copies/calc
$ svn merge http://svn.example.com/repos/vendor/libcomplex/1.0      \
            http://svn.example.com/repos/vendor/libcomplex/current  \
            libcomplex
… # alle Konflikte zwischen ihren und unseren Änderungen auflösen
$ svn commit -m 'merging libcomplex-1.1 into the main branch'
…

Im trivialen Fall würde die neue Version der Drittanbieter-Bibliothek aus der Datei- und Verzeichnisperspektive genau so aussehen wie die vorherige Version. Keine der libcomplex Dateien wäre gelöscht, umbenannt oder an einen anderen Ort verschoben worden – die neue Version würde gegenüber der vorherigen lediglich textuelle Änderungen enthalten. In einer vollkommenen Welt würden sich unsere Anpassungen sauber in die neue Version einfügen, ganz ohne Komplikationen oder Konflikte.

Allerdings gestalten sich die Dinge nicht immer so einfach, und tatsächlich ist es normal, dass sich Quelltext-Dateien zwischen Software-Veröffentlichungen verschieben. Das verkompliziert das Vorgehen, um sicherzustellen, dass unsere Anpassungen für die neue Version immer noch gültig sind, und es kann schnell passieren, dass wir in eine Situation gelangen, in der wir unsere Anpassungen manuell in die neue Version einpflegen müssen. Sobald Subversion die Geschichte einer gegebenen Quelltext-Datei kennt – inklusive aller früheren Orte – ist das Vorgehen des Einpflegens in eine neue Version der Bibliothek recht einfach. Allerdings sind wir dafür verantwortlich, Subversion mitzuteilen, wie sich die Organisation des Quelltextes zwischen den Zulieferungen geändert hat.

Zulieferungen, die mehr als ein paar Löschungen, Hinzufügungen und Verschiebungen beinhalten, verkomplizieren das Vorgehen bei der Aktualisierung auf neuere Versionen der Drittanbieter-Daten. Aus diesem Grund stellt Subversion das Skript svn_load_dirs.pl zur Verfügung, das Sie dabei unterstützt. Dieses Skript automatisiert die zum Importieren notwendigen Schritte, die wir beim Vorgehen zur allgemeinen Verwaltung von Lieferanten-Zweigen erwähnten, um zu gewährleisten, dass es dabei zu möglichst wenig Fehlern kommt. Sie werden zwar immer noch dafür verantwortlich sein, mit den Zusammenführungs-Befehlen die neuen Versionen der Drittanbieter-Daten in Ihren Hauptentwicklungszweig einzupflegen, jedoch kann Ihnen svn_load_dirs.pl dabei helfen, diesen Punkt schneller und leichter zu erreichen.

Kurz gesagt ist svn_load_dirs.pl eine Verbesserung von svn import mit folgenden wichtigen Eigenschaften:

svn_load_dirs.pl benötigt drei zwingend erforderliche Argumente. Das erste Argument ist der URL zum Basis-Subversion-Verzeichnis, in dem gearbeitet wird. Dieses Argument wird gefolgt von dem URL – relativ zum ersten Argument – wohin die aktuelle Zulieferung importiert werden soll. Schließlich gibt das dritte Argument an, aus welchem lokalen Verzeichnis importiert werden soll. In unserem vorigen Beispiel würde ein typischer Aufruf von svn_load_dirs.pl wie folgt aussehen:

$ svn_load_dirs.pl http://svn.example.com/repos/vendor/libcomplex \
                   current                                        \
                   /path/to/libcomplex-1.1
…

Sie können svn_load_dirs.pl mitteilen, dass Sie ein Tag von der neuen Zulieferung anlegen möchten, indem Sie die Option -t gefolgt von einem Tag-Namen übergeben. Dieser Tag-Name ist auch ein URL relativ zum ersten Argument des Programms.

$ svn_load_dirs.pl -t libcomplex-1.1                              \
                   http://svn.example.com/repos/vendor/libcomplex \
                   current                                        \
                   /path/to/libcomplex-1.1
…

Wenn Sie svn_load_dirs.pl aufrufen, untersucht es den Inhalt Ihre existierenden Zulieferung „current“ und vergleicht sie mit der vorgeschlagenen neuen Zulieferung. Im trivialen Fall werden keine Dateien ausschließlich in einer und nicht in der anderen Zulieferung vorhanden sein, so dass das Skript den Import ohne Probleme durchführt. Falls sich jedoch zwischen den Versionen Unterschiede in der Dateistruktur ergeben sollten, fragt svn_load_dirs.pl nach, wie die Unterschiede aufgelöst werden sollen. So haben Sie zum Beispiel die Möglichkeit, dem Skript mitzuteilen, dass die Datei math.c aus Version 1.0 von libcomplex in der Version 1.1 von libcomplex in arithmetic.c umbenannt wurde. Alle Diskrepanzen, die sich nicht durch Verschiebungen erklären lassen, werden als normale Löschungen und Hinzufügungen behandelt.

Das Skript akzeptiert auch eine gesonderte Konfigurationsdatei, in der Eigenschaften auf Dateien und Verzeichnisse gesetzt werden können, deren Name einem regulären Ausdruck entspricht und dem Projektarchiv hinzugefügt werden. Diese Konfigurationsdatei wird svn_load_dirs.pl mit der Option -p bekanntgegeben. Jede Zeile der Konfigurationsdatei ist eine durch Leerraum begrenzte Menge aus zwei oder vier Werten: ein regulärer Ausdruck wie in Perl, zu dem der entsprechende Pfad passen muss, ein Schlüsselwort zur Kontrolle (entweder break oder cont) und optional ein Eigenschafts-Name und ein Wert.

\.png$              break   svn:mime-type   image/png
\.jpe?g$            break   svn:mime-type   image/jpeg
\.m3u$              cont    svn:mime-type   audio/x-mpegurl
\.m3u$              break   svn:eol-style   LF
.*                  break   svn:eol-style   native

Für jeden hinzugefügten Pfad der dem regulären Ausdruck einer Zeile entspricht, werden die Eigenschafts-Änderungen der Reihe nach durchgeführt, es sei denn, das Kontroll-Schlüsselwort ist break (was bedeutet, dass keine weiteren Eigenschafts-Änderungen für diesen Pfad durchgeführt werden sollen). Falls das Kontroll-Schlüsselwort cont ist – eine Abkürzung für continue (fortfahren) – wird mit der nächsten Zeile der Konfigurationsdatei fortgefahren.

Jeglicher Leerraum im regulären Ausdruck, im Namen der Eigenschaft oder im Wert der Eigenschaft muss entweder mit einfachen oder doppelten Anführungszeichen umgeben werden. Anführungszeichen, die nicht zum Umfassen von Leerraum verwendet werden, können mit einem vorangestellten umgekehrten Schrägstrich (\) maskiert werden. Der umgekehrte Schrägstrich maskiert nur Anführungszeichen beim Lesen der Konfigurationsdatei, darum sollten Sie darüberhinaus keine weiteren Zeichen maskieren.