我有一个具有标准布局的subversion存储库，即trunk /和branchs /(和tags /)。在进行较大更改时，将使用功能分支，并定期与主干同步，然后重新集成回主干(现在使用1.5)。很标准的东西。

我想知道的是，一旦完成并合并这样的功能分支，应该保留还是删除它。该颠覆书有时似乎暗示删除它们是很常见的，但是我也看到了一些确实保留分支的开放源代码项目。

我还有些担心删除分支将如何使其更难以跟踪存在的分支，尤其是当可能重复的名称进入场景时(例如我们两次搜索重构)，它们的提交历史消失在存储库深度的某个位置等等。

另一方面，分支的使用率很高，尤其是现在使用1.5，并且我喜欢这样的想法：不必遍历大量不活动的分支来查找我当前正在处理的分支。

我缺少哪些利弊？人们在做什么？

解决方案

我们可以安全地删除它们。删除它们并不会从存储库中删除它们，所分配的空间不会被回收，但是可以确保整个项目树看起来更加整洁。

我一直在删除要素分支，因为我喜欢不混乱。其他一些开发人员对此稍有困惑，但是由于我们在错误跟踪系统中记录了提交的修订版本，因此运行起来非常顺畅。如果有人说找不到分支，那么建议在他们的log / diff / checkout /通常使用的所有东西上使用-rrevision标志。

我的团队删除了它们以保持混乱。毕竟，这并不像走开。如果需要，可以检索它们。没错，再次找到它们可能很困难：我们需要知道分支所在的修订号，以便告诉客户端查看该修订以查看文件。

我们使用FogBugz进行项目管理，它通过修订号跟踪何时将内容提交到SVN存储库。我们可以使用它来确定需要恢复到哪个修订版本才能查看文件：我们在FogBugz中找到功能历史记录，查看以确定分支存在的修订版本，并使用该信息向后跳转。

如果我们真的担心删除它们，以免忘记它们，那么只需在名为"非活动"的分支下创建一个文件夹，然后将较旧的非活动分支" svn move"移入该文件夹。这对我们来说可能是两全其美的。