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

我最近在 Subversion 中观察到一个非常奇怪的合并冲突。我使用乌龟SVN作为客户端。干线和分行详细信息请参见以下信息：

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

1. 用户 1 首先在解决方案中添加一个新项目并提交整个目录。 （类库11）
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）时，这会在将来引起冲突

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