5

我相当习惯于使用 svn 进行分支和合并，通常这工作正常。然而，一个组件在两个分支中工作，并且基本上将组件带到不同的方向，因此自动合并将不起作用，并且使用超越比较显示文件大部分不同。

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

我很想对企业说，这是无法做到的。我可以看到这让他们感到沮丧，因为他们有模块 + 功能 A 和模块 + 功能 B 工作，但模块 + 功能 A + 功能 B 就目前而言没有意义。例如，功能 A 可能会删除功能 B 中的关键组件。

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

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

4

2 回答 2

4

你所说的本质上是试图重新定位其中一个分支。在一些 DVCS中对此有支持，但我不知道 SVN 中对这种事情有任何支持。

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

以后如何避免这种情况？频繁整合。

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

这就是为什么开源项目经常反对巨大的补丁，它们过时的速度惊人地快，而且没有人真正有时间正确地审查它们。另一方面，如果您将相同的贡献分解为多个独立的可消化的小部分，则您的贡献更有可能被 A) 接受和 B) 正确审查，这样它就不会导致层出不穷的缺陷。

于 2009-02-26T12:07:16.030 回答
0

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

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

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

于 2009-02-26T12:33:58.090 回答