我正在开发一个平台，以在我们的环境中自动化和集成功能分支步骤。
现在我知道重新整合分支的正确程序是：
第一点是最容易出错的，因为可能有一些冲突需要解决，所以它只是客户端。
但我会通过我的平台 GUI 在服务器上运行重新集成合并，显然是在检查以确保分支与主干同步之后。这可能吗？
【问题讨论】：
好的，让我检查一下场景 - 我猜您是在尝试将开发人员与主干完全隔离，以便没有人直接提交到主干。我假设您的平台会自动创建这些分支，并且开发人员可以在某些时候说他们已经完成了分支并将其合并回。所以代码遵循循环：
我实际上完全赞成，如果这是您想要的工作方式，那太好了。
我想不出它会彻底失败的任何原因，但你必须检查以下几点：
第 1 点是最重要的。这意味着当重新集成发生时，它必须实际上是一个空操作。如果在您的 2.2 步骤中发生任何类型的合并，我会说您 必须 放弃提交并让开发人员再次从主干重新建立基础。即使 svn 说合并说是成功的并且没有冲突，你也不能相信它已经做了足够的正确的事情来触发和忘记。如果您要自动化，请确保开发人员提交的内容是合并的内容，而不是自动生成的混合内容。 您可以通过查看合并的输出来检查合并是否“干净” - 如果任何文件被“合并”，那么就有问题了。如果它们刚刚更新，那么您就可以了。
第 3 点很有趣，但始终是个问题，即使在正常工作中也是如此。在这种情况下，开发人员 A 会说他们已经完成，重新构建他们的工作副本，然后花一些时间检查一切是否正常。与此同时，开发人员 B 偷偷更新了主干。开发人员 A 认为一切正常并重新集成。但是，开发人员 B 所做的更改意味着即使代码没有触及开发人员 A 修改的任何文件，代码也会变得混乱。由于开发人员 A 是最后提交的，因此他们会受到指责。
假设如果开发人员 A 包含了开发人员 B 的更改，那么他就会发现问题。你的平台有机会发现这种情况（例如，如果 svn-merginfo 说有可以提交到分支的主干修订，那么它不是最新的）。但是，我也警告不要在没有必要的情况下创建一个永恒的合并循环。也许给开发人员一个警告，自他们重新建立基础以来已经进行了提交，但无论如何都允许他们继续。
最后一点：我在上面提到了使用 svn-mergeinfo。你不能依赖这个来假设重新整合合并是可以的。如果你这样做了，在进行检查和提交合并之间会有一个竞争条件 - 同时有人可能已经进入。您仍然需要检查实际合并命令的输出以了解实际发生的情况。
如果多个开发人员尝试同时重新集成，请注意这种情况。如果您每次都检查一个新的工作副本，您可以拥有任意数量的副本，但提交很可能会因旧的“文件过期”类型错误而失败。在这些情况下，重新集成将再次失败，您必须让开发人员重新建立他们的分支。
总而言之，我喜欢它。那里有相当多的复杂性，但归根结底，这就是这种系统的重点——它处理复杂的东西，所以开发人员不必这样做。他们所要做的就是不断重新建立他们的分支，直到系统允许他们成功重新集成。
【讨论】：