以前指摘したように、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" エントリにあるデータと同じか、簡単に計算できる場合です。 [44] また、サブディレクトリのエントリについては、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 ファイルがあります。 これらの属性ファイルのそれぞれ(「作業中」と「元の」バージョン)は 属性名と属性値を格納するのに、単純な「ディスク上ハッシュ」ファイル形式 を使います。