Svn Subversion合并需要；旧式；即使一切看起来都是最新的？

我最近从一个旧的subversion服务器/存储库迁移到了最新版本1.8.9。新存储库是在新服务器上从头开始创建的，旧数据是从头开始导入的（我们从旧存储库中签出代码，在本地导出代码以删除所有SVN绑定，并以新的方式将其签入新存储库）

一切似乎都很好

我们已经使用这个新的存储库几个月了。我最近去把一根树枝并入树干。它抛出了大量可怕的树冲突。我无法理解这一点。主干和分支应该是同步的（主干中的所有内容也在分支中，唯一的新代码是分支中的代码，这就是我们试图合并的代码）。出于纯粹的挫败感，我单击了“重新整合而不是自动合并（旧式）”：

现在点击“合并”成功了

为什么我不明白？有人解释为什么会发生这种情况和/或这两种合并类型之间有什么区别吗？似乎没有关于这意味着什么的文档

我能看到的唯一一件可能有点不寻常的事情是，我们在某个点上从主干合并到分支（一些“紧急”的变化可能是为了生存）

相关版本号：

subversion : 1.8.9
Tortoise: 1.8.8
Repository : V6

我想知道“旧式”和“旧式”的实际区别是什么 融合与“新风格”

TortoiseSVN手册尚未更新，以涵盖新的自动重新整合合并功能，并且在您明确指定正在进行重新整合合并时仍然没有更新。以下是乌龟的新旧风格的区别：

旧式=

svn合并--重新整合

。在Subversion 1.7及更高版本中，您必须通过在命令行中添加

--reintegrate

选项来明确指定进行重新整合合并

新样式=

svn合并

<代码>--在Subversion 1.8+中不推荐重新集成选项。合并是否重新整合由Subversion客户端自动确定。不过，有三个先决条件——你的工作副本

• 无法进行任何本地编辑
• 不能切换路径
• 工作副本不得被复制

Subversion 1.8发行说明中描述了新的自动重新整合合并：

中还介绍了该功能。您可以比较本章以了解Subversion 1.7和1.8版本之间工作流的差异

乌龟1.7（“旧式”）与1.8（“新式”）行为的差异

也最好是解释为什么这会导致使用 新样式但不使用旧样式

---

如果看不到两次合并后工作副本的状态（有

--reintegrate

和没有它），我很难说出当时发生了什么，以及为什么指定

--reintegrate

会显式地改变行为）。我猜SVN 1.8未能检测到重新整合合并，因此您必须显式运行它。

1.8合并并不意味着“树冲突已成为历史”-它们仍然可以自然出现。我认为您缺少我的观点@lazybager。显然，可能会发生树冲突，但为什么旧式合并会阻止这种情况发生？请显示这两种类型的测试合并输出（

text/plain

TSVN输出类型）以及分支修订日志（其中包含

svn mv

）：未来树冲突的来源我现在已经完成了合并。我必须把它放到分支机构，以便在最后期限前发布到source。其实我只想知道有什么不同？似乎没有关于这些选项含义的文档。我在OrtoiseSVN 1.9.4中遇到了同样的问题：单击“测试合并”会与自动合并产生冲突，但使用“旧式”重新整合合并会得到正确的结果。然后我发现：这表明从命令行自动合并工作正常。所以我试着在OrtoiseSVN中点击“合并”（不先测试），而不检查“旧式”重新整合，然后。。。成功了！！因此，至少在版本1.9.4中，问题似乎仅限于“测试合并”预览功能。您能解释一下工作副本不能是混合版本吗？@Liam概念上的Subversion功能之一是，工作副本可以具有不同版本号的目录和文件。SVNBook中有一个很好的解释