本文档是为了描述 Subversion 1.4 而编写的。如果您正在运行更新版本的 Subversion，我们强烈建议您访问 https://svnbook.subversion.org.cn/ 并查阅适合您 Subversion 版本的本书版本。
正如我们之前提到的，Subversion 工作副本的每个目录都包含一个名为 .svn 的特殊子目录，其中存放着有关该工作副本目录的管理数据。Subversion 使用 .svn 中的信息来跟踪以下内容：
工作副本目录中的文件和子目录所代表的存储库位置。
当前工作副本中每个文件和目录的修订版本。
可能附加到这些文件和目录的任何用户定义的属性。
工作副本文件的原始（未编辑）副本。
Subversion 工作副本管理区域的布局和内容被认为是实现细节，并非真正用于人类消费。鼓励开发人员使用 Subversion 的公共 API 或 Subversion 提供的工具来访问和操作工作副本数据，而不是直接读取或修改这些文件。工作副本库为其管理数据采用的文件格式会不时更改，而公共 API 在很大程度上隐藏了这一点，从而使普通用户免受困扰。在本节中，我们公开了一些这些实现细节，纯粹是为了满足您强烈的求知欲。
也许 .svn 目录中最重要的文件是 entries 文件。它包含有关工作副本目录中版本化项目的大部分管理信息。正是这一个文件跟踪了存储库 URL、原始修订版本、文件校验和、原始文本和属性时间戳、调度和冲突状态信息、最后已知的提交信息（作者、修订版本、时间戳）、本地副本历史记录，实际上是 Subversion 客户端想要了解有关版本化（或即将版本化）资源的任何信息！
熟悉 CVS 管理目录的人会注意到，Subversion 的 .svn/entries 文件充当了 CVS 的 CVS/Entries、CVS/Root 和 CVS/Repository 文件的组合。
.svn/entries 文件的格式随着时间的推移而发生了变化。最初是一个 XML 文件，现在使用的是自定义格式，虽然仍然是人类可读的。虽然 XML 对 Subversion 的早期开发者来说是一个不错的选择，因为他们经常调试文件的内容（以及 Subversion 在这些内容下的行为），但随着 Subversion 的成熟，对易于开发人员调试的需求已减少，取而代之的是用户对更快性能的需求。请注意，Subversion 的工作副本库会自动将工作副本从一种格式升级到另一种格式——它会读取旧格式，并写入新格式——这可以省去您签出新工作副本的麻烦，但也可能使不同版本的 Subversion 尝试使用同一工作副本的情况变得复杂。
如前所述，.svn 目录还保存着文件的原始“文本基础”版本。这些可以在 .svn/text-base 中找到。这些原始副本的好处很多——无需网络即可检查本地修改和差异报告、无需网络即可恢复修改或丢失的文件、更有效地将更改传输到服务器——但代价是每个版本化的文件至少要存储两次磁盘。如今，对于大多数文件来说，这似乎是一个可以忽略不计的代价。但是，随着版本化文件大小的增长，这种情况变得更加糟糕。有些人正在考虑让“文本基础”的存在成为一个选项。具有讽刺意味的是，随着版本化文件大小的增长，“文本基础”的存在变得更加重要——谁愿意为了提交对文件的一点微小更改而将一个巨大的文件传输到网络上呢？
与“文本基础”文件目的类似的是属性文件及其原始“prop-base”副本，分别位于 .svn/props 和 .svn/prop-base 中。由于目录也可以拥有属性，因此也存在 .svn/dir-props 和 .svn/dir-prop-base 文件。