有一些标准的，推荐使用的组织资料库的方法。大部分人们创建一个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.

在我们的例子里，你的个人分支有一个相对短的生存时间：你可能创建它是为了修正一个bug或实现一个新特性。 当你的任务完成时，你的分支的使命也完成了。不过在软件开发中，有两个“主”分支并行的运行很长的一段时间 也是很常见的。例如，假设到公开发布一个稳定的calc项目的时候了，并且你知道要花费几个月 时间来除掉软件里的bug。你不想人们在这个项目上加新特性，但你也不想告诉所有的开发者停止编程。因此取而代之的是，你创建 软件的一个“稳定”的分支，它不会修改太多：

$ 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上添加前沿的（或实验性的）特性， 你可以宣布一个项目政策，只有bug修正能被提交到/calc/branches/stable-1.0。 就是说，当人们继续在主线上工作时，人为挑选的一部分bug在稳定分支中被修正。甚至在稳定分支已经被发行后， 在很长一段时间，你可能要继续维护这个分支——也就是说，只要你还在向客户提供对这个发行版的支持。