什么时候真正需要重新整合选项? [英] When is the reintegrate option really necessary?
问题描述
如果始终先同步功能分支,然后再将其合并回.为什么您真的必须使用--reintegrate
选项?
If you always synchronise a feature branch before you merge it back. Why do you really have to use the --reintegrate
option?
Subversion书中说:
The Subversion book says:
但是,将分支合并回主干时,基础数学却大不相同.现在,您的功能分支是重复的主干更改和私有分支更改的混合体,因此没有简单的连续修订版本可以复制.通过指定--reintegrate选项,您要求Subversion仅仔细复制您分支唯一的那些更改. (实际上,它是通过将最新的主干树与最新的分支树进行比较来实现的:所产生的差异正是您的分支更改!)
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尝试合并目标分支上已经存在的代码,它将什么都不做,对吗?
So the --reintegrate
option only merges the changes that are unique to the feature branch. But if you always synchronise before merge (which is a recommended practice, in order to deal with any conflicts on the feature branch), then the only changes between the branches are the changes that are unique to the feature branch, right? And if Subversion tries to merge code that is already on the target branch, it will just do nothing, right?
Mark Phippard在博客帖子中写道:
In a blog post, Mark Phippard writes:
如果我们包括这些同步的修订,则我们将合并已经存在于主干中的更改.这会产生不必要的混乱冲突.
If we include those synched revisions, then we merge back changes that already exist in trunk. This yields unnecessary and confusing conflicts.
有没有一个例子说明何时放弃重新整合会给我带来不必要的冲突?
Is there an example of when dropping reintegrate gives me unnecessary conflicts?
推荐答案
让我解释一下何时--reintegrate
是绝对必要的.
Let me explain when --reintegrate
is absolutely necessary.
请考虑以下用例.
- 您在 p1/trunk 下有项目 p1 .该项目有一个文件
readme.txt
,其中一行"line1"< - 创建一个新分支 p1/branches/br1
- 留在后备箱中.将行"line2"添加到
readme.txt
并将其提交到主干 - 切换到
p1/branches/br1
分支.更新到HEAD. - 从中继线合并到此分支(以提取中继线更改).
-
readme.txt
中应该有 - 提交结果合并到
p1/branches/br1
分支 - 切换到中继.更新到HEAD.
- 从
p1/branches/br1 to trunk.
合并
line1
和line2
- you have project p1 under p1/trunk. The project has a file,
readme.txt
, with one line "line1"< - Create a new branch, p1/branches/br1
- Stay in trunk. Add line "line2" to
readme.txt
and commit it to trunk - Switch to the
p1/branches/br1
branch. Update to HEAD. - Merge from trunk to this branch (to pick up trunk changes).
- You should have
line1
andline2
inreadme.txt
- Commit merge the result to
p1/branches/br1
branch - Switch to trunk. Update to HEAD.
- Merge from
p1/branches/br1 to trunk.
- 您将在
readme.txt
中看到line1
,line2
和line2
.因此,您有两次"line2",这是不正确的. SVN不显示任何冲突.因此,这是非常危险的,因为合并没有错误,并且您印象中一切都很好.
- You'll see
line1
,line2
andline2
inreadme.txt
. So, you have "line2" two times which is incorrect. SVN does not show any conflicts. So, it is very dangerous because merge performed with no errors and you are under impression that everything is fine.
这里的解决方案是应该使用--reintegrate
选项完成第9步的合并. reintegrate选项告诉SVN将br1
与主干进行比较,并且仅将br1
更改应用于主干.在这种特殊情况下,我们在br1
中未做任何更改.干线中的结果应为两行"line1"和"line2".
The solution here is that the step 9 merge should be done using the --reintegrate
option. The reintegrate option tells SVN to compare br1
with trunk and apply only br1
changes to trunk. In this particular case we have not done any changes in br1
. The result in trunk should be two lines "line1" and "line2".
另一个有用的评论.步骤9之后的分支p1/branches/br1
不应再用于开发.如果要继续在分支中进行开发,请创建一个新分支,例如p1/branches/br2
.从中继线到p1/branches/br1
的另一次合并会引起很多冲突.
Another useful remark. Branch p1/branches/br1
should not be used for development after step 9 anymore. If you want to continue development in branches, create a new branch, for example, p1/branches/br2
. Another merge from trunk to p1/branches/br1
causes lots of conflicts.
这篇关于什么时候真正需要重新整合选项?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!