.svn ディレクトリにある一番重要な ファイルはentries ファイルです。 このファイルはXMLドキュメントでその内容は作業コピーディレクトリ中の バージョン管理下にあるリソースについての管理情報のあつまりです。 リポジトリURL、修正元リビジョン、ファイルのチェックサム、修正元 テキストと属性のタイムスタンプ、予告と衝突状態に関する情報、最後に コミットしたことに関する情報(実行者、リビジョン、タイムスタンプ)、 ローカルコピー履歴—Subversionクライアントが管理しているリソース について興味のある情報はすべてここに記録されています。

以下は、実際の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 ファイルがあります。 これらの属性ファイルのそれぞれ(「作業中」と「元の」バージョン)は 属性名と属性値を格納するのに、単純な「ディスク上ハッシュ」ファイル形式 を使います。