在Subversion中合并分支时的冲突预防

Question

我最近在Subversion中发现了一个非常奇怪的合并冲突.我正在使用陆龟SVN作为客户端.请查看以下有关主干和分行详情的信息:

• \树干\ .两个用户正在研究这个问题.
• \ QA \是从主干合并的分支.
• 为简单起见,在\ trunk\ClassLibrary1.sln中有一个visual studio解决方案
• 目前解决方案中有一个示例项目.\干线\ ClassLibrary1的
• 两个用户都已完全更新,并且没有任何工作副本更改.
• 将发生以下事件序列.

---

1. 用户1将首先在解决方案中添加一个新项目并提交整个目录.(ClassLibrary11)
2. 用户2将获取更新并在解决方案中添加新项目并提交整个目录结构(ClassLibrary12)
3. 上下文:在上面的补充中,ClassLibrary11是我们的特征X而ClassLibrary12是我们的特征Y.现在特征Y是稳定的,完全独立于特征X并且可以移动到QA分支.
4. 合并过程:我们转到QA分支并将功能Y从主干合并到QA分支.它成功合并,没有任何冲突.
5. 在开发3周后,功能X变得稳定,现在我们尝试将功能X移动到QA分支.但是当我们合并时,它会在ClassLibrary.sln文件中给出合并冲突

意图:我们希望将整个流程自动化作为我们的Devops管道的一部分,其中功能(完全独立)可以从仪表板升级到不同的分支,这将合并与功能相关联的修订.在上面的情况下,特征X和特征Y是完全独立的(功能和代码文件也是如此).唯一的共同点是解决方案文件ClassLibrary.sln文件,其中添加了对这两个项目的引用.

Tortoise SVN应该自动发现修订版只是对2个不同提交的重新排序.所以我只是想知道一种方式(重新设计/预防性提交),以免这种冲突发生.如果他们应该发生那么我需要知道,虽然合并功能Y即ClassLibrary12,这将导致未来的冲突

Answer 1

解决冲突的过程不可能自动化。如果可能的话 SVN 会为你做这件事，但事实并非如此，所以它不能。总是需要有人来解决冲突。现在你可能想知道为什么会发生冲突，但我认为这不是一个重要的问题。不要紧。重要的是您对自动解决冲突的期望是不现实的。这是不可能的。