什么时候真正需要重新集成选项？
如果您总是在合并回功能分支之前同步它。为什么你真的必须使用 --reintegrate 选项？
《颠覆》一书中说：
然而，当将分支合并回主干时，底层的数学原理是完全不同的。您的功能分支现在是重复的主干更改和专用分支更改的混合体，因此没有简单的连续修订范围可供复制。通过指定 --reintegrate 选项，您要求 Subversion 仔细复制您的分支特有的那些更改。 （事实上，它是通过比较最新的主干树和最新的分支树来实现这一点的：所得的差异正是您的分支更改！）
因此 --reintegrate 选项仅合并唯一的更改到功能分支。但是，如果您始终在合并之前进行同步（这是推荐的做法，以便处理功能分支上的任何冲突），那么分支之间的唯一更改就是功能分支特有的更改，对吧？如果 Subversion 尝试合并目标分支上已有的代码，它不会执行任何操作，对吧？
在博客文章中，Mark Phippard 写道：
如果我们包含这些同步修订，那么我们将合并回主干中已存在的更改。这会产生不必要且令人困惑的冲突。
有没有一个例子说明何时放弃重新整合会给我带来不必要的冲突？
If you always synchronise a feature branch before you merge it back. Why do you really have to use the --reintegrate option?
The Subversion book says:
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!)
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?
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
让我解释一下什么时候
--reintegrate是绝对必要的。考虑以下用例。
readme.txt，其中一行“line1”<readme.txt中，并将其提交到 trunkp1/branches/br1分支。更新到 HEAD。readme.txt中应该有line1和line2p1/branches/br1分支p1/branches/br1 合并到 trunk。readme.txt中看到line1、line2和line2。所以，你有两次“line2”，这是不正确的。 SVN没有显示任何冲突。所以，这是非常危险的，因为合并执行时没有错误，而且你会觉得一切都很好。这里的解决方案是第 9 步合并应该使用
--reintegrate选项完成。重新集成选项告诉 SVN 将br1与 trunk 进行比较，并仅将br1更改应用于 trunk。在这种特殊情况下，我们没有对br1进行任何更改。 trunk 中的结果应该是两行“line1”和“line2”。另一个有用的评论。第 9 步之后分支
p1/branches/br1不应再用于开发。如果您想继续在分支中进行开发，请创建一个新分支，例如p1/branches/br2。从 trunk 到 p1/branches/br1 的另一次合并会导致大量冲突。Let me explain when
--reintegrateis absolutely necessary.Consider the following use case.
readme.txt, with one line "line1"<readme.txtand commit it to trunkp1/branches/br1branch. Update to HEAD.line1andline2inreadme.txtp1/branches/br1branchp1/branches/br1 to trunk.line1,line2andline2inreadme.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.The solution here is that the step 9 merge should be done using the
--reintegrateoption. The reintegrate option tells SVN to comparebr1with trunk and apply onlybr1changes to trunk. In this particular case we have not done any changes inbr1. The result in trunk should be two lines "line1" and "line2".Another useful remark. Branch
p1/branches/br1should 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 top1/branches/br1causes lots of conflicts.从来没有必要使用
--reintegrate；这是一个方便。如果您最近从trunk到feature-branch的合并合并了自您分支到修订版以来，那么你可以使用以下命令。trunk中发生的所有更改rev请注意，此命令将在
trunk的最新工作副本的根目录中运行，并且不会提交任何未完成的更改。让我扩展我的答案，以更直接地回答这个问题“是否有一个例子说明何时放弃重新集成会给我带来不必要的冲突？”
这篇文章的意思是“如果我们包含这些同步修订，那么我们将合并主干中已存在的更改。这会产生不必要且令人困惑的冲突。”
包含同步修订版将如下所示：
其中
.是 trunk 的干净工作副本，N是创建feature-branch的修订版来自主干。该合并命令合并自分支以来提交给feature-branch的所有更改，包括在feature-branch< 之后从trunk合并的更改/代码> 已创建。这意味着对trunk所做的更改将包含在上面的合并中。您会告诉 Subversion 将实际源自trunk的更改应用到trunk，这会导致冲突。It is never necessary to use
--reintegrate; it's a convenience. If your most recent merge fromtrunktofeature-branchmerged all of the changes that occurred intrunksince you branched up to revisionrev, then you could use the following command.Note that this command would be run in the root of an up-to-date working copy of
trunkwith no outstanding changes to be committed.Let me expand my answer to more directly answer the question "Is there an example of when dropping reintegrate gives me unnecessary conflicts?"
Here's what the article means by "If we include those synched revisions, then we merge back changes that already exist in trunk. This yields unnecessary and confusing conflicts."
Including the synched revisions would look like this:
Where
.is a clean working copy of trunk andNis the revision thatfeature-branchwas created fromtrunk. That merge command merges all of the changes committed to thefeature-branchsince it was branched, including those changes that were merged fromtrunkafter thefeature-branchwas created. That means changes already made totrunkwould be included in the merge above. You'd be telling Subversion to apply changes totrunkthat actually originated intrunk, which results in conflicts.我认为马克意味着它避免了比较两个已修改的文件，一个是从分支重新集成的文件，一个是在主干中的相应文件，当两个文件都已同步时（而不仅仅是在各自的分支中本地更改）。
假设我们有
trunk/ac和branches/dev/ac，其中trunk/ac在某个时刻被修改并重新集成到分支中后来合并。正如您所指出的，在将所有东西放回后备箱之前这样做是一个很好的做法。因此，下一步将合并回主干，其中
ac在两侧都是“不同的”，因为它们在两个位置都发生了变化。如果没有该选项，将会出现不必要的比较，而--reintegrate将使 SVN 看到更改不仅仅是本地的。I think that Mark means it avoids comparing two files which have been modified, one to reintegrate from the branch and its corresponding file in the trunk, when both have been synchronized (and not just changed locally in their respective branch).
Let's assume we have
trunk/a.candbranches/dev/a.c, withtrunk/a.cmodified at some point and re-integrated in the branch later with a merge. As you pointed out, it's a good practice to do that before putting everything back to the trunk.So the next step would be that merging back to the trunk, where
a.care "different" on both sides since they have changed at both locations. Without the option there will be an unnecessary comparison, wheras the--reintegratewill make SVN see the change was not just local.从来没有必要使用
--reintegrate——它只是一个别名。如果您有trunk的工作副本，则与相同。
您可以使用您更熟悉的任何一个
It’s never necessary to use
--reintegrate— it’s simply an alias. If you have a working copy oftrunk, thenis the same as
You can use whichever one you’re more comfortable with.