我必须从分支到主干进行合并。这两者在结构上已经完全不同了，有六个以上的树冲突，可能还有五十个左右的文本冲突。可以理解，我对这次合并感到有些紧张。
我想知道产生冲突的标准究竟是什么。假设函数F效率低下，因此分支中的开发人员重写它以获得辅助函数G，而trunk中的开发人员以不同的方式重写它。在这种情况下，我理解将在函数F上生成冲突，函数F以两种不同的方式重写。但是会不会在函数G上产生冲突，它不属于主干版本？或者功能G实际上是否会被应用并逃避任何通知？我担心合并可能导致的这种混乱代码。
答案 0 :(得分：1)
Subversion无法保护您免受语义冲突的影响。就此而言，我不知道可以的版本控制系统。
在您的具体示例中，答案取决于。 G功能可能包含在冲突中。但如果两个文件在文件中相距足够远，并且G函数附近没有其他任何变化，那么合并完全有可能仍然保持G。
当然还有许多其他方法可以获得永远不会被版本控制系统捕获的语义冲突。例如，有人修改函数F以获得新参数。另一个开发人员在另一个文件中添加了一个新的函数F调用，改变F的开发人员不会触摸，也不会对他的工作副本进行更改。当开发人员提交新函数F时，即使语义上他的更改与存储库中的现有代码冲突，也没有冲突。使用我们今天使用的版本控制系统，解决方案是团队沟通，代码审查和测试。
避免这样的事情的唯一方法是，如果执行合并的工具理解语言，而不仅仅是面向行的冲突。这当然意味着您的版本控制工具需要支持您使用它的每种语言。这将使其作为通用工具的用处远没那么有用。
然而，有一种语义感知合并工具的实现。 SemanticMerge支持C＃和Java。 Subversion支持外部合并工具，我知道有些用户使用这个工具来处理这些类型的情况。
在实践中，这些问题实际上并不常见。