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

Posted 2023-02-23

【中文标题】在 Subversion 中合并分支时的冲突预防

【英文标题】：conflicts prevention while merging branches in Subversion

【发布时间】：2019-01-10 11:05:51

【问题描述】：

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

\主干\。有两个用户正在解决这个问题。 \QA\ 是从主干进行合并的分支。 为简单起见，\trunk\ClassLibrary1.sln 中有一个 Visual Studio 解决方案 解决方案中当前有一个示例项目。 \trunk\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 这会在未来引起冲突

【参考方案1】：

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