svn - 什么时候真正需要重新整合选项？

Question

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

颠覆书说:

When merging your branch back to the trunk, however, the underlying mathematics is quite different. Your feature branch is now a mishmosh of both duplicated trunk changes and private branch changes, so there's no simple contiguous range of revisions to copy over. By specifying the --reintegrate option, you're asking Subversion to carefully replicate only those changes unique to your branch. (And in fact, it does this by comparing the latest trunk tree with the latest branch tree: the resulting difference is exactly your branch changes!)

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

在 a blog post ，马克·菲帕德写道:

If we include those synched revisions, then we merge back changes that already exist in trunk. This yields unnecessary and confusing conflicts.

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

Answer 1

让我解释一下--reintegrate是绝对必要的。

考虑以下用例。

您在 p1/trunk 下有项目 p1。该项目有一个文件，readme.txt , 一行 "line1"<

创建一个新分支，p1/branches/br1

留在后备箱里。将“line2”行添加到 readme.txt并将其提交到主干

切换到p1/branches/br1分支。更新到 HEAD。

从主干合并到此分支(以获取主干更改)。

你应该有 line1和 line2在 readme.txt

提交合并结果到p1/branches/br1分公司

切换到主干。更新到 HEAD。

从 p1/branches/br1 to trunk. 合并

你会看到 line1 , line2和 line2在 readme.txt .所以，你有两次“line2”，这是不正确的。 SVN 没有显示任何冲突。因此，这是非常危险的，因为合并执行时没有错误，并且您的印象是一切都很好。

这里的解决方案是第 9 步合并应该使用 --reintegrate 来完成。选项。 reintegrate 选项告诉 SVN 比较 br1带主干，仅适用 br1更改为中继。在这种特殊情况下，我们没有对 br1 进行任何更改。 .主干中的结果应该是两行“line1”和“line2”。

另一个有用的评论。分公司 p1/branches/br1在第 9 步之后不应再用于开发。如果要在分支中继续开发，请新建一个分支，例如 p1/branches/br2 .另一个从主干合并到 p1/branches/br1导致很多冲突。