如何解决SVN树冲突

Question

我已经阅读了几天，试图找到一种使用tortiseSVN 1.8解决树冲突的方法。 我的主干有两个分支：

• 分支/ 3.1
• 支链/ 3.2

同样，这两个分支都不是主干。 我们不在主干上进行“主线”开发。 我正在尝试将3.1分支的更改合并到3.2分支。

3.1中的代码经过了一些重构，并且3.2分支中存在的许多文件夹在3.1分支中不再存在。 此外，还有一些新工作将新文件夹添加到3.2。 问题是树冲突没有给我解决冲突的方法，而只允许我接受工作副本。 这似乎是一个严重的缺陷。 我们正在进行大量的重构，我正在寻找一个过程，可以将早期版本分支上的更改集成到以后版本分支中。

有人可以告诉我最好的方法吗？

Answer 1

要进行合并，您需要做两件事：

• 您需要两个分支之间有共同的血统。
• 如果您将两个分支保持同步，则需要在两个分支之间进行常规合并。 例如，我假设所有在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.2上需要对3.1进行更改。

这是一个漫长的过程，但是您需要完成它。 将其用作改进您的开发过程的课程。

---

我们曾经使用听起来像您所使用的类似系统的东西。 Trunk被认为是原始的，并且与我们的发行版相匹配（从来没有真正做到过）。 由于创建新分支以及将先前的分支合并到主干（或者只是丢失了从何处分支），我们一直在丢失从一个版本到另一个版本的更改。

分支就像孩子：您创造了一个分支，最好准备好照顾它，而不要迷失方向。

我们转向了持续发展的过程 。 我们在主干上进行开发，然后在发布之前进行分支。 分支点通常在我们完成该版本的所有功能时出现，并且我们现在正在进行错误修复。

发布在分支上完成。 如果发现错误，则将在分支上修复该错误，然后仅将该修订合并到主干（如果该错误也在主干上）。 发布完成后，分支将被锁定。 如果我们需要做一个修补程序，我们可以将该分支重新用于该修补程序。

有时，我们有功能分支 。 当我们这样做时，我确保我们不断地从开发流合并到该功能分支。 这样，当我们最终将该功能重新集成到主干中时，几乎没有冲突。

通过最小化分支并跟踪我们从何处分支，并进行恒定合并（如在功能分支中进行合并），我们减少了合并冲突，并且不再遇到曾经困扰我们发行版的问题。