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

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

\树干\ .两个用户正在研究这个问题.

\ QA \是从主干合并的分支.

为简单起见,在\ trunk\ClassLibrary1.sln中有一个visual studio解决方案

目前解决方案中有一个示例项目.\干线\ ClassLibrary1的

两个用户都已完全更新,并且没有任何工作副本更改.

将发生以下事件序列.

用户1将首先在解决方案中添加一个新项目并提交整个目录.(ClassLibrary11)

用户2将获取更新并在解决方案中添加新项目并提交整个目录结构(ClassLibrary12)

上下文:在上面的补充中,ClassLibrary11是我们的特征X而ClassLibrary12是我们的特征Y.现在特征Y是稳定的,完全独立于特征X并且可以移动到QA分支.

合并过程:我们转到QA分支并将功能Y从主干合并到QA分支.它成功合并,没有任何冲突.

在开发3周后,功能X变得稳定,现在我们尝试将功能X移动到QA分支.但是当我们合并时,它会在ClassLibrary.sln文件中给出合并冲突

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

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