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

假设作为存储库管理员，您将负责支持多个项目的版本控制系统。您的第一个决定是使用单个存储库来存放多个项目，还是为每个项目分配一个独立的存储库，或者两者兼而有之。

使用单个存储库存放多个项目有其优势，最明显的是维护工作减少了。单个存储库意味着只有一套钩子程序，只需对一个东西进行例行备份，如果 Subversion 发布了不兼容的新版本，只需对一个东西进行转储和加载，等等。此外，您还可以轻松地将数据在项目之间移动，而不会丢失任何历史版本控制信息。

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

还可以采取一种折中的方法。例如，项目可以根据它们之间的关系进行分组。您可以创建几个存储库，每个存储库中包含几个项目。这样，可能想要共享数据的项目就可以轻松地进行共享，并且随着新的修订版本添加到存储库中，至少开发人员知道这些新的修订版本至少与使用该存储库的每个人都有一定的关联。

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

例如，您的存储库可能如下所示：

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

以您认为合适的任何方式布局您的存储库。Subversion 不会期望或强制执行特定的布局——在它看来，目录就是目录。最终，您应该选择满足在存储库中生存的项目的参与者需求的存储库安排。

为了全面披露，我们还要提到另一种非常常见的布局。在这种布局中，trunk、tags 和 branches 目录位于存储库的根目录中，您的项目位于这些目录下的子目录中，如下所示：

这种布局本身并没有什么错误，但它可能对您的用户来说并不直观。尤其是在大型、多项目且拥有众多用户的环境中，这些用户可能只熟悉存储库中的一两个项目。但项目作为分支同级元素的方法往往会淡化项目个性，并将重点放在整个项目集作为一个单一实体。不过，这是一个社会问题。我们喜欢我们最初建议的安排，完全出于实用原因——当有一个单一的存储库路径包含该项目的整个历史——过去、现在、标记和分支——并且只有该项目时，更容易询问（或修改、或迁移到其他地方）单个项目的整个历史。

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

我们在第 6 章，服务器配置 中介绍了服务器选择和配置，但我们在这里要简单说明的是，对其中一些其他问题的回答可能会有影响，从而迫使您在决定存储库的存储位置时做出选择。例如，某些部署方案可能需要通过多台计算机上的远程文件系统访问存储库，或者使用内容同步的多个存储库在地理位置上进行分发，以允许全球用户更有效地访问这些数据。处理 Subversion 的每种可能的部署方式既不可能，也不在本手册的讨论范围之内。我们只是鼓励您使用这些页面和其他资源作为参考材料来评估您的选项，并提前做好规划。

Subversion 中的访问控制几乎完全由 Subversion 服务器进程管理。我们在第 6 章，服务器配置 中讨论了可用的 Subversion 服务器，并在名为“基于路径的授权”的部分 中专门解释了基于路径的访问控制。除了这些用户级访问控制问题之外，您还需要确保您的存储库可以被托管机器上的需要访问它的程序访问。考虑对您的存储库进行有意义的操作系统级用户和组所有权。同样，在第 6 章，服务器配置 中找到的信息应该能够帮助您做出这些决定。