我已经阅读了好几天，试图找到一种使用 tortiseSVN 1.8 解决树冲突的方法。 我的树干有两个分支：
- 分支/3.1
- 分支/3.2
同样，这两个分支都脱离了树干。我们不在主干上进行"主线"开发。 我正在尝试将更改从我们的 3.1 分支合并到我们的 3.2 分支。
3.1中的代码经过了一些重构，3.2 分支中存在的许多文件夹在 3.1 分支中不再存在。此外，还有一些新工作将新文件夹添加到 3.2。 问题是树冲突没有给我解决冲突的方法，而只允许我接受工作副本。 这似乎是一个严重的缺陷。 我们正在做大量的重构，我正在寻找一个可以将早期版本分支上的更改集成到更高版本分支的过程。
有人可以告诉我处理这个问题的最佳方法吗？
要合并工作，您需要两件事：
- 您需要两个分支之间的共同祖先。
- 如果您保持两个分支同步，则需要在两者之间进行定期合并。例如，我假设 3.1 上的所有工作都应该在 3.2 中。当您在这两个分支中工作时，您应该将 3.1 更改合并到 3.2 中。
发生合并冲突是因为合并是三向比较。两个开发流（开发流可以指分支或主干）相互比较，并将它们与它们的最后一个共同祖先进行比较。假设一个文件，其中 #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.1 上的修复不会在 3.2 上完成。或者，如果您在 3.1 中进行了不希望在 3.2 上进行的更改，则执行--record-only将阻止您在下次合并时考虑对 3.2 分支的更改。
现在怎么办？你需要理清你的工作。查看两个分支之间的svn log。如果你看到两个分支上都发生了错误修复，请使用svn merge --record-only让 Subversion 知道 3.1 分支上的特定更改也在 3.2 分支上完成（尽管是手动的）。查看文件移动和重命名，并查看它们在每个分支上的完成情况。
完成此操作后，将 3.1 上的更改合并到 3.2 一次几个修订版，樱桃选择合并。确保 3.1 上的更改是您想要的 3.2
。这是一个漫长的过程，但你需要完成。以此为教训来改进您的开发过程。
我们习惯使用听起来像您使用的类似系统。Trunk应该是原始的，与我们的版本相匹配（它从来没有真正做到过）。我们不断丢失从一个版本到另一个版本的更改，因为我们何时创建了一个新分支，以及何时将以前的分支合并到 trunk（或者我们只是丢失了分支的位置）。
分支就像孩子：你做一个，你最好准备好照顾它，不要忘记它的去向。
我们切换到了持续开发过程。我们在主干上进行开发，然后在发布之前进行分支。分支点通常在我们完成该版本的所有功能时出现，我们现在正处于错误修复过程中。
发布是在分支上完成的。如果我们发现一个错误，我们将修复分支上的错误，然后只将该修订版合并到主干中（如果该错误也在主干上）。释放完成后，分支将被锁定。如果我们需要执行修补程序，我们可以将该分支重用于修补程序。
有时，我们有功能分支。当我们这样做时，我确保我们不断从开发流合并到该功能分支。这样，当我们最终将该功能重新集成到主干中时，我们几乎没有冲突。
通过将分支保持在最低限度，并通过跟踪我们从哪里分支，并进行不断的合并（就像在功能分支中一样），我们减少了合并冲突，并且不再有曾经困扰我们发布的问题。