我有一个带有标准布局的subversion存储库，即trunk /和branches /（和tags /）。在进行更大的更改时，会使用功能分支，定期与主干同步，然后重新集成回主干（现在使用1.5）。非常标准的东西。
我想知道的是，这样一个功能分支，一旦完成并合并，是应该保留还是删除。颠覆书偶尔似乎暗示删除它们很常见，但我也看到了一堆开源项目，这些项目确实保留了分支机构。
我也有点担心删除分支会如何更难以跟踪存在哪些分支，特别是当可能重复的名称进入场景时（比如说我们搜索重构两次），他们的提交历史在深度某处消失存储库等。
另一方面，分支的使用非常多，特别是现在使用1.5分，而且我确实喜欢不必浏览大量非活动分支以找到我正在处理的分支。
我缺少哪些优点和缺点？人们在做什么？
答案 0 :(得分：28)
如果您真的担心删除它们，以免被遗忘，那么只需在名为“非活动”的分支下创建一个文件夹，并将svn move旧的非活动分支创建到该文件夹中。这对你来说可能是两全其美的。
答案 1 :(得分：22)
您可以安全地删除它们。删除它们不会将它们从存储库中删除，分配的空间永远不会被回收，但它确实会使整个项目树看起来更加清理。
答案 2 :(得分：11)
我一直在删除功能分支，因为我喜欢缺乏混乱。其他一些开发人员一直存在轻微的混淆，但由于我们在错误跟踪系统中记录了提交的修订数量，因此它非常顺利。如果有人说他们找不到分支，建议在他们的日志/差异/结账时使用-rrevision标志/通常所需的一切。
答案 3 :(得分：8)
我的团队会删除它们以防止混乱。毕竟不像是消失了;如果需要，可以检索它们。你是对的，很难再找到它们：你需要知道分支存在的修订号，这样你就可以告诉你的客户查看那个版本以查看你的文件。
我们使用FogBugz进行项目管理，通过修订号跟踪事件何时提交到我们的SVN存储库。我们可以使用它来确定我们需要修改的版本以便查看我们的文件：我们在FogBugz中找到功能历史记录，查看分支存在的修订版本，并使用该信息向后跳转。