虽然 Subversion 允许您在不丢失任何信息的情况下移动版本化的文件和目录，甚至提供将整个版本化历史记录集从一个仓库移动到另一个仓库的方法，但这样做可能会极大地破坏经常访问仓库并期望事物位于特定位置的人的工作流程。因此，在创建新仓库之前，请尝试展望未来；在将数据置于版本控制之下之前，请提前计划。通过有意识地 “布局” 您的仓库或仓库及其版本化的内容，您可以避免许多未来的麻烦。

让我们假设您作为仓库管理员，将负责为多个项目提供版本控制系统支持。您的第一个决定是使用单个仓库来存储多个项目，还是为每个项目提供一个单独的仓库，或者在这两者之间进行一些折衷。

为多个项目使用单个仓库有很多好处，最明显的是没有重复维护。单个仓库意味着只有一套钩子程序，一个需要定期备份的东西，一个需要在 Subversion 发布不兼容的新版本时进行转储和加载的东西，等等。此外，您可以在项目之间轻松移动数据，而不会丢失任何历史版本信息。

使用单一仓库的缺点是，不同的项目可能对仓库事件触发器有不同的需求，例如需要将提交通知邮件发送到不同的邮件列表，或者对构成合法提交的定义不同。当然，这些问题并非不可克服——只是意味着所有钩子脚本都必须对仓库的布局敏感，而不是假设整个仓库都与单一组人员相关联。此外，请记住，Subversion 使用仓库全局修订号。虽然这些数字没有特别的魔力，但有些人仍然不喜欢这样一个事实，即使他们的项目最近没有进行任何更改，仓库的最新修订号也会不断增加，因为其他项目正在积极添加新的修订版本。^[39]

也可以采用折中的方法。例如，可以根据项目之间的关联程度对项目进行分组。您可以在每个仓库中拥有几个仓库，其中包含少量项目。这样，可能需要共享数据的项目可以轻松地做到这一点，并且随着新修订版本添加到仓库中，至少开发人员知道这些新修订版本至少与使用该仓库的所有人相关联。

在决定如何组织项目与仓库的关系后，您可能需要考虑仓库本身的目录层次结构。由于 Subversion 使用常规目录副本进行分支和标记（参见 第 4 章，分支和合并），Subversion 社区建议您为每个项目根目录选择一个仓库位置——包含与该项目相关数据的“最顶层”目录——然后在该根目录下创建三个子目录：trunk，表示进行主要项目开发的目录；branches，用于创建主开发线的各种命名分支的目录；以及 tags，它是一组创建的树快照，可能被销毁，但从不更改。^[40]

例如，您的仓库可能如下所示

请注意，每个项目根目录在仓库中的位置并不重要。如果您每个仓库只有一个项目，那么将每个项目根目录放在其各自仓库的根目录下是合乎逻辑的。如果您有多个项目，您可能希望将它们按组排列在仓库中，例如将具有相似目标或共享代码的项目放在同一个子目录中，或者只是按字母顺序对它们进行分组。这样的安排可能看起来像这样

以您认为合适的方式布局您的仓库。Subversion 不会期望或强制执行特定的布局——在其眼中，目录就是目录。最终，您应该选择满足在其中工作的项目的用户的需求的仓库安排。

为了完全公开，我们将提到另一种非常常见的布局。在此布局中，trunk、tags 和 branches 目录位于仓库的根目录中，您的项目位于这些目录下的子目录中，如下所示

这种布局并没有什么特别错误，但它可能对您的用户来说并不直观。特别是在拥有许多用户的庞大、多项目的情况下，这些用户可能只熟悉仓库中的一个或两个项目。但是，将项目作为分支兄弟的方法往往会淡化项目个性，而将重点放在整个项目集作为一个单一实体。不过，这是一个社会问题。我们喜欢我们最初建议的安排，纯粹出于实际原因——当有一个单一的仓库路径保存单个项目的整个历史记录（过去、现在、标记和分支）时，更容易询问（或修改或迁移到其他地方）单个项目的整个历史记录，并且仅此项目。

在创建您的 Subversion 仓库之前，您需要回答的一个显而易见的问题是它将放在哪里。这与涉及如何访问仓库（通过 Subversion 服务器或直接访问）、由谁访问（您公司防火墙后面的用户或整个开放互联网上的用户）、您将在 Subversion 周围提供哪些其他服务（仓库浏览界面、基于电子邮件的提交通知等）、您的数据备份策略等等。

我们在第 6 章，服务器配置中介绍了服务器选择和配置，但我们在这里想简要说明的是，对这些其他问题的答案可能会对您决定存储库的位置产生影响。例如，某些部署场景可能需要从多台计算机通过远程文件系统访问存储库，在这种情况下（正如您将在下一节中看到的那样），您对存储库后端数据存储的选择实际上不是选择，因为只有可用的后端之一在这种情况下才能工作。

介绍 Subversion 的每种可能的部署方式既不可能，也不在本书的范围之内。我们只是鼓励您使用这些页面和其他资源作为参考材料来评估您的选择，并提前计划。

Subversion 为每个存储库使用的底层数据存储类型提供了两种选择——通常称为 “后端” 或，有点令人困惑的是，“(版本化的)文件系统”——。一种数据存储类型将所有内容保存在 Berkeley DB (或 BDB) 数据库环境中；使用这种类型的存储库通常被称为 “BDB 支持的”。另一种类型将数据存储在普通平面文件中，使用自定义格式。Subversion 开发人员已经习惯于将这种后一种数据存储机制称为 FSFS^[41]——一种版本化的文件系统实现，它直接使用本机操作系统文件系统——而不是通过数据库库或其他抽象层——来存储数据。

表 5.1，“存储库数据存储比较” 对 Berkeley DB 和 FSFS 存储库进行了比较概述。

这两种后端类型各有优缺点。它们都没有比另一个更“官方”，尽管从 Subversion 1.2 开始，较新的 FSFS 是默认的数据存储。两者都足够可靠，可以用来存储您的版本化数据。但正如您在表 5.1, “仓库数据存储比较”中看到的那样，FSFS 后端在支持的部署场景方面提供了更多灵活性。更多的灵活性意味着您需要更努力地寻找错误部署它的方法。这些原因——再加上不使用 Berkeley DB 意味着系统中少了一个组件——在很大程度上解释了为什么今天几乎每个人在创建新仓库时都使用 FSFS 后端。

幸运的是，大多数访问 Subversion 仓库的程序都对使用哪种后端数据存储一无所知。您甚至不必坚持最初选择的数据存储——如果您以后改变主意，Subversion 提供了将仓库数据迁移到使用不同后端数据存储的另一个仓库的方法。我们将在本章后面详细介绍这一点。

以下小节将更详细地介绍可用的后端数据存储类型。