我已经阅读了几天，试图找到一种使用 tortiseSVN 1.8 解决树冲突的方法。我有两个主干分支：
同样，这两个分支都脱离了树干。我们不在主干上进行“主线”开发。我正在尝试将 3.1 分支的更改合并到 3.2 分支。
3.1 中的代码经过了一些重构，3.2 分支中存在的许多文件夹在 3.1 分支中不再存在。此外，还有一些新工作将新文件夹添加到 3.2。问题是树冲突并没有给我解决冲突的方法，而只允许我接受工作副本。这似乎是一个严重的缺陷。我们正在进行大量重构，我正在寻找一种可以将早期版本分支上的更改集成到后期版本分支中的过程。
谁能告诉我最好的处理方法？
【问题讨论】：
标签： svn tortoisesvn tree-conflict
要合并工作，您需要两件事：
发生合并冲突是因为合并是一种三向比较。将两个开发流（开发流可以指分支或主干）相互比较，并将它们与它们的最后一个共同祖先进行比较。想象一个文件，其中第 100 行在两个开发流中都发生了更改。从一个合并到另一个会导致冲突。
Subversion 不只是区分文件，它也区分目录。如果我在一个开发流中重命名一个文件（或移动它），然后我进行合并，它将在另一个开发流中重命名（或移动）。如果我在一个开发流中删除或添加一个文件，然后合并，它也会在另一个开发流中被删除或添加。
在 Subversion 中，如果我对两个开发流上的同一个文件执行两个不同的操作，可能会发生 树冲突。例如，我重命名了 3.1 和 3.2 分支上的文件。即使我将它们重命名为相同的名称，Subversion 也会将其视为冲突。
为了防止您的灾难再次发生：确保您的两个分支确实共享相同的祖先。为什么不从 3.1 分支分支 3.2，或者至少在分支 3.2 之前将 3.1 分支重新整合回主干。 Subversion 通常很擅长跟踪历史记录，但您需要确保分支共享一个共同的历史记录。
另一个是常规合并。您需要定期将 3.1 合并到 3.2 分支——甚至可能每天。这可以确保在 3.2 分支上工作的人在 3.1 中拥有他们需要的更改，并且不会重复工作。不断合并还可以使更改保持较小，并且当存在合并冲突时，它们更容易处理。请记住svn mergeinfo 命令，它可以让您知道哪些内容已合并到 3.2 中，哪些内容仍需要合并到 3.1 中。您始终可以使用--record-only 参数来防止将特定修订版考虑用于将来的合并。例如，您修复了两个分支上的错误，您使用--record-only 确保未在 3.2 上完成对 3.1 的修复。或者，如果您在 3.1 中进行了您不希望在 3.2 上进行的更改，则执行 --record-only 将阻止您在下一次合并时考虑在 3.2 分支上进行该更改。
现在该怎么办？你需要解开你的工作。查看两个分支之间的svn log。如果您看到两个分支上都发生了错误修复，请使用svn merge --record-only 让 Subversion 知道 3.1 分支上的特定更改也在 3.2 分支上完成（尽管是手动）。查看文件移动和重命名，看看它们是如何在每个分支上完成的。
完成此操作后，一次将 3.1 的更改合并到 3.2 的几个修订版，cherry pick 合并。确保 3.1 上的更改是您想要在 3.2 上进行的更改。
这是一个漫长的提取过程，但您需要完成。以此为教训，改进您的开发过程。
我们使用听起来像您使用的类似系统的系统。 Trunk 被认为是原始并与我们的版本相匹配（它从未真正做到过）。我们不断丢失从一个版本到另一个版本的更改，因为当我们创建了一个新分支以及将前一个分支合并到主干时（或者我们只是丢失了分支的位置）。
分支就像孩子：你造一个，你最好准备好照顾它，不要迷失它的去向。
我们切换到持续开发过程。我们在主干上进行开发，然后在发布之前进行分支。分支点通常在我们完成该版本的所有功能时出现，我们现在正在修复错误。
发布在分支上完成。如果我们发现一个错误，我们将修复分支上的错误，然后只将该修订合并到主干（如果该错误也在主干上）。一旦发布完成，分支就会被锁定。如果我们需要做一个修补程序，我们可以将该分支重用于修补程序。
有时，我们有功能分支。当我们这样做时，我会确保我们不断地从开发流合并到该功能分支。这样，当我们最终将该功能重新集成回主干时，我们几乎没有冲突。
通过将分支保持在最低限度并跟踪我们从哪里分支，并进行不断的合并（例如在功能分支中），我们减少了合并冲突，并且不再有曾经困扰我们发布的问题。
【讨论】：