本手册旨在描述 Subversion 1.1。如果您正在运行更新版本的 Subversion，我们强烈建议您访问 https://svnbooks.subversion.org.cn/ 并参考适用于您的 Subversion 版本的本手册版本。
如前所述，每个 Subversion 工作副本目录都包含一个名为.svn的特殊子目录，其中包含有关该工作副本目录的管理数据。Subversion 使用.svn中的信息来跟踪以下内容：
工作副本目录中的文件和子目录所代表的存储库位置。
当前工作副本中每个文件和目录的版本。
可能附加到这些文件和目录的任何用户定义属性。
工作副本文件的原始（未编辑）副本。
虽然.svn目录中存储了其他一些数据，但我们将仅检查其中两个最重要的项目。
也许.svn目录中最重要的文件是entries文件。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="2002-09-24T17:12:44.064475Z" url="http://svn.red-bean.com/tests/.greek-repo/A/D" kind="dir" revision="1"/> <entry committed-rev="1" name="gamma" text-time="2002-09-26T21:09:02.000000Z" committed-date="2002-09-24T17:12:44.064475Z" checksum="QSE4vWd9ZM0cMvr7/+YkXQ==" kind="file" prop-time="2002-09-26T21:09:02.000000Z"/> <entry name="zeta" kind="file" schedule="add" revision="0"/> <entry url="http://svn.red-bean.com/tests/.greek-repo/A/B/delta" name="delta" 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的文件）计划在用户下次提交此工作副本目录的更改时添加到版本控制中。每个条目都有一个唯一的名称，并且每个条目都有一个节点类型。
开发人员应注意 Subversion 在读取和写入其entries文件时使用的一些特殊规则。虽然每个条目都有与其关联的版本和 URL，但请注意，并非样本文件中的每个entrytag 都具有显式的 revision 或 url 属性附加到它。当这些值的含义与（在 revision 的情况下）或从 [38] （在 url 的情况下）存储在“此目录”条目中的数据中可轻易计算得出时，Subversion 允许条目不显式存储这两个属性。还要注意，对于子目录条目，Subversion 只存储关键属性——名称、类型、URL、版本和调度。为了减少重复信息，Subversion 规定确定有关子目录的完整信息集的方法是向下遍历到该子目录，并从其自己的.svn/entries文件读取“此目录”条目。但是，对子目录的引用保留在其父级的entries文件中，其中包含足够的信息以允许基本版本控制操作，以防子目录本身实际上从磁盘中丢失。
如前所述，.svn目录还保存文件的原始“文本基准”版本。这些版本可以在.svn/text-base中找到。这些原始副本的好处很多——无网络本地修改检查和差异报告、无网络修改或丢失文件的还原、更改到服务器的传输量更小——但需要以在磁盘上至少两次存储每个版本化文件的代价为代价。如今，对于大多数文件来说，这似乎是一个可以忽略不计的惩罚。然而，随着版本化文件大小的增长，这种情况变得更加糟糕。有人正在关注让“文本基准”的存在成为一个选项。具有讽刺意味的是，随着版本化文件的大小变得越来越大，“文本基准”的存在变得更加重要——谁愿意仅仅因为想要对它进行微小的更改而跨网络传输一个巨大的文件？
与“文本基准”文件类似的是属性文件及其原始“prop-base”副本，它们分别位于.svn/props和.svn/prop-base中。由于目录也可以具有属性，因此还有.svn/dir-props和.svn/dir-prop-base文件。这些属性文件中的每一个（“工作”和“基准”版本）都使用一个简单的“磁盘上的哈希”文件格式来存储属性名称和值。