服务器端SVN分支重新集成

Question

我正在开发一个平台，用于在我们的环境中自动化和集成功能分支步骤。

现在我知道重新集成分支的正确过程是：

1. svn merge URL/trunk (在分支工作副本中与主干同步)
2. 2. svn update（在主干工作副本中）
   3. svn merge --reintegrate URL/branch（在主干工作副本中）

第一点是最容易出错的，因为可能会有一些冲突需要解决，所以它只是客户端。

但我会通过我的平台 GUI 在服务器上运行重新集成合并，显然是在检查确保分支与主干同步之后。 这可能吗？

Answer 1

好吧，让我检查一下场景 - 我猜你正在尝试将开发人员与主干完全隔离，这样就没有人直接提交到主干。 我假设你的平台自动创建这些分支，开发人员可以在某个时候说他们已经完成了分支并将其合并回来。因此代码遵循以下循环：

1. 分支
2. 编辑
3. 提交到分支
4. 从主干重新建立分支
5. 更新trunk wc
6. 将分支重新集成到 trunk wc
7. 提交 trunk wc

我实际上完全支持这个，如果这是您想要的工作方式，那就太好了。

我想不出它会彻底失败的任何原因，但您必须检查以下事项： 在

1. 没有开发人员首先查看的情况下，不得签入任何代码。
2. 错误总是会发生在主干上，开发人员在某些时候可能需要一种直接攻击主干的方法。
3. 即使没有合并，如果开发人员没有重新基于最新的主干，重新集成也可能会引入微妙的错误。

第1点是最重要的。 这意味着当重新集成发生时，它实际上必须是无操作。 如果您的 2.2 步骤中发生任何类型的合并，我想说您必须放弃提交并让开发人员再次从主干重新建立基础。 即使 svn 说合并成功并且没有冲突，你也不能相信它已经做了足够正确的事情，以至于解雇后就忘记了。 如果您要实现自动化，请保证开发人员提交的内容是被合并的内容，而不是某些自动生成的混合内容。
您可以通过查看合并的输出来检查合并是否“干净” - 如果任何文件被“合并”，则存在问题。 如果它们刚刚更新，那就没问题。

第 3 点很有趣，但始终是一个问题，即使在正常工作中也是如此。 在这种情况下，开发人员 A 会说他们已经完成了，重新调整他们的工作副本，然后花一些时间检查一切是否正常。 与此同时，开发者 B 偷偷更新了 trunk。 开发人员 A 认为一切正常并重新集成。 然而，开发人员 B 所做的更改意味着代码会变得混乱，即使它没有触及开发人员 A 修改的任何文件。由于开发人员 A 是最后提交的，因此他们受到指责。

假设是，如果开发人员 A 包含了开发人员 B 的更改，那么他就会发现问题。 您的平台有机会发现这种情况（例如，如果 svn-merginfo 说有可以提交到分支的主干修订，那么它不是最新的）。 然而，我也警告不要在没有必要的情况下创建一个永恒的合并周期。 也许可以向开发人员发出警告，表明他们重新建立基础后已经进行了提交，但无论如何都允许他们继续进行。

最后一点：我在上面提到过使用 svn-mergeinfo。 您不能依赖于此来假设重新集成合并就可以了。 如果这样做，在进行检查和提交合并之间就会出现竞争条件 - 有人可能会同时介入。 您仍然需要检查实际合并命令的输出以了解到底发生了什么。

如果多个开发人员尝试同时重新集成，还要注意这种情况。 如果您每次都签出一个新的工作副本，则可以拥有任意数量的工作副本，但提交很可能会因旧的“文件已过期”类型错误而失败。 在这些情况下，重新集成将再次失败，您必须让开发人员重新建立他们的分支。

总而言之我喜欢它。 其中有相当多的复杂性，但归根结底，这就是这种系统的重点 - 它处理复杂的事情，因此开发人员不必这样做。 他们所要做的就是不断重新调整分支机构，直到系统让他们成功重新整合。