Subversion可以正确处理两个方向的合并(主干< - >分支)?

时间:2012-01-09 13:00:36

标签: svn merge branching-and-merging merge-tracking

据我所知,最常见(和推荐)的方式来处理分支和在Subversion中合并是:

  • 将分支创建为trunk的副本
  • 在分支上进行破坏性开发,并在trunk上进行常规开发
  • 这样做时,定期合并更改主干 - >分支,以避免分支发散太多。使用合并跟踪(svn:mergeinfo),我可以运行svn merge ^/trunk,SVN将自动从主干中获取所有未合并的更改。
  • 完成分支​​上的工作后,将所有内容合并(在主干:svn merge --reintegrate ^/branch/foo上),然后丢弃分支。

(例如在SVN书中描述,Basic Merging章节)。

现在我的问题:虽然这适用于“功能分支”,但有时候还需要“发布分支”,它代表出货/即将出货的版本。

对于发布分支,根据我的经验,合并必须在两个方向进行:

  • 发布分支中的错误修复必须合并到主干(分支 - >主干)
  • 但有时从主干(甚至新功能)修复错误被认为对发布版本(或发布的更新)至关重要,因此必须合并主干 - >分支

我没有找到任何关于SVN和svn:mergeinfo如何处理这个问题的信息。我可以双向合并(“双向合并”),还有svn跟踪合并修订吗?

有任何陷阱吗?有什么特别需要注意的吗?

2 个答案:

答案 0 :(得分:2)

  

我可以双向合并(“双向合并”),还有svn跟踪合并修订吗?

是的,您可以合并各个功能(通过合并特定的修订版),SVN将跟踪它。

答案 1 :(得分:2)

实际上,在SVN中双向合并通常会导致更多的痛苦(与git相比)。问题是如果你将trunk合并到分支中,然后尝试将分支上的更改合并回trunk,SVN将尝试合并来自trunk的更改,这些更改将再次合并到分支中,这将导致许多不必要的冲突。要解决此问题,您可以“仅记录”在将分支合并到主干之前将主干合并到分支的提交。 有关一般方法,请参阅SVN手册中的Advanced Merging - Blocking Changes章节(但他们提供的示例不适用于该特定用例)。

示例:

  1. 假设您将trunk合并到分支中创建了两个提交r3857和r3858(我经常在使用NetBeans时看到它首先创建目录然后创建文件)。
  2. 然后你在该发布分支上做了一些额外的修复。
  3. 现在您要将其合并回主干。在此之前,请在trunk目录中执行以下操作:

    svn merge“^ / project / branches / release-0.1”-r3857:3858 - 仅限记录

  4. 像往常一样从release-0.1分支合并之后。与直接合并尝试相比,这将导致更少的冲突。

  5. 在提交之前,我有时会恢复一些引入的更改(特别是SVN可能由于某些原因在解决树冲突时在文件级引入svnmerginfo)。