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