【问题标题】:Subversion: deleting old feature branches vs. keeping them颠覆:删除旧功能分支与保留它们
【发布时间】:2010-09-14 19:47:02
【问题描述】:

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

我想知道这样一个功能分支,一旦完成并合并,是否应该保留或删除。颠覆书偶尔似乎暗示删除它们是很常见的,但我也看到了一堆保留分支的开源项目。

我也有点担心删除一个分支会使跟踪哪些分支存在变得更加困难,尤其是当潜在的重复名称进入场景时(比如我们搜索重构两次),它们的提交历史会在深度的某个地方消失存储库等。

另一方面,分支被大量使用,尤其是现在的 1.5,而且我确实喜欢不必通过大量非活动分支来查找我目前正在处理的分支的想法。

我缺少哪些优点和缺点?人们在做什么?

【问题讨论】:

    标签: svn version-control branch


    【解决方案1】:

    如果您真的担心删除它们,以免它们被遗忘,那么只需在名为“inactive”的分支下创建一个文件夹,然后将 svn move 旧的非活动分支添加到该文件夹​​中。这对您来说可能是两全其美。

    【讨论】:

    • 你不会还要处理重复的分支名称吗,我想你也可以用它不活动的日期重命名
    【解决方案2】:

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

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

    【讨论】:

      【解决方案3】:

      完成后我一直在删除功能分支,因为我喜欢没有杂乱。其他一些开发人员有一些小的困惑,但是由于我们在错误跟踪系统中记录了提交的修订号,所以它非常顺利。如果有人说他们找不到分支,建议在他们的 log/diff/checkout/whatever 上使用 -rrevision 标志,这通常是所有需要的。

      【讨论】:

        【解决方案4】:

        您可以安全地删除它们。删除它们并不会从存储库中删除它们,分配的空间永远不会回收,但它确实会让您的整个项目树看起来更加干净。

        【讨论】:

          猜你喜欢
          • 1970-01-01
          • 2010-10-08
          • 1970-01-01
          • 2023-03-28
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          • 1970-01-01
          相关资源
          最近更新 更多