问题标签 [svn-reintegrate]

合并（重新集成）回主干后必须删除功能分支吗？

我更喜欢不断地从我的功能分支来回合并更改 - 我相信这可以将冲突降至最低。但是我知道，一旦您使用 reintegrate 合并到主干，应该删除功能分支。

是这样吗？为什么？我能做些什么来规避这种情况？

更新 我问的是来自工具的技术问题，而不是“方法问题”。我打算在合并后继续在功能分支上工作。

更新最佳答案确实指定了一个相当复杂的过程（合并、删除和重新分支）。在 TortoiseSVN 中是否有一种简单的方法可以实现这一点？不应该吗？

如果您总是在合并之前同步功能分支。为什么你真的必须使用该--reintegrate选项？

颠覆书说：

然而，当将你的分支合并回主干时，基础数学是完全不同的。您的功能分支现在是重复的主干更改和私有分支更改的混合体，因此没有简单的连续修订范围可供复制。通过指定 --reintegrate 选项，您要求 Subversion 只仔细复制那些对您的分支唯一的更改。（事实上​​，它通过比较最新的主干树和最新的分支树来做到这一点：由此产生的差异正是您的分支更改！）

因此该--reintegrate选项仅合并功能分支独有的更改。但是如果你总是在合并之前同步（这是一个推荐的做法，为了处理特性分支上的任何冲突），那么分支之间的唯一变化就是特性分支独有的变化，对吧？如果 Subversion 试图合并已经在目标分支上的代码，它什么也不做，对吧？

在一篇博文中，Mark Phippard 写道：

如果我们包括那些同步的修订，那么我们将合并回主干中已经存在的更改。这会产生不必要的和令人困惑的冲突。

有没有一个例子说明放弃重新整合会给我带来不必要的冲突？

我正在尝试将开发分支重新集成到我的 Subversion 1.5 存储库中的主干中。在此操作之前，我将所有更改从主干合并到开发分支。现在，当我尝试重新集成分支中的更改时，我收到以下错误消息：

然后该消息继续抱怨我的项目中的一些文件夹。但是当我尝试再次将主干的更改合并到开发分支时，TortoiseSVN 告诉我没有什么要合并的（因为我之前已经合并了所有的更改）：

我正在尝试按照此处的说明进行操作：http: //svnbook.red-bean.com/en/1.5/svn.branchmerge.basicmerging.html，但是没有解决这样的问题。

有任何想法吗？也许我应该删除主干然后复制我的分支？但我不确定它是否安全。

也可以看看

svn merge with --reintegrate 抱怨缺少范围，但 mergeinfo 似乎是正确的

我已经阅读了很多关于当您从分支合并回 SVN 中的主干时需要重新集成的内容（一篇关于外部存储库合并的文章非常有帮助）。

问题似乎来自人们定期从主干更新分支的事实，这意味着最终合并回来是反射性的。

在我的用例中，我们想要创建一个发布分支，只要它能够稳定分支并修复任何错误，它就会一直存在。为了保持稳定性，我们不想从主干向上合并，但我们确实希望定期从发布分支向下合并修复，以便主干免费获得所有错误修复。我们也不想等到QA结束才合并回主干。因此，我们希望：

1. 创建分支
2. 定期更改分支（和主干）
3. 定期合并回主干（也许每天）

由于我们永远不会从主干合并，我认为我们不需要担心重新集成旨在解决的问题。这种方法有问题吗？

我有一个大型项目，需要在新功能上做很多工作，所以我计划使用一个分支来完成这项工作。我以前不需要这样做，我只是想从有经验的 Subversion 用户那里得到保证，事情“应该”顺利进行。

我特别关心的是 Subversion 处理分支和主干之间删除、重命名/移动文件的能力。也就是说，如果多个文件在分支中被删除或重命名/移动，但这些文件继续被使用并在主干中接收更改，将与主干合并仍然顺利进行（当然，根据需要重新处理分支)?

另外，当我将分支与主干重新集成时，如果主干和分支之间的文件名称（或存在）差异很大，重新集成会很困难吗？分支中删除（移动）的文件现在会在主干中删除（移动），还是文件会滞留并出现冲突？

SVN 书并没有为我解决这些问题，因此将不胜感激您的经验。谢谢！

我发现这种方式更容易合并分支和更少的冲突：

将主干复制到新分支，将其与功能分支合并。完成后，将新分支合并回主干。这种技术很像 mercurial 和 git rebase。

我曾经合并从主干到功能分支的任何变化。但是后来当我把feature分支合并回trunk时，trunk中的一些东西又会重新合并回trunk，造成了很多冲突。有一个重新整合合并的选择，但它似乎对我不起作用。

有没有人做类似的颠覆变基？我最近才开始这样做，还没有看到任何副作用。这会导致任何不可预见的问题吗？

我一直在努力了解 SVN 合并/重新集成，并阅读了这些文章/书籍：

http://svnbook.red-bean.com/en/1.5/index.html
http://blogs.open.collab.net/svn/2008/07/subversion-merg.html

我显然还没有完全明白，因为我不明白为什么在合并回主干（反射/循环合并）中包含同步修订是一个问题 - 我确实看到了不排除修订的理由。

如果trunk上的一行文件A被合并到branch上的文件A'中，然后又合并回trunk，那么A和A'肯定没有区别，所以不冲突？为什么“[合并]主干中已经存在的更改”是一个问题？

我正在尝试复制冲突场景，以尝试了解 reintegrate 为我做的事情，但更让我困惑的是这种情况：

1. 在主干上提交更改 (r4)
2. 将 r4 合并到分支并提交 (r5)
3. 在分支上提交更改 (r6)
4. 通过以下任一方式将分支合并到主干：
   • 将修订范围 r5-r6 合并到主干 - 发生冲突，或
   • 将 r5 合并到主干，然后将 r6 合并到主干 - 不会发生冲突

我正在使用 SmartSVN 6.6 和 SVN 1.6。为什么与单独合并每个修订版相比，合并修订版范围时会产生不同的结果？最终，为什么包含反射合并是一个问题？

我有 2 个分支，我正在重新整合

在两个分支中，我都有相同的 CFG 文件，我不想被调和。
想让它们保持版本化但不协调。

你知道如何从这个过程中排除指定的文件吗？

由于我的 SVN 存储库仍然使用 Subversion 1.4，因此我使用svnmerge.py进行合并跟踪。我有一个与主干保持同步的功能分支（svnmerge init在分支之后，然后不时地svnmerge merge）。

现在我想将分支重新集成回主干（这与 SVN 书中描述的情况相同）。

我怎样才能执行相当于svn merge --reintegrateusing svnmerge.py？

我们做了以下丑陋的事情：

那么，我们怎样才能实现另一个reintegrate呢？

到目前为止我尝试了什么？

• 好吧，明显的合并-残酷地失败了！
• 创建一个补丁并将其应用到trunk（应该可以工作，因为它只区分没有svn的文件......）
• 创建另一个分支@trunk r101 并合并第一个分支的所有更改 - 惨败:)

编辑：

主干的合并信息不显示所需分支的任何合并修订（因为我已使用 r101 将它们回滚）