手动合并分歧代码的提示

Question

我习惯使用svn进行分支和合并，通常这很好用。然而，在两个分支中处理了一个组件，并且基本上将组件放在不同的方向上，因此自动合并将不起作用，并且使用超出比较显示文件大多不同。

我试图将一些文件拼接在一起，但结果，即使它们有效，也是非常可怕的。

我很想向企业说这是不可能做到的。我可以看到这令他们感到沮丧，因为他们有模块+功能A工作和模块+功能B工作但模块+功能A +功能B只是没有意义。例如，要素A可能会移除某些特征B中的关键组件。

有没有办法尝试合并这样的代码？或模块+ A + B真的模块+ C？

我们确实看到了这一点，但是功能A需要的时间比功能B更短，而功能B是长期运行项目的一部分。有没有办法避免这种情况发生？或者他们是如何构建代码以便两个功能很好地结合在一起的？

Answer 1

你所说的基本上是试图改变其中一个分支。在some DVCSs中有对此的支持，但我不知道在SVN中对此类事情有任何支持。

你最好的选择是选择其中一个分支（现在最重要的分支）并将其合并到主线上，这应该是相当直接的。在另一个分支中，您将需要从trunk中提取更改并协调差异，根据您描述的情况，这几乎肯定不会是自动的，您可能需要花一些时间考虑如何在顶部实现此分支功能一个合并到主线，但这是并行开发的成本：事情发生了变化。

将来如何避免这种情况？ Frequent integration

如果你有两个团队，每个团队都有一个代码库A，并且他们会在不同的功能上工作6个月，那么整合就会非常痛苦，因为每个团队都会对另一个团队已经改变的A做出假设。另一方面，通过每周或每月集成构建，每个团队应该更加了解另一个团队正在进行哪些更改，并且最终集成应该更容易。

这就是为什么开源项目经常反对巨大的补丁，它们过快地过时，没有人真正有时间正确地审查它们。另一方面，如果你采取相同的贡献并将其分解为一些独立的易消化部分，你的贡献更可能是A）被接受和B）正确审查，因此它不会导致无穷无尽的缺陷。

Answer 2

单个文件，比如src1.c. 您可以通过这种方式构建描述合并的菱形图：

   Original src1.c
        /       \
       /         \
      /           \
   b1 src1.c     b2 src1.c
      \            /
       \          /
        \        /
         \      /
        merged src1.c

其中b1表示第一个分支版本，b2表示第二个分支版本。 您可以比较并行差异（比如合并的源和b2版本之间的差异，以及b1和原始版本）。这可能会有所帮助。