有一些标准的、推荐的组织仓库内容的方式。大多数人创建一个 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 474.

	提示
	回想一下前一节，如果您的工作副本所指的仓库位置被删除，那么当您尝试更新时，您将收到错误消息 $ svn up Updating '.': svn: E160005: Target path '/calc/branches/my-calc-branch' does not exist 在这种情况下，您所需要做的就是将您的工作副本切换到仍然存在的某个位置 $ svn sw ^/calc/trunk D src/whole.c U src/real.c A src/integer.c U . Updated to revision 474.

现在您的分支就消失了。当然，它并没有真正消失：该目录只是从 HEAD 修订版中消失了，不再影响任何人。如果您使用 svn checkout、svn switch 或 svn list 检查早期修订版，您仍然可以看到您的旧分支。

如果浏览已删除的目录还不够，您可以随时将其恢复。在 Subversion 中恢复数据非常容易。如果存在一个已删除的目录（或文件），您希望将其恢复到 HEAD，只需使用 svn copy 从旧修订版中复制它即可

$ svn copy ^/calc/branches/my-calc-branch@473 \
           ^/calc/branches/my-calc-branch \
           -m "Restore my-calc-branch."

Committed revision 475.

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

$ svn copy ^/calc/trunk ^/calc/branches/stable-1.0 \
           -m "Creating stable branch of calc project."

Committed revision 476.

现在，开发人员可以继续向 /calc/trunk 添加尖端（或实验性）功能，您可以宣布一个项目策略，即只有错误修复才能提交到 /calc/branches/stable-1.0。也就是说，当人们继续在主干上工作时，人们会选择性地将错误修复提交到稳定分支。即使在稳定分支发布之后，您也可能需要长时间维护该分支，也就是说，只要您继续为客户提供该版本的支持，就需要维护该分支。我们将在下一节中详细讨论这一点。