在Subversion合并分支时如何避免冲突

Question

我最近在Subversion中观察到一个非常奇怪的合并冲突。我使用的是Tortoise 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. 合并过程：我们转到QA分支，并从主干合并特性Y到QA分支。它成功地合并而没有任何冲突。
5. 经过3周的开发，特性X变得稳定，现在我们尝试将特性X移动到QA分支。但是，当我们进行合并时，它会在ClassLibrary.sln文件中给出合并冲突

意图：我们希望将整个流程自动化作为我们的DevOps管道的一部分，从仪表板中可以将完全独立的功能推广到不同的分支，该仪表板会合并与功能相关联的修订版本。在上述情况下，功能X和功能Y是完全独立的（在功能和代码文件方面也是如此）。唯一的共同点是解决方案文件ClassLibrary.sln文件，在其中添加了对这两个项目的引用。

Tortoise SVN应该自动发现修订版本只是对2个不同提交的重新排序。因此，我想知道一种方法（重新设计/预防性提交），以避免发生此类冲突。如果它们应该发生，那么我需要知道，在合并Feature Y即ClassLibrary12时，这将导致未来的冲突。

- ankur

Answer 1

无法自动化解决冲突的过程。如果可能的话，SVN会为您完成此操作，但事实并非如此，因此它无法做到。始终需要有人来解决冲突。现在您可能会想知道为什么会发生冲突，但我认为这不是一个重要的问题。重要的是，您对自动解决冲突的期望是不现实的。这是不可能的。

- Dialecticus