什么时候真正需要重新整合选项? [英] When is the reintegrate option really necessary?

查看:86
本文介绍了什么时候真正需要重新整合选项?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

如果始终先同步功能分支,然后再将其合并回.为什么您真的必须使用--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.

请考虑以下用例.

  1. 您在 p1/trunk 下有项目 p1 .该项目有一个文件readme.txt,其中一行"line1"<
  2. 创建一个新分支 p1/branches/br1
  3. 留在后备箱中.将行"line2"添加到readme.txt并将其提交到主干
  4. 切换到p1/branches/br1分支.更新到HEAD.
  5. 从中继线合并到此分支(以提取中继线更改).
  6. readme.txt
  7. 中应该有line1line2
  8. 提交结果合并到p1/branches/br1分支
  9. 切换到中继.更新到HEAD.
  10. p1/branches/br1 to trunk.合并
  1. you have project p1 under p1/trunk. The project has a file, readme.txt, with one line "line1"<
  2. Create a new branch, p1/branches/br1
  3. Stay in trunk. Add line "line2" to readme.txt and commit it to trunk
  4. Switch to the p1/branches/br1 branch. Update to HEAD.
  5. Merge from trunk to this branch (to pick up trunk changes).
  6. You should have line1 and line2 in readme.txt
  7. Commit merge the result to p1/branches/br1 branch
  8. Switch to trunk. Update to HEAD.
  9. Merge from p1/branches/br1 to trunk.
  1. 您将在readme.txt中看到line1line2line2.因此,您有两次"line2",这是不正确的. SVN不显示任何冲突.因此,这是非常危险的,因为合并没有错误,并且您印象中一切都很好.
  1. You'll see line1, line2 and line2 in readme.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屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