我一直在阅读几天，试图找到一种方法来使用tortiseSVN 1.8来解决树冲突。我有两个分支机构：
同样，这两个分支都脱离了树干。我们不在主干上进行“主线”开发。我正在尝试将3.1分支的更改合并到3.2分支。
3.1中的代码经历了一些重构，3.1分支中存在的许多文件夹不再存在于3.1分支中。此外，还有一些新工作添加到3.2的新文件夹。问题是树冲突不能让我找到解决冲突的方法，但只允许我接受工作副本。这似乎是一个严重的缺陷。我们正在进行大量的重构，我正在寻找一个流程，我们可以将早期版本分支的更改集成到更高版本的分支中。
有人可以告诉我处理这件事的最佳方法吗？
答案 0 :(得分：0)
要合并工作，您需要两件事：
合并冲突的发生是因为合并是一种三方比较。将两个开发流（开发流可以指代分支或主干）相互比较，并将它们与它们的最后共同祖先进行比较。想象一下两个开发流中改变了＃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.2上的更改是您想要的3.2。
这是一个漫长的过程，但你需要完成它。将此作为改进开发过程的课程。
我们使用听起来像你使用的类似系统的东西。 Trunk被认为是 pristine 并匹配我们的版本（它从未真正做过）。我们一直在从一个版本到另一个版本丢失更改，因为当我们创建一个新分支时，以及当我们将前一个分支合并到主干（或者我们只是丢失了我们分支的地方）时。
分支就像孩子一样：你制造一个，你最好准备好照顾它，不要忘记它去哪里。
我们切换到持续开发流程。我们在trunk上进行开发，然后在发布之前进行分支。分支点通常出现在我们完成该版本的所有功能的时候，我们现在正处于修复bug的过程中。
发布在分支上完成。如果我们发现错误，我们将修复分支上的错误，然后只将该修订合并到主干（如果该错误也在主干上）。一旦发布完成，分支就会被锁定。如果我们需要执行修补程序，我们可以将该分支重用于此修补程序。
有时，我们有功能分支。当我们这样做时，我确保我们不断地从开发流合并到该功能分支。这样，当我们最终将该功能重新集成到主干中时，我们几乎没有任何冲突。
通过将分支保持在最低限度并跟踪我们从哪里进行分支，并进行常量合并（如在功能分支中），我们减少了合并冲突，并且不再存在曾经困扰我们发布的问题。