Dieser Text befindet sich gegenwärtig in Bearbeitung, unterliegt ständigen Änderungen und kann dadurch nicht stets akkurat irgendeine freigegebene Version der Software Apache™ Subversion® beschreiben. Das Speichern dieser Seite als Lesezeichen oder andere auf diese Seite zu verweisen, ist keine so gute Idee. Besuchen Sie http://www.svnbook.com/, um stabile Versionen dieses Buchs zu erhalten.

Versionskontrolle nach Art von Subversion

Wir haben bereits erwähnt, dass Subversion ein modernes, netzbewusstes Versions-Kontroll-System. Wie wir in „Grundlagen der Versionskontrolle“ beschrieben haben (unser Versions-Kontroll-Überblick auf hoher Ebene), dient ein Projektarchiv als Kern-Speichermechanismus für die versionierten Daten von Subversion, und über Arbeitskopien kommunizieren Anwender und ihre Software mit diesen Daten. In diesem Abschnitt werden wir damit beginnen, die besonderen Vorgehensweisen von Subversion bei der Implementierung von Versionskontrolle vorzustellen.

Subversion Projektarchive

Subversion implementiert das Konzept eines Projektarchivs für Versionskontrolle so, wie es jedes andere moderne Versions-Kontroll-System auch machen würde. Im Gegensatz zu einer Arbeitskopie ist ein Subversion-Projektarchiv ein abstraktes Gebilde, das sich fast ausschließlich über die eigenen Subversion-Bibliotheken und -Werkzeuge manipulieren lässt. Da die meisten Interaktionen eines Anwenders mit Subversion die Benutzung des Subversion-Clients einbeziehen und im Kontext einer Arbeitskopie vollzogen werden, wird sich ein großer Teil dieses Buches mit dem Subversion-Projektarchiv und dessen Bearbeitung beschäftigen. Für die Feinheiten des Projektarchivs, siehe allerdings Kapitel 5, Verwaltung des Projektarchivs.

[Warnung] Warnung

In Subversion wird das client-seitige Objekt, über das jeder Anwender verfügt – das Verzeichnis mit versionierten Dateien zusammen mit Metadaten, die dem System erlauben, erstere zu überwachen und mit dem Server zu kommunizieren – eine Arbeitskopie genannt. Obwohl andere Versions-Kontroll-Systeme den Begriff Projektarchiv (Repository) für das client-seitige Objekt verwenden, ist es sowohl falsch als auch eine verbreitete Quelle für Missverständnisse, den Begriff in diesem Sinn im Kontext von Subversion zu verwenden.

Arbeitskopien werden später in „Subversion-Arbeitskopien“ beschrieben.

Revisionen

Ein Subversion-Client übergibt eine (d.h., übermittelt die Änderungen an einer) beliebigen Anzahl von Dateien und Verzeichnissen als eine einzige atomare Transaktion. Eine atomare Transaktion bedeutet: entweder es gehen alle Änderungen in das Projektarchiv oder keine. Angesichts von Programm- und Systemabstürzen, Netzproblemen oder anderer Anwenderaktionen hält Subversion an dieser Atomizität fest.

Jedes Mal wenn das Projektarchiv eine Übertragung 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.6, „Änderungen am Baum im Verlauf der Zeit“ 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 einer Übertragung ist.

Abbildung 1.6. Änderungen am Baum im Verlauf der Zeit

Änderungen am Baum im Verlauf der Zeit

Projektarchive adressieren

Subversion-Client-Programme verwenden 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.

  • http://svn.example.com/svn/project
  • http://svn.example.com:9834/repos

Die Subversion-Projektarchiv-URLs sind nicht beschränkt auf den Typ http://. Da Subversion mehrere unterschiedliche Kommunikationswege zwischen seinen Clients und Servern anbietet, unterscheiden sich die zur Adressierung des Projektarchivs verwendeten URLs auf eine subtile Art, abhängig davon, welcher Zugriffsmechanismus zum Projektarchiv angewendet werden soll. Tabelle 1.1, „Projektarchiv-Zugriffs-URLs“ beschreibt, wie unterschiedliche URL Schemata auf die verfügbaren Zugriffsmethoden abgebildet werden. Details über die Serveroptionen von Subversion finden Sie unter Kapitel 6, Konfiguration des Servers.

Tabelle 1.1. Projektarchiv-Zugriffs-URLs

Schema Zugriffsmethode
file:/// Direkter Zugriff auf das Projektarchiv (auf lokaler Platte)
http:// Zugriff über das WebDAV-Protokoll auf Apache-Server, die Subversion abhandeln können
https:// Wie http://, jedoch mit SSL-Einbindung (Verschlüsselung und Authentifizierung).
svn:// Zugriff über ein besonderes Protokoll auf einen svnserve-Server
svn+ssh:// Wie svn://, jedoch über einen SSH-Tunnel

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:

  • file:///var/svn/repos
  • 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:

  • file:///X:/var/svn/repos
  • file:///X|/var/svn/repos

