以前指摘したように、Subversion作業コピーのディレクトリのそれぞれは
.svn
という名前の特別のサブディレクトリを持ち、
そこに作業コピーディレクトリに関する管理情報を格納します。
Subversion は.svn
中の情報を以下のようなことを
記録するのに利用します:
どこにあるリポジトリが、作業コピーディレクトリのファイルやサブディレクトリ によって表現されているのか。
どのリビジョンのファイルやディレクトリが現在の作業コピーに あるのか。
ファイルやディレクトリに結びついたユーザ定義の属性。
作業コピーファイルの修正元(編集前)コピー。
.svn
ディレクトリに格納されたデータには
ほかにもいろいろありますが、最も重要なアイテムのいくつかだけに
ついて説明します。
.svn
ディレクトリにある一番重要な
ファイルはentries
ファイルです。
このファイルはXMLドキュメントでその内容は作業コピーディレクトリ中の
バージョン管理下にあるリソースについての管理情報のあつまりです。
リポジトリURL、修正元リビジョン、ファイルのチェックサム、修正元
テキストと属性のタイムスタンプ、予告と衝突状態に関する情報、最後に
コミットしたことに関する情報(実行者、リビジョン、タイムスタンプ)、
ローカルコピー履歴—Subversionクライアントが管理しているリソース
について興味のある情報はすべてここに記録されています。
以下は、実際のentries ファイルの例です:
例8.4 典型的な.svn/entries
ファイル
<?xml version="1.0" encoding="utf-8"?> <wc-entries xmlns="svn:"> <entry committed-rev="1" name="" committed-date="2005-04-04T13:32:28.526873Z" url="http://svn.red-bean.com/repos/greek-tree/A/D" last-author="jrandom" kind="dir" uuid="4e820d15-a807-0410-81d5-aa59edf69161" revision="1"/> <entry name="lambda" copied="true" kind="file" copyfrom-rev="1" schedule="add" copyfrom-url="http://svn.red-bean.com/repos/greek-tree/A/B/lambda"/> <entry committed-rev="1" name="gamma" text-time="2005-12-11T16:32:46.000000Z" committed-date="2005-04-04T13:32:28.526873Z" checksum="ada10d942b1964d359e048dbacff3460" last-author="jrandom" kind="file" prop-time="2005-12-11T16:32:45.000000Z"/> <entry name="zeta" kind="file" schedule="add" revision="0"/> <entry name="G" kind="dir"/> <entry name="H" kind="dir" schedule="delete"/> </wc-entries>
わかるように、entries ファイルは本質的にはエントリのリストです。
entry
タグのそれぞれは三つのうちのどれかを
表現しています: 作業コピーディレクトリ自身
(「this directory」エントリと呼ばれ、name
属性が空の値であるものとして示されています)、その作業コピーディレクトリ
にあるファイル(kind
属性が"file"
に設定されているものとして示されています)、あるいは
作業コピーのサブディレクトリ(kind
がここでは
"dir"
に設定されます)。エントリがこのファイルに格納される
ファイルとサブディレクトリは既にバージョン管理下にあるか(上の例の
zeta
ファイルのように)、この作業コピー
ディレクトリの変更が次にコミットされるときにバージョン管理下に
追加することが予告されているか、です。エントリのそれぞれは
ユニークな名前を持ち、特定のノード種別を持ちます。
開発者は、Subversion がentries
ファイルを
読み書きするときに使う特別の規則に注意すべきです。
すべてのエントリは自分のリビジョンと、結びついているURLを
持っていますが、サンプルファイル中のすべてのentry
タグが明示的なrevision
や
url
属性を持つわけではありません。
Subversion はエントリが明示的にこの二つの属性を持たないことも
認めていますが、それは、その値が、"svn:this-dir"
エントリにあるデータと同じか、簡単に計算できる場合です。
[45]
また、サブディレクトリのエントリについては、Subversion は
重要な属性—名前、種別、url、リビジョン、そして予告状況
のみを保存するということに注意してください。重複する情報を
減らすために、Subversion は、サブディレクトリに関する完全な情報
を決定する方法として、そのサブディレクトリに下りていき、その
ディレクトリ自身の.svn/entries
ファイルの
"svn:this-dir"
エントリを読むように指示します。
しかし、サブディレクトリへの参照は、その親の
entries
ファイルに記録されていて、サブディレクトリ
がディスクから削除されてしまったような場合でも基本的なバージョン管理
操作をするのには十分な情報を持っています。
前に注意したように、.svn
ディレクトリはまた
修正元の「text-base」バージョンのファイルを保存しています。
これは.svn/text-base
にあります。修正元
コピーの利点は、いくつかあります。—ネットワークの通信なしに
ローカル修正をチェックして差分を報告したり、ネットワーク通信なしに
修正したり削除したファイルを元に戻したり、サーバへの変更点の送信
サイズを減らしたりできます—しかし、少なくともそれぞれの
バージョン管理されたファイルを二つディスク上に保存するコストが
発生します。最近では、これはほとんどのファイルについて無視できる程度の
ものです。しかし、バージョン管理されたファイルが大きくなるにつれ
この状況はひどいことになっていきます。「text-base」
をオプションにしては、という意見もあります。
しかし皮肉にも、バージョン管理するファイルのサイズが大きくなるに
つれて、「text-base」の存在も、それだけ重要になっていきます—
ファイルにしたほんの少しの変更をコミットしたいだけなのに、ばかでかい
ファイルをネットワーク越しに送ろうなんて、誰が考えるでしょう?
「text-base」ファイルと同じような目的で、属性ファイルと、その修正元
「prop-base」コピーがあります。それぞれ、.svn/props
と.svn/prop-base
にあります。
ディレクトリも属性を持つことができるので、
.svn/dir-props
と
.svn/dir-prop-base
ファイルがあります。
これらの属性ファイルのそれぞれ(「作業中」と「元の」バージョン)は
属性名と属性値を格納するのに、単純な「ディスク上ハッシュ」ファイル形式
を使います。