像我们前面提到的，每个Subversion工作拷贝包含了一个特别的子目录叫做.svn，这个目录包含了关于工作拷贝目录的管理数据，Subversion使用.svn中的信息来追踪如下的数据：
工作拷贝中展示的目录和文件在版本库中的位置。
工作拷贝中当前展示的文件和目录的修订版本。
所有附加在文件和目录上的用户定义属性。
初始（未编辑）的工作拷贝文件的拷贝。
然而.svn目录中还有一些其他的数据，我们会考察一些最重要的项目。
或许.svn目录中最重要的单个文件就是entries了，这个条目文件是一个XML文档，包含了关于工作拷贝中的版本化的资源的大多数管理性信息，这个文件保留了版本库URL、原始修订版本、可知的最后提交信息（作者、修订版本和时间戳）和本地拷贝历史—实际上是Subversion客户端关于一个版本化（或者是将要版本化的）资源的所有感兴趣的信息！
如下是一个实际条目文件的例子：
例 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>
就像你能看到的，条目文件本质上是一列条目，每个entry标签代表了下面三者之一的事情：工作拷贝目录本身（叫做“本目录”条目，并且name属性的值为空），工作拷贝目录中的一个文件（通过kind属性设置为"file"来标示），或者是工作拷贝中的一个子目录（kind这时设置为"dir"）。所有在这个文件标记的文件和子目录都是已经纳入版本控制或者是（上面例子中的zeta）预定在下次提交加入到版本控制。每个条目都有一个唯一的名字，每个条目有一个kind节点。
开发者必须意识到一些Subversion读写entries文件的特殊规则，每个条目都有一个修订版本和URL与之关联，注意在上面实例文件中并不是每个entry标签都有明确的revision或url属性，Subversion允许一些情况不明确的说明这个两个属性，如属性值与“本目录”的值相同（revision的情况）或者是可以从“本目录”简单计算[46]出的来（url）。注意对于子目录条目，Subversion只保管最重要的信息—名称、类型、URL、修订版本和日程。为了减少重复信息，Subversion指示当要检测目录信息时会跑到这个子目录自己的.svn/entries的“本目录”条目。当然了，对这个子目录的引用还是会保存在父目录的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文件。所有的属性文件（“working”和“base”版本）都使用同样的“hash-on-disk”文件格式来排序属性名称和值。