我们一直在试验一种新技术来管理我们的发布分支。
通常，我们在主干上维护当前版本，并为每个版本创建发布分支。发布分支是通常进行积极开发的地方，主干用于修复当前版本的错误。
我们定期将主干中的错误修复合并到发布分支（每周）。
现在我们已经准备好发布另一个版本，我们想将发布分支合并到主干中。不幸的是，这会导致许多冲突（> 50）。一开始我很惊讶，但现在我明白了，Subversion 不能轻易地用主干中的内容来纠正分支中的更改。
有没有办法告诉 Subversion 在重新集成到主干时使用分支中的所有文件版本？我们知道文件的分支版本是“正确的”。
作为替代方案，理论上我们可以放弃主干，只在分支上工作——从分支分支进行发布。
我们使用 TortoiseSVN 和 Subclipse。
【问题讨论】：
标签： svn
来自svn help merge的输出：
--accept ARG
指定自动冲突解决动作 （'推迟'，'基地'，'地雷冲突'，'他们的冲突'，'地雷满'， 'theirs-full', 'edit', 'launch')
要在合并到主干时接受分支更改，您需要“--accept theirs-full”选项。
我认为 TortoiseSVN 1.6.2 在 GUI 中没有等效选项。您仍然可以通过选择“use repository”来interactively resolve conflicts，因为在合并过程中会遇到每个冲突。
【讨论】：
我相信您通过将错误修复从主干复制到您的发布分支所做的事情有时称为rebasing。在这种情况下，所有变基意味着您采用一个通常基于主干的修订版 r49 的分支，并将来自主干的 r50-r57 的更改合并到分支中，以便您现在可以将该分支视为基于修订版主干的 r57 而不是修订版 r49。
实践中的问题是，当将主干或任何其他基础的一系列修订合并到其中一个分支时，它不会重置创建该分支的基础修订，而是保留正常的mergeinfo属性是了解已合并内容的唯一方法。为了能够将来自分支的更改重新集成回其基础（例如主干），而不会无意中重播合并的基础更改，例如在我之前的示例中从 r50-r57 将通过樱桃合并从分支到基础的更改以不包括由变基（从基础合并到分支）引起的任何修订的方式选择特定修订。
不幸的是，除了由 Subversion 开发人员实施一种方法来自动执行此操作之外，只有不包含合并信息属性的修订版描述了仅包含原始基本修订版和目标修订版之间的修订版的合并基地（通常是HEAD）。这变得更加复杂，因为合并通常包括与合并提交一起提交的手动更改，这些更改将丢失，并且任何给定对象的起源都必须追踪到它的共同祖先才能使其工作正确地在staircased 分支上。除此之外，允许将分支替换为基础或主干的较新副本并将所有以前的提交作为一系列单独的提交重新应用的功能也将使这成为可能，但是笨拙的行为更像是真正的变基.
这些 cmets 不是一个明确的答案，但代表了我作为 Subversion 长期用户的理解。如果有人有任何其他要添加的内容或可以在我的陈述中挑选出一些可能不正确的内容，请务必让我知道，以便我们能够真正了解 Subversion 当前实现的功能和限制。
更新： 根据 Subversion 文档，似乎在使用 --reintegrate option 时，Subversion 应该能够正确地重新集成在分支中完成的工作，以考虑任何可能的刷新合并已完成将基本更改带入分支。当然，这在技术上与变基有点不同，但我认为它在使用上足够相似，可以称为变基。现在的主要问题是 --reintegrate 选项是否在 base 的更改以樱桃挑选的方式合并到主干时是否有效，而不是合并从 BASE+NEXT 到 HEAD 的所有内容。
更新：似乎cherry picking should be supported 在使用 Subversion 1.5 及更高版本的 svn merge --reintegrate 选项时也是如此。遵循这些说明应该可以让您重新集成，而不会由于重新引入变基更改修订而导致意外冲突。
有关详细信息，请阅读标题为 Keeping a Branch in Sync 的部分下的 Subversion 书籍。
【讨论】：
也许我在这里遗漏了一些东西，但听起来最简单的选择是删除主干并通过从新版本分支分支重新创建它。
【讨论】：
理论上，您可以“合并两棵不同的树”，从树干的头部到树枝的头部。这应该避免由于重新集成而引起的任何奇怪的冲突。
【讨论】：