当SVN与合并跟踪有效时，它非常好，我喜欢它。但它一直在扭曲。我们正在使用TortoiseSVN。我们不断收到以下消息：
错误：只有先前将修订版1234到2345从/ Trunk合并到重新集成源时才能使用重新集成，但事实并非如此
供参考，这是我们使用的方法：
我从主干到分支合并一系列修订（将范围留空，因此应该是所有修订），因此分支应该与之正确同步后备箱。
目前，Trunk具有多个与之关联的SVN合并跟踪属性。应该是？或者Reintegrate是否应该添加任何合并跟踪信息？
我们的流程有问题吗？这使SVN无法使用 - 每3个重新集成中就有1个迫使我潜入并破解合并跟踪信息。
答案 0 :(得分：10)
在过去从一个树干到另一个树枝进行了一次parial合并时，有时会发生这个问题。部分合并是指在整个树上执行合并但只提交部分合并时。这将为您提供树中的文件，这些文件的mergeinfo数据与树的其余部分不同步。
上面的--reintegrate错误消息应该列出svn遇到问题的文件（至少在svn 1.6中这样做）。
你可以：
使用错误消息中的范围，从trunk到branch手动合并问题文件。注意：您必须从范围的开头减去1，因此您运行的命令将是：
cd <directory of problem file in branch working copy>
svn merge -r1233:2345 <url of file in trunk>
svn commit
或
如果您确定分支中文件的内容正确并且您只想将文件标记为已合并，则可以使用--record-only标记svn merge：
cd <directory of problem file in branch working copy>
svn merge --record-only -r1233:2345 <url of file in trunk>
svn commit
（我认为你可以在整个树上使用--record-only，但我还没有尝试过，你必须绝对确定没有真正的合并需要来自主干）
答案 1 :(得分：3)
Bunny hopping可能是解决方案。
基本上，当您想要从trunk中提取这些更改时，不是将主干更改连续地合并到一个分支（branches/foo中，让我们称之为）：
branches/foo2）。branches/foo合并到branches/foo2）。branches/foo）。答案 2 :(得分：3)
你的问题是你试图通过已经完成“半合并”而在已经“损坏”的分支上使用Reintegrate merge。我的建议是忽略重新整合并坚持修改合并，如果这是你的工作流程。
然而，您收到错误的主要原因是SVN正在为您执行一些检查。在这种情况下，如果合并具有来自其中的单个文件的额外mergeinfo，则svn会抛出一个摇摆不定并阻止您合并 - 主要是因为这种情况可能会产生您可能不会注意到的产品错误。这在svn reintegrate术语中被称为subtree merge（阅读Reintegrate to the Rescue部分，特别是最后有争议的重新整合检查）。
您可以在执行中间合并时停止记录mergeinfo，或者只保留分支直到准备就绪 - 然后合并将获取对trunk进行的更改。我认为您也可以通过将整个主干合并到分支而不是单个文件来进行此检查，从而使mergeinfo在最后重新整合时保持安全。
编辑：
@randomusername ：我认为（从未过于密切）移动是因为它属于“部分合并”陷阱。 SVN的一个很酷的功能是你可以进行稀疏结账 - 只获得树的部分副本。当你合并一个部分树时，SVN不能说整个东西被合并，因为它显然不是，所以它稍微不同地记录mergeinfo。这对重新整合没有帮助，因为重新整合必须将所有合并回主干，现在它发现某些位被修改而没有被合并，所以它抱怨。移动看起来有点相同 - 分支树的一部分现在在mergeinfo中的显示方式与预期不同。我不打算重新整合，并坚持正常的修订范围合并。这是一个不错的主意，但在太多不同的情况下，它试图为太多的用户提供太多的东西。
答案 3 :(得分：0)
我怀疑你没有正确遵循合并说明：
“现在，使用svn merge和--reintegrate选项将分支更改复制回主干。你需要一个/ trunk的工作副本。你可以通过做一个svn checkout，从磁盘上的某个位置挖出旧的主干工作副本，或使用svn开关（请参阅“遍历分支”一节）。您的主干工作副本不能进行任何本地编辑或包含修订的混合< / strong>（请参阅“混合修订工作副本”一节）。虽然这些通常是合并的最佳实践，但在使用--reintegrate选项时需要它们。
一旦你有干净的工作副本，你就可以将你的分支合并回来了：“
我在合并方面遇到的问题很少。