作業コピー管理領域の内部

以前指摘したように、Subversion作業コピーのディレクトリのそれぞれは .svn という名前の特別のサブディレクトリを持ち、 そこに作業コピーディレクトリに関する管理情報を格納します。 Subversion は.svn 中の情報を以下のようなことを 記録するのに利用します:

.svn ディレクトリに格納されたデータには ほかにもいろいろありますが、最も重要なアイテムのいくつかだけに ついて説明します。

Entries ファイル

.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 タグが明示的なrevisionurl 属性を持つわけではありません。 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 ファイルがあります。 これらの属性ファイルのそれぞれ(作業中元のバージョン)は 属性名と属性値を格納するのに、単純なディスク上ハッシュファイル形式 を使います。




[45] つまり、エントリのURLは親ディレクトリURLと エントリ名称をつなげたものと同じとみなすということです。