5

我们发布了 1.0 版本并继续在主干中开发 2.0。我们为与已发布版本相关的错误修复创建了分支/1.0。

计划是：

  • 2.0 开发继续在主干/
  • trunk/ 包含不会合并到branches/1.0 中的新功能，因此trunk 永远不会合并到branches/1.0 中
  • 当在发布的应用程序中发现错误时，会在分支/1.0 中进行修复。当修复集发布到生产环境时，branchs/1.0 被复制到 tags/1.0.x，branchs/1.0 被合并到 trunk/
  • 想法是颠覆合并跟踪应该跟踪更改，这样当我们将 1.0.4 修复合并到主干时，1.0.3 修复会自动跳过

这种方法有什么问题吗？颠覆合并跟踪是否可以跟踪更改？我还没有在实践中尝试过，并且大多数示例都以不同的方式执行此操作（从主干合并到分支，这是我不想要的，因为在 1.0 修复中不需要大多数 2.0 开发）。合并重新整合是否适合这种情况？

4

1 回答 1

6

是的，这正是它的设计目的。由于svn:mergeinfo主干上的属性会跟踪 1.0 中的哪些修复已被合并回来，因此第二次运行合并不会导致它再次获取这些修订。

合并前跟踪，您必须跟踪您合并了哪些修订，并确保您不会再次尝试合并它们。现在合并脚本更干净了。

于 2011-03-28T14:35:32.253 回答