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

/trunk
/branches
/tags

如果一个仓库包含多个项目，管理员通常会按项目索引其布局（有关“项目根”的更多信息，请参阅 名为“选择仓库布局”的部分）。

/paint/trunk
/paint/branches
/paint/tags
/calc/trunk
/calc/branches
/calc/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 -r 从旧版本中复制它。

$ svn copy -r 374 http://svn.example.com/repos/calc/branches/my-calc-branch \
                  http://svn.example.com/repos/calc/branches/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。也就是说，当人们继续开发主线时，人工可以选择性地将错误修复移植到稳定分支。即使在稳定分支发布之后，您可能还会继续维护该分支很长时间——也就是说，只要您继续为客户提供对该版本的支持。