svn分支合并树冲突问题（使用乌龟）答案

【问题标题】：svn branch merge tree conflict issue (using tortoise)svn分支合并树冲突问题（使用乌龟）
【发布时间】：2013-04-28 09:25:57
【问题描述】：

我已经阅读了很多关于此的内容，但无法弄清楚问题所在，这很奇怪。我为服务器使用 1.7 版，为客户端使用最新的龟版（1.7）。这是场景：

我创建了一个父分支，然后从中创建了 1 个子分支。所以，PARENT_BRANCH -> CHILD_BRANCH
在 CHILD_BRANCH 中添加一个新目录并提交。
使用 tortoise 合并从 CHILD_BRANCH 到 PARENT_BRANCH 的所有更改。我使用了 'merge a range of revisions' 选项，并没有在选项中指定任何修订，所以基本上让 svn 识别和管理要合并的修订。
合并后，在 PARENT_BRANCH 中创建新目录。
从 PARENT_BRANCH -> CHILD_BRANCH 合并回来。
我在新目录上遇到树冲突，错误是它尝试添加的目录已经存在。

当然，该目录在子分支中，因为它最初来自那里。我虽然 svn 1.5+ 使用 merge-info 跟踪合并，但应该知道这是目录所在的分支，不应该抛出树合并错误。

知道发生了什么，我该如何解决这个问题？我给出的示例只是针对 1 个目录，但实际上有很多目录和文件，因此手动逐个处理需要数小时。

【问题讨论】：

【解决方案1】：

问题是 CHILD 和 PARENT 都有不同的修订版，它们添加了相同的文件夹。 CHILD 对第 4 步中的修订一无所知。

在每次从 CHILD 到 PARENT 的合并之后（您的第 4 步），您需要立即向 CHILD 记录它具有从 CHILD 到 PARENT 的合并修订。为此，您可以将 PARENT 中的修订合并到 CHILD 并在 tortoisesvn 中检查此标志：

【讨论】：

感谢您的回复。因此，如果我理解正确，假设从 CHILD->PARENT 合并时，svn 标识 r100-r200 将从 CHILD 中获取和合并。合并后，当我提交时，可以说它是修订版 r201。所以，现在我必须告诉 CHILD 将 r201 记录为“仅记录”，这样当我从 PARENT->CHILD 合并回来时，这个特定的修订版将被忽略，并且我不应该因为 CHILD->PARENT- 而出现任何树冲突>儿童合并。这真的很奇怪，因为 svn 应该已经知道创建目录命令是由哪个分支发起的。
不用担心，是的，您的描述是正确的。由于 svn 没有针对“合并”记录它已合并到的详细信息以及提交合并时所做的修订，因此它无法执行您想要的操作。 Svn 对于短期功能分支当然比您正在使用的长期分支更好。

【解决方案2】：

SVN 是一种可以以多种不同方式使用的工具。一些用例得到很好的支持，而另一些则没有。两个分支之间不断双向合并属于后一类。

因此，SVN 并不适合所有项目。但是，它对于大多数项目都非常有效，因为不需要合并两个方向的更改。 SVN 的典型工作流程如下：

创建一个特性分支，对特性分支进行更改，并将来自原始分支的所有更改合并到特性分支，以便特性分支包含来自原始分支的所有内容以及仅存在于此分支上的一些附加特性特定的功能分支。一旦功能分支完成，它就会与原始分支重新集成，并关闭。

这个工作流程得到了 SVN 的良好支持，并且在大多数项目中运行良好。

【讨论】：

感谢您的回复。我不能使用重新整合，因为这个分支不会消失。这是一个常规的开发分支，我们在其中添加功能，将其推送到生产环境，然后继续为下一个版本开发。
@AC1：请说明在哪些情况下您必须合并两个方向的更改。不了解您的实际需求，很难为您提供帮助。
当然。我们的分支结构是这样的。我们有一个“主干”分支（PARENT），并且有多个 CHILD 分支，例如“短期”、“长期”（我正在编造名称以提供您的想法）。开发人员继续在这些分支中工作，短期 2 周 sprint 和长期 8 周 sprint。冲刺完成后，分支将其更改合并到主干中，主干被推送到生产环境，然后主干被合并回短期和长期，这样它们就可以同步了。子分支永远存在，并且在发布到生产完成后不会停止存在
@AC1：您的工作流程没有什么特别之处。更改仅从主干合并到开发（功能）分支，并且在每个 sprint 后功能分支与主干重新集成。通常，您会在 sprint 结束时删除分支并为新的 sprint 创建一个新分支。但是，也可以重用现有的功能分支。 Version Control with Subversion 一书中的Keeping a Reintegrated Branch Alive 部分解释了它是如何工作的。
谢谢诺西德。我认为这正是@mounds 在他的回复中提到的。感谢你们让我明白这一点。