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 übertragene Änderung von foo.c an

$ svn log -r HEAD 
# gibt die Protokollnachricht der letzten Übertragung 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 Übertragungs-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 Versions-Kontroll-Systems, 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.

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

	Anmerkung
	Beachten Sie, dass es die meisten Shells erforderlich machen, mindestens Leerzeichen in Anführungsstriche zu setzen oder anderweitig zu maskieren, wenn sie Teile von Revisionsdaten-Spezifizierungen sind. Bestimmte Shells könnten auch Probleme mit der unmaskierten Verwendung von geschweiften Klammern bekommen. Schlagen Sie in der Dokumentation Ihrer Shell nach, was in Ihrer Umgebung notwendig ist.

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 (Mo, 27. Nov 2006) | 6 Zeilen
…

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

Die Fähigkeit von Subversion, Revisionsdaten in Revisionsnummern überführen zu können, beruht auf einer sequentiellen Ordnung der Revisions-Datumsstempel – je jünger die Revision, desto jünger der Datumsstempel. Da Datumsstempel jedoch in der unversionierten, änderbaren svn:date-Eigenschaft einer Revision gespeichert werden (siehe „Eigenschaften“), können Revisions-Datumsstempel aus der Reihenfolge geraten. Die meisten Operationen von Subversion jedoch bekommen davon nichts mit – schließlich ist die Versionsnummer an sich das primäre Unterscheidungsmerkmal jeder Revision. Falls die Reihenfolge der Datumsstempel jedoch 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. Die Verschmelzung von Historien mehrerer Projektarchive in ein einzelnes (wie unter „Projektarchiv-Daten woanders hin verschieben“ beschrieben) ist der häufigste Ursache für dieses Szenario.