Beachten Sie, dass ein URL Schrägstriche verwendet, selbst wenn die übliche (nicht-URL) Form eines Pfades unter Windows rückwärtige Schrägstriche verwendet. Beachten Sie ebenfalls, bei der Verwendung des Formats file:///X|/ den URL in Anführungsstriche einzuschließen, damit der senkrechte Strich nicht als Pipe-Symbol interpretiert wird.

[Anmerkung] 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.

Der Subversion-Client wandelt URLs nach Bedarf automatisch um, wie es auch ein Web-Browser macht. So wird beispielsweise der URL http://host/path with space/project/españa – der sowohl Leerzeichen als auch Zeichen aus dem höheren ASCII-Bereich enthält – automatisch von Subversion so interpretiert als ob sie http://host/path%20with%20space/project/espa%C3%B1a geschrieben hätten. Falls der URL Leerzeichen enthält, stellen Sie sicher, ihn auf der Kommandozeile in Anführungszeichen zu setzen, so dass Ihre Shell alles als ein einzelnes Argument für das Programm behandelt.

Es gibt eine erwähnenswerte Ausnahme von der Regel, wie Subversion URLs behandelt, die in vielen Kontexten auch auf die Behandlung lokaler Pfade anwendbar ist. Falls die letzte Pfadkomponente des URL oder lokalen Pfades einen Klammeraffen (@) enthält, müssen Sie eine besondere Syntax verwenden – in „Peg- und operative Revisionen“ beschrieben – damit Subversion diese Ressource passend ansprechen kann.

In Subversion 1.6 wurde eine neue Notation mit Zirkumflex (^) als Kurzschreibweise für der URL des Wurzelverzeichnisses des Projektarchivs eingeführt. Sie können beispielsweise ^/tags/bigsandwich/ verwenden, um sich auf den URL des Verzeichnisses /tags/bigsandwich im Wurzelverzeichnis des Projektarchivs zu beziehen. Beachten Sie, dass dieser URL nur dann funktioniert, wenn Ihre aktuelles Arbeitsverzeichnis eine Arbeitskopie ist – der Kommandozeilen-Client kennt den URL des Projektarchiv-Wurzelverzeichnisses, da er sich die Metadaten der Arbeitskopie ansieht. Beachten Sie auch, dass Sie ^/ statt nur ^ verwenden (mit dem abschließenden Schrägstrich), wenn Sie sich auf das Wurzelverzeichnis des Projektarchivs beziehen möchten. Anwender von Windows sollten nicht vergessen, dass ein Zirkumflex auf ihrer Plattform zu den Fluchtsymbolen gehört. Deshalb sollten Sie einen doppelten Zirkumflex verwenden ^^, falls Sie den Subversion-Client auf einem Windows-Rechner verwenden.

Subversion-Arbeitskopien

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 für die 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 eigenes Arbeitsverzeichnis einzupflegen (indem es aus dem Projektarchiv liest). Beachten Sie, dass das zentrale Projektarchiv der Makler für die änderungen aller in Subversion ist – im typischen Arbeitsablauf werden Änderungen nicht direkt von Arbeitskopie zu Arbeitskopie weitergegeben.

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 jede Arbeitskopie ein Unterverzeichnis namens .svn, auch bekannt als das Verwaltungsverzeichnis der Arbeitskopie. Die Dateien in jedem Verwaltungsverzeichnis helfen Subversion dabei, zu erkennen, welche Ihrer versionierten Dateien unveröffentlichte Änderungen enthalten und welche Dateien hinsichtlich der Arbeit anderer veraltet sind.

[Anmerkung] Anmerkung

Vor Version 1.7 unterhielt Subversion administrative .svn-Unterverzeichnisse in jedem versionierten Verzeichnis Ihrer Arbeitskopie. Subversion 1.7 bietet einen völlig neuen Ansatz für die Speicherung und Verwaltung von Metadaten der Arbeitskopie; der sichtbarste Unterschied ist, dass jede Arbeitskopie nur ein .svn Unterverzeichnis als unmittelbares Kind des Wurzelverzeichnisses der Arbeitskopie besitzt.

Wie die Arbeitskopie funktioniert

Für jede Datei eines Arbeitsverzeichnis merkt sich Subversion (neben anderen Dingen) zwei essentielle Informationen:

  • Auf welcher Revision Ihre Arbeitsdatei aufbaut (das wird die Arbeitsrevision der Datei genannt)

  • Ein Zeitstempel, der festhält, wann die lokale Kopie das letzte Mal vom Projektarchiv aktualisiert wurde.

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

Unverändert und aktuell

Die Datei im Arbeitsverzeichnis ist unverändert, und keinerlei Änderungen an der Datei sind seit der Arbeitsrevision an das Projektarchiv übertragen worden. Ein svn commit der Datei würde nichts machen, und ein svn update der Datei auch nicht.

Lokal geändert und aktuell

Die Datei wurde im Arbeitsverzeichnis geändert, und keinerlei Änderungen an der Datei sind seit der letzten Aktualisierung an das Projektarchiv übertragen worden. Es gibt lokale Änderungen, die noch nicht an das Projektarchiv übertragen worden sind, so dass ein svn commit der Datei Ihre Änderungen erfolgreich veröffentlichen würde, und ein svn update der Datei nichts tun würde.

Unverändert und veraltet

Die Datei wurde im Arbeitsverzeichnis nicht geändert, jedoch im Projektarchiv. Die Datei sollte aktualisiert werden, damit sie bezüglich der letzten öffentlichen Revision aktuell ist. Ein svn commit der Datei würde nichts machen, und ein svn update der Datei würde die letzten Änderungen in Ihre Arbeitskopie einbringen.

Lokal geändert und veraltet

Die Datei wurde sowohl im Arbeitsverzeichnis als auch im Projektarchiv geändert. Ein svn commit der Datei würde mit einem out-of-date Fehler abbrechen. Die Datei sollte erst aktualisiert werden; ein svn update Befehl würde versuchen, die öffentlichen mit den lokalen Änderungen zusammenzuführen. Wenn Subversion diese Zusammenführung nicht plausibel automatisch durchführen kann, wird die Auflösung des Konflikts dem Benutzer überlassen.

Grundlegende Interaktionen der Arbeitskopie

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.7, „Das Dateisystem des Projektarchivs“ dargestellt.

Abbildung 1.7. Das Dateisystem des Projektarchivs

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 Arbeitskopie 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 "Fixed a typo in button.c." 
Sende          button.c
Übertrage Daten .
Revision 57 ü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 übertragen, 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 übertragen wurden seit sie ausgecheckt hatte in ihre Arbeitskopie.

$ pwd
/home/sally/calc
$ ls -A
Makefile button.c integer.c .svn/
$ svn update 
Aktualisiere ».«:
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.

Arbeitskopien mit gemischten Revisionen

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. Subversions Arbeitskopien entsprechen nicht jederzeit einer einzigen Revision des Projektarchivs; sie können Dateien aus mehreren unterschiedlichen Revisionen enthalten. 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 einer Übertragung ins Projektarchiv. Angenommen, dass keine weiteren Übertragungen vorgenommen wurden, wird Ihre Übertragung 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 eine Übertragung 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.

Aktualisierungen und Übertragungen sind getrennt

Eine der grundlegenden Regeln von Subversion ist, dass eine Aktion, die in das Projektarchiv schreibt keine Aktion zur Folge hat, die aus dem Projektarchiv liest und umgekehrt. Wenn Sie bereit sind, neue Änderungen an das Projektarchiv zu übertragen, heißt das noch lange nicht, dass Sie auch die Änderungen anderer haben möchten. Und wenn Sie noch an Änderungen arbeiten, sollte svn update elegant die Änderungen aus dem Projektarchiv mit Ihren Änderungen zusammenführen anstatt Sie dazu zu zwingen, Ihre Änderungen zu veröffentlichen.

Der hauptsächliche Nebeneffekt dieser Regel ist, dass eine Arbeitskopie zusätzlich buchhalten muss, um sowohl gemischte Revisionen zu verfolgen als auch diese Mischung vertragen zu können. Die Tatsache, dass auch Verzeichnisse selbst versioniert sind, verkompliziert die Sache nur.

Nehmen wir zum Beispiel an, Ihre Arbeitskopie besteht komplett aus Revision 10, während andere ihre Änderungen übertragen haben, so dass die jüngste Revision im Projektarchiv nun Revision 14 ist. Sie bearbeiten die Datei foo.html und führen ein svn commit aus, das die Revision 15 im Projektarchiv erzeugt. Nach der erfolgreichen Übertragung würden viele neue Benutzer erwarten, dass die gesamte Arbeitskopie auf Revision 15 stehe, was aber nicht der Fall ist! Alle möglichen Änderungen können sich zwischen Revision 10 und 15 im Projektarchiv zugetragen haben. Der Client weiß nichts über diese Änderungen im Projektarchiv, da Sie noch nicht svn update aufgerufen haben, und svn commit zieht keine Änderungen herein. Wenn andererseits svn commit automatisch Änderungen hereinziehen würde, könnte die gesamte Arbeitskopie auf Revision 15 gebracht werden – doch dann wäre die grundlegende Regel verletzt, dass Lesen und Schreiben getrennte Aktionen sind. Deshalb ist das einzig Sichere, das der Subversion-Client tun kann, die eine Datei – foo.html – als zur Revision 15 gehörig zu kennzeichnen. Der Rest der Arbeitskopie verbleibt bei Revision 10. Nur durch svn update können die neuesten Änderungen hereingezogen und die gesamte Arbeitskopie als Revision 15 gekennzeichnet werden.

Gemischte Revisionen sind normal

Tatsache ist, dass jedes Mal wenn Sie svn commit aufgerufen haben, die Arbeitskopie aus irgendeiner Mischung von Revisionen besteht. Die Sachen, die Sie eben ins Projektarchiv gebracht haben, werden mit höheren Revisionsnummern gekennzeichnet als alles andere. Nach einigen Übertragungen (ohne zwischenzeitliche Updates) ist Ihre Arbeitskopie eine Riesenmischung von Revisionen. Selbst wenn Sie die einzige Person sind, die das Projektarchiv benutzt, werden sie dieses Phänomen bemerken. Um Ihre Mischung aus Arbeitsrevisionen untersuchen zu können, verwenden Sie den Befehl svn status mit der Option --verbose (-v; siehe „Verschaffen Sie sich einen Überblick über Ihre Änderungen“ für weitergehende Informationen).

Oft ist neuen Benutzern überhaupt nicht bewusst, das ihre Arbeitskopie gemischte Revisionen beinhaltet. Das kann zur Verwirrung führen, weil viele Client-Programme empfindlich auf die Revision des Objektes reagieren, das sie untersuchen. Beispielsweise wird der svn log-Befehl verwendet, um die Historie der Änderungen einer Datei oder eines Verzeichnisses darzustellen (siehe „Erzeugung einer Liste der Änderungsgeschichte“). Wenn der Benutzer diesen Befehl auf ein Objekt in der Arbeitskopie anwendet, erwartet er, die gesamte Historie des Objektes zu sehen. Wenn jedoch die Arbeitsrevision des Objektes ziemlich alt ist (oftmals weil lange Zeit kein svn update aufgerufen wurde), wird die Historie der älteren Version des Objekts angezeigt.

Gemischte Revisionen sind nützlich

Wenn Ihr Projekt hinreichend komplex ist, werden Sie entdecken, dass es manchmal ganz nett sein kann, Teile Ihrer Arbeitskopie zurückzudatieren (oder auf eine ältere Version als die vorliegende zu aktualisieren); wie das gemacht wird, wird in Kapitel 2, Grundlegende Benutzung gezeigt. Vielleicht möchten Sie eine ältere Version eines Teilmoduls in einem Unterverzeichnis testen, oder Sie möchten herausbekommen, wann ein Fehler das erste Mal in einer Datei auftauchte. Dies ist der Zeitmaschinen-Aspekt eines Versions-Kontroll-Systems – die Eigenschaft, die es ermöglicht, irgendeinen Teil Ihrer Arbeitskopie zeitlich nach vorne oder nach hinten zu verschieben.

Gemischte Revisionen haben ihre Grenzen

Wie auch immer Sie gemischte Revisionen in Ihrer Arbeitskopie verwenden, diese Flexibilität hat ihre Grenzen.

Erstens kann die Löschung einer Datei oder eines Verzeichnisses nicht an das Projektarchiv übertragen werden, wenn die Datei oder das Verzeichnis nicht ganz aktuell ist. Falls eine neuere Version im Projektarchiv existiert, wird Ihr Löschversuch abgelehnt, um zu vermeiden, dass Sie versehentlich Änderungen löschen, die Sie noch nicht gesehen haben.

Zweitens können Sie keine Änderungen an Metadaten eines Verzeichnisses an das Projektarchiv übertragen, wenn das Verzeichnis nicht ganz aktuell ist. In Kapitel 3, Fortgeschrittene Themen werden Sie lernen, wie man Eigenschaften an Objekte hängt. Die Arbeitskopie eines Verzeichnisses definiert eine bestimmte Menge von Einträgen und Eigenschaften, so dass eine Eigenschafts-Änderung an einem veralteten Verzeichnis Eigenschaften zerstören kann, die Sie noch nicht gesehen haben.

Schließlich können Sie, beginnend mit Subversion 1.7, standardmäßig eine Arbeitskopie mit gemischten Revisionen als Ziel einer Zusammenführung verwenden. (Diese neue Anforderung wurde eingeführt, um daher rührende Probleme zu verhindern.)