Subversion合并分支时的冲突预防

Question

我最近在Subversion中发现了一个非常奇怪的合并冲突。我正在使用乌龟SVN作为客户端。请在中继和分支详细信息中找到以下信息：

• \ trunk \。有两个用户正在为此工作。
• \ QA \是分支从主干进行合并的分支。
• 为简单起见，\ trunk \ ClassLibrary1.sln中有一个Visual Studio解决方案
• 解决方案中当前有一个示例项目。 \ trunk \ ClassLibrary1
• 两个用户均已完全更新，并且没有任何工作副本更改。
• 以下事件将发生。

---

1. 用户1首先将在解决方案中添加一个新项目，然后提交整个目录。 （ClassLibrary11）
2. 用户2将进行更新并在解决方案中添加一个新项目，并提交整个目录结构（ClassLibrary12）
3. 上下文：在上述添加中，ClassLibrary11是我们的功能X，ClassLibrary12是我们的功能Y。现在功能Y是稳定的，完全独立于功能X，可以移动到QA分支。
4. 合并过程：我们转到质量检查分支，将特征Y从主干合并到质量检查分支。它成功合并，没有任何冲突。
5. 开发3周后，功能X变得稳定，现在我们尝试将功能X移至质量检查分支。 但是当我们合并时，它使我们在ClassLibrary.sln文件中发生合并冲突

tutorial

目的：我们希望将整个过程自动化为Devops管道的一部分，其中功能（完全独立）可以从仪表板提升到不同的分支，合并合并到功能的修订版。在上述情况下，特征X和特征Y完全独立（在功能和代码文件方面也是如此）。唯一的共同点是解决方案文件ClassLibrary.sln文件，其中添加了对两个项目的引用。

Tortoise SVN应该会自动发现，修订只是对2个不同提交的重新排序。因此，我只想知道一种方法（重新设计/预防性提交），以免发生此类冲突。而且如果发生这种情况，那么我需要知道在合并功能Y（即ClassLibrary12）时，这会在将来引起冲突

Answer 1

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