什么时候重新整合选项真的有必要？

Question

如果始终在合并功能分支之前同步功能分支.为什么你真的必须使用这个--reintegrate选项？

Subversion的书说:

然而,当将你的分支合并回主干时,基础数学是完全不同的.您的功能分支现在是重复主干更改和私有分支更改的混合,因此没有简单的连续修订版本可供复制.通过指定--reintegrate选项,您要求Subversion仅仔细复制您的分支特有的更改.(事实上​​,它通过将最新的树干树与最新的树枝树进行比较来实现这一点:产生的差异正是你的树枝变化!)

因此,该--reintegrate选项仅合并功能分支唯一的更改.但是如果你总是在合并之前进行同步(这是一种推荐的做法,为了处理功能分支上的任何冲突),那么分支之间的唯一变化就是功能分支独有的变化,对吧？如果Subversion尝试合并已经在目标分支上的代码,它就什么都不做,对吧？

在一篇博文中,Mark Phippard写道:

如果我们包含那些同步修订,那么我们合并回已经存在于trunk中的更改.这会产生不必要和令人困惑的冲突.

是否有一个例子表明何时放弃重新融合会给我带来不必要的冲突？

Answer 1

让我解释什么时候--reintegrate绝对必要.

考虑以下用例.

1. 你有p1/trunk下的项目p1.该项目有一个文件,有一行"line1"<readme.txt
2. 创建一个新分支,p1/branches/br1
3. 留在行李箱里.添加"line2"行readme.txt并将其提交到trunk
4. 切换到p1/branches/br1分支.更新到HEAD.
5. 从主干合并到此分支(以获取主干更改).
6. 你应该拥有line1和line2进入readme.txt
7. Commit将结果合并到p1/branches/br1分支
8. 切换到主干.更新到HEAD.
9. 合并来自 p1/branches/br1 to trunk.
   1. 你会看到line1,line2并line2在readme.txt.所以,你有两次"line2"是不正确的.SVN没有显示任何冲突.所以,这是非常危险的,因为合并执行没有错误,你会觉得一切都很好.

这里的解决方案是使用--reintegrate选项完成步骤9合并.reintegrate选项告诉SVN br1与trunk 比较并仅应用br1对trunk的更改.在这个特殊情况下,我们没有做任何改变br1.trunk中的结果应该是两行"line1"和"line2".

另一个有用的评论 p1/branches/br1在步骤9之后不应该使用分支进行开发.如果要在分支中继续开发,请创建一个新分支,例如p1/branches/br2.从trunk进行的另一次合并p1/branches/br1会导致很多冲突.