我相当习惯于使用svn进行分支和合并，通常这可以正常工作。但是，一个组件是在两个分支中使用的，并且基本上沿不同方向使用该组件，因此自动合并将不起作用，并且使用“无法比较”会显示文件之间的差异最大。
我曾尝试将某些文件缝合在一起，但是即使它们起作用，结果也非常恐怖。
我很想对企业说这是做不到的。我看到这让他们感到沮丧，因为他们的模块+功能A正常运行，而模块+功能B正常运行，但是模块+功能A +功能B就目前而言毫无意义。例如，功能部件A可能删除了功能部件B中的关键组件。
有没有办法尝试合并这样的代码？还是模块+ A + B确实是模块+ C？
我们确实看到了这种情况的到来，但是功能A的需要时间比功能B的运行时间短，功能B是长期运行的项目的一部分。有什么方法可以避免这种情况的发生？还是他们使用结构化代码的方式来使这两个功能很好地融合在一起？
最佳答案
您在说的实际上是在尝试对其中一个分支进行基础调整。 some DVCSs中对此提供了支持，但是我不知道SVN中对此类型的任何支持。
最好的选择是选择一个分支(现在最重要的一个分支)并将其合并到主线中，这应该相当简单。在另一个分支中，您将需要从主干中提取更改并协调差异，鉴于您所描述的情况，这几乎肯定不是自动的，您可能需要花费一些认真的时间思考如何在顶部实现该分支功能。其中一个已合并到主线中，但这就是并行开发的成本:情况会发生变化。
您将来如何避免这种情况？ Frequent integration。
如果您有两个团队，每个团队都被赋予了代码库A，并且他们要花6个月的时间来研究不同的功能，那么由于每个人都对A做出了另一组变更的假设，因此集成将非常痛苦。另一方面，通过每周或每月的集成构建，每个团队应该更清楚地知道对方正在进行哪些更改，并且最终集成应该容易得多。
这就是为什么开源项目经常反对巨大的补丁程序，它们以惊人的速度过时而又过时而又没有人真正有时间对其进行适当审查的原因。另一方面，如果您做出相同的贡献并将其分解为多个可消化的小部分，那么您的贡献更有可能被A)接受并且B)受到了适当的审核，因此不会导致无休止的缺陷流。
关于svn - 手动合并不同代码的提示，我们在Stack Overflow上找到一个类似的问题：https://stackoverflow.com/questions/590220/