Subversion分支重整合

Question

当一个分支被重新合并到主干后，该分支是否已经无效？

在重新合并之后，您是否可以对分支进行修改，并将其合并回主干的较晚时间？

- Aaron Smith

---

我猜你应该修改已接受的答案，因为它不再正确。这个问题在现代Subversion客户端中已经不存在了。 - bahrep

Answer 1

从技术上来说，你是可以这么做的，你的分支既没有死亡也没有被禁用，但是不建议在重新集成后从分支合并到主干。

你可以在这里找到关于原因的完整讨论：Subversion merge reintegrate

基本上，文章中提到，虽然可能将修改再次合并到主干，但由于重新集成强制你在重新集成操作之前从主干合并到分支，你将面临循环合并的问题，这在Subversion 1.5中非常棘手。
根据文章内容，建议在重新集成后立即删除已经重新集成的分支，并创建一个同名或不同名的新分支。

这是已知的Subversion行为，未来版本（可能是1.6版）将加以解决。

---

- Pini Reznik

---

有人知道在Subversion 1.6中是否解决了重新整合的问题吗？ - Bradley Dwyer

我已经在https://dev59.com/tnA75IYBdhLWcg3waIQJ中解释了svn v1.6的问题。简短版：是的，你可以多次重新整合。 :) - Andres Jaan Tack

Pini，你的“Subversion合并重新集成”的链接似乎已经失效或者需要一些认证才能访问Collabnet。你知道这篇文章是否可以在其他地方无需认证就能访问吗？ - Kaitsu

我认为这是原始文章： http://blogs.collab.net/subversion/2008/07/subversion-merg/这是早期讨论： http://svn.haxx.se/dev/archive-2007-11/0729.shtml - Pini Reznik

因回答已不再实用，所以进行了反对投票。 - bahrep

Answer 2

实际上，您需要在使用--reintegrate提交创建的版本修订的分支中，执行从主干到分支的--record-only合并：

$ cd trunk
$ svn merge --reintegrate ^my-branch 
$ svn commit

Committed revision 555. 
# This revision is ^^^^ important

现在你可以记录它了

$ cd my-branch
$ svn merge --record-only -c 555 ^trunk 
$ svn commit

你现在很乐意保留这个分支。

更多信息请见第4章 分支和合并，高级合并。

- krico

---

答案已过时。 - bahrep

Answer 3

当你从分支合并到主干后，你应该做以下两件事中的一件：

• 删除你的分支。这是最简单的方法，但它会使得分支的历史更难查看。

• 告诉你的分支不要合并重新集成的提交。如果你将分支重新集成到主干，并将其作为修订版本 X 提交，那么你可以在分支上运行此命令：svn merge --record-only -c X url-to-trunk。但是，如果你在提交中进行了除合并之外的任何更改，则不应进行此操作。其他任何更改都永远不会回到你的分支。

- JW.

Answer 4

如果有人多次对分支进行更改（1.5之前），以下是合并更改的建议：记住您进行合并的修订版本！要么在某处写下修订版本号，要么（更简单）创建一个标签。（当然，您以后可以找到它，但那很麻烦。）

示例：

您的存储库布局如下：

/your_project
  /trunk
  /branches
  /tags

假设这是一个Web应用程序，你计划发布。你将创建一个标签，并从那个标签（或主干）创建一个分支，在其中进行错误修复：

/your_project
  /trunk
  /branches
    /1.0.0-bugfixes
  /tags
    /1.0.0

通过这种方式，您可以将新功能集成到主干中。所有的错误修复都只会在错误修复分支中进行，在每次发布之前，您需要对当前版本（现在来自于错误修复分支）进行标记。

假设您已经进行了相当数量的错误修复，并将其发布到生产服务器上，您急需其中一个功能位于当前主干中：

/your_project
  /trunk
  /branches
    /1.0.0-bugfixes
  /tags
    /1.0.0
    /1.0.1
    /1.0.2

现在您可以直接将1.0.0和1.0.2之间的更改集成到您的主干代码中（假设您在您的工作副本中）：

svn merge http://rep/your_project/tag/1.0.0 http://rep/your_project/tag/1.0.2 .

以下是您需要记住的事情。您已经将1.0.0和1.0.2之间的更改合并到主干上。假设当前生产版本中存在更多更改：

/your_project
  /trunk
  /branches
    /1.0.0-bugfixes
  /tags
    /1.0.0
    /1.0.1
    /1.0.2
    /1.0.3
    /1.0.4

您现在已经准备好从主干版本发布新版本，但您的错误修复的最后更改仍然缺失：

svn merge http://rep/your_project/tag/1.0.2 http://rep/your_project/tag/1.0.4 .

现在您已经将所有更改合并到主干上，可以进行发布（不要忘记先进行测试）。

/your_project
  /trunk
  /branches
    /1.0.0-bugfixes
    /1.1.0-bugfixes
  /tags
    /1.0.0
    /1.0.1
    /1.0.2
    /1.0.3
    /1.0.4
    /1.1.0

- Mauli

Answer 5

不，分支仍然存在，但此时它与主干完全相同。如果您继续在分支上开发，稍后可以自由地重新与主干合并。

- Ben Hoffstein

---

只有日志不同。分支上的日志将更加详细，例如包含真实的作者。 - Hugo

请查看Pini Reznik的答案和其中引用的文章，了解为什么您不应继续使用该分支（即使在技术上是可能的）。 - mhagger

认真的，不要这样做。这会给你带来世间痛苦。删除分支，重新创建它。如果你不相信我，我会送你一个密封的罐子，里面装着我两周前悲伤的眼泪。 - detly

Answer 6

正如大家在这里已经说过的：该分支并没有死亡，可以继续提交到该分支。

有时候，在合并后你可能想要删除该分支。唯一可靠的解决方案是删除该分支。缺点是，如果你因历史原因想再次查看它，那么找到该分支就更难了。因此，许多人会将“重要”的分支保留下来，并达成不更改它们的协议。我希望有一种方法可以标记一个死/只读分支，从而确保在另行通知之前，没有人可以向其提交。

- Alexander

---

svn mv ^/branches/foo ^/branches/.dead/foo - user256434

Answer 7

首先，如果您仍在使用Subversion 1.7或更早版本，则应升级您的Subversion客户端和服务器。没有理由使用非常老的Subversion版本。截至2016年，当前版本为Subversion 1.9。现在还支持SVN 1.8并且仍然接收错误修复。

您所提出的问题已在Subversion 1.8中解决。从SVN 1.8开始，--reintegrate选项已被弃用。重新集成合并现在将自动执行。请参见与改进相关的Subversion 1.8发行说明条目。

阅读 SVNBook 1.8 | 重新集成分支：

如果您选择在将分支重新整合到主干后不删除它，则可以继续从主干执行同步合并，然后再次重新整合该分支。如果这样做，仅会将第一次重新整合后在分支上进行的更改合并到主干中。

只有Subversion 1.8支持重用特性分支。早期版本需要在多次重新整合特性分支之前进行一些特殊处理。有关更多信息，请参见本章的早期版本: http://svnbook.red-bean.com/en/1.7/svn.branchmerge.basicmerging.html#svn.branchemerge.basicmerging.reintegrate

- bahrep

Answer 8

您可以随意将分支合并到主干，或将主干合并到分支中。

- Chris Marasti-Georg

Answer 9

当你执行合并操作时，需要指定目标。如果需要，你可以将TreeA和TreeB的差异合并到TreeC中。正如Chris所暗示的那样，你的问题并没有太多意义。如果将你的分支合并到主干上，分支将保持不变。如果之后不再需要该分支，你可以将其删除。

- Jonah Braun

Answer 10

你可以继续在分支上开发，你需要的功能是合并跟踪，它在Subversion 1.5中可用，这意味着从分支进行的额外合并仅包括新更改。

- Douglas Leeder