As you saw in リビジョン項, revision numbers in Subversion are pretty straightforward—integers that keep getting larger as you commit more changes to your versioned data. Still, it doesn't take long before you can no longer remember exactly what happened in each and every revision. Fortunately, the typical Subversion workflow doesn't often demand that you supply arbitrary revisions to the Subversion operations you perform. For operations that do require a revision specifier, you generally supply a revision number that you saw in a commit email, in the output of some other Subversion operation, or in some other context that would give meaning to that particular number.
But occasionally, you need to pinpoint a moment in time for which you don't already have a revision number memorized or handy. So besides the integer revision numbers, svn allows as input some additional forms of revision specifiers—revision keywords, and revision dates.
The various forms of Subversion revision specifiers can be mixed and matched when used to specify revision ranges. For example, you can use -r
where REV1
:REV2
REV1
is a revision keyword and REV2
is a revision number, or where REV1
is a date and REV2
is a revision keyword, and so on. The individual revision specifiers are independently evaluated, so you can put whatever you want on the opposite sides of that colon.
The Subversion client understands a number of revision keywords. These keywords can be used instead of integer arguments to the --revision (-r)
switch, and are resolved into specific revision numbers by Subversion:
リポジトリにある最新のリビジョンです。
作業コピーにあるファイル、ディレクトリの、「修正元」リビジョン です。
ファイル、ディレクトリが変更されたBASE
以前の(または BASE
リビジョンを含む)最後のリビジョンです。
The revision immediately before the last revision in which an item changed. Technically, this boils down to COMMITTED
-1.
As can be derived from their descriptions, the PREV
, BASE
, and COMMITTED
revision keywords are used only when referring to a working copy path—they don't apply to repository URLs. HEAD
, on the other hand, can be used in conjunction with both of these path types.
Here are some examples of revision keywords in action:
$ svn diff -r PREV:COMITTED foo.c # foo.c にコミットした最後の変更を表示 $ svn log -r HEAD # 最後のリポジトリへのコミットで付けたログメッセージを表示 $ svn diff -r HEAD # 作業コピー内の (ローカルで変更された) ファイルを、リポジトリの最新バージョンと比較 $ svn diff -r BASE:HEAD foo.c # 修正前の foo.c とリポジトリの最新バージョンの foo.c とを比較 $ svn log -r BASE:HEAD # 最後に更新した後のすべてのコミットログを表示 $ svn update -r PREV foo.c # foo.c の最後の変更をもとに戻す # (foo.c の作業リビジョン番号は減少する) $ svn diff -r BASE:14 foo.c # 修正前の foo.c と リビジョン 14 にある foo.c とを比較
Revision numbers reveal nothing about the world outside the version control system, but sometimes you need to correlate a moment in real time with a moment in version history. To facilitate this, the --revision (-r)
option can also accept as input date specifiers wrapped in curly braces ({
and }
). Subversion accepts the standard ISO-8601 date and time formats, plus a few others. Here are some examples. (Remember to use quotes around any date that contains spaces.)
$ 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} …
When you specify a date, Subversion resolves that date to the most recent revision of the repository as of that date, and then continues to operate against that resolved revision number:
$ svn log -r {2006-11-28} ------------------------------------------------------------------------ r12 | ira | 2006-11-27 12:31:51 -0600 (Mon, 27 Nov 2006) | 6 lines …
日付範囲を使うこともできます。 Subversionは両方の日付の間にあるすべてのリビジョンを検索対象と します。両端の日付は検索に含みます:
$ svn log -r {2006-11-20}:{2006-11-29} …
Since the timestamp of a revision is stored as an unversioned, modifiable property of the revision (see 属性項, revision timestamps can be changed to represent complete falsifications of true chronology, or even removed altogether. Subversion's ability to correctly convert revision dates into real revision numbers depends on revision datestamps maintaining a sequential ordering—the younger the revision, the younger its timestamp. If this ordering isn't maintained, you will likely find that trying to use dates to specify revision ranges in your repository doesn't always return the data you might have expected.