有一些标准的、推荐的组织仓库的方法。大多数人创建 trunk 目录来保存开发的 “主线”，一个 branches 目录来保存分支副本，以及一个 tags 目录来保存标签副本。如果一个仓库只保存一个项目，通常人们会创建这些顶层目录

如果一个仓库包含多个项目，管理员通常会按项目索引其布局。参见 名为“规划你的仓库组织”的部分，了解更多关于 “项目根目录” 的信息，但这里是一个这种布局的例子

当然，你可以自由地忽略这些常见的布局。你可以创建任何你想要的变化，无论对你或你的团队来说什么最有效。请记住，无论你选择什么，它都不是一个永久的承诺。你可以在任何时候重新组织你的仓库。因为分支和标签是普通的目录，svn move 命令可以根据你的意愿移动或重命名它们。从一种布局切换到另一种布局只是执行一系列服务器端移动的问题；如果你不喜欢仓库中组织方式，只需调整目录即可。

但是请记住，虽然移动目录可能很容易，但你也需要考虑到你的用户。你的调整可能会让拥有现有工作副本的用户感到困惑。如果用户拥有特定仓库目录的工作副本，你的 svn move 操作可能会从最新版本中删除该路径。当用户下次运行 svn update 时，他们将被告知他们的工作副本代表着一个不再存在的路径，用户将被迫 svn switch 到新的位置。

Subversion 模型的另一个好特性是，分支和标签可以拥有有限的生命周期，就像任何其他版本化的项目一样。例如，假设你最终完成了对 calc 项目的个人分支的所有工作。在将所有更改合并回 /calc/trunk 后，你的私人分支目录不再需要存在

$ svn delete http://svn.example.com/repos/calc/branches/my-calc-branch \
             -m "Removing obsolete branch of calc project."

Committed revision 375.

现在你的分支消失了。当然，它并没有真正消失：这个目录只是从 HEAD 修订版中消失了，不再分散任何人的注意力。如果你使用 svn checkout、svn switch 或 svn list 来检查之前的修订版，你仍然可以看到你的旧分支。

如果浏览你已删除的目录还不够，你始终可以把它带回来。在 Subversion 中恢复数据非常容易。如果有一个你想要重新带回 HEAD 的已删除目录（或文件），只需使用 svn copy 从旧修订版中复制它

$ svn copy http://svn.example.com/repos/calc/branches/my-calc-branch@374 \
           http://svn.example.com/repos/calc/branches/my-calc-branch \
           -m "Restore my-calc-branch."

Committed revision 376.

在我们的例子中，你的个人分支的生命周期相对较短：你可能创建它来修复错误或实现新功能。当你完成任务时，分支也就结束了。然而，在软件开发中，通常也会并行运行两个 “主” 分支，而且时间很长。例如，假设现在是将 calc 项目的稳定版本发布给公众的时候，并且你知道需要几个月的时间才能消除软件中的错误。你不想让人们给项目添加新功能，但你也不想告诉所有开发人员停止编程。因此，你可以创建一个软件的 “稳定” 分支，这个分支不会有太大变化

$ svn copy http://svn.example.com/repos/calc/trunk \
           http://svn.example.com/repos/calc/branches/stable-1.0 \
           -m "Creating stable branch of calc project."

Committed revision 377.

现在，开发人员可以自由地继续在 /calc/trunk 中添加最先进的（或实验性的）功能，并且你可以宣布一项项目策略，即只有错误修复才能提交到 /calc/branches/stable-1.0。也就是说，随着人们继续在主干上工作，人类会选择性地将错误修复移植到稳定分支。即使在稳定分支发布后，你可能也会继续维护该分支很长时间——也就是说，只要你继续为客户提供该版本的支持。我们将在下一节中对此进行更多讨论。