svn：合并工作流程的细微差别

Question

我们有一个包含主干，偶尔的功能分支和一些持久开发者分支的存储库（因为我们每个都在项目的特定区域工作）。

行李箱由我们的项目经理管理，除紧急情况外，他是唯一一个将分支重新集成到行李箱中的人。重新整合到主干操作也是非常明确的事情。我们遇到麻烦的是在我们的分支机构做什么。 （旁注：我们使用TortoiseSVN优先于命令行。）

我们的开发人员分支已经不同步了，在尝试阅读这个问题时，我对工作流程以及这些方法的优缺点感到困惑：

1. 通过以下步骤在分支B和主干之间进行对称重新同步：

   • 合并 - 从B整合到主干
   • 合并 - 从主干重新整合回B

2. asymmetrical resync：

   • 合并 - 从B整合到主干
   • 合并 - 仅从主干进入B的记录（你如何在TortoiseSVN中做到这一点？）

3. reintegrate-and-restart：

   • 合并 - 从B整合到主干
   • 删除B
   • 将主干复制到B以重新开始

4. one-way resync从主干到B：

   • 从主干到B合并
   • （根据需要重复，直到重新融入行李箱。）

我们在选项＃1（对称重新同步）方面进展顺利，我真的很困惑为什么＃2和＃3似乎是推荐的方法。

任何人都能解释一下吗？

此外，在分支B和C之间合并以交换更新的正确方法是什么，而不是先重新合并到主干？ [我会问单独的问题]

Answer 1

我个人更喜欢选项3.每当你进行合并时，Subversion会跟踪你正在合并的修改以及从哪里修改。它以超级秘密（读取：公共知识但不编辑它）属性称为svn:mergeinfo。 SVN如何存储此合并信息变得复杂，并且取决于您的开发人员对合并过程的熟悉程度，它可能会变得非常混乱。

通过将B合并回主干，主干获得svn:mergeinfo，表明修订版X和Y之间的B现在位于主干上。然后，通过从主干中删除并创建B fresh，B现在具有所有必需的历史记录和svn:mergeinfo（因为svn:mergeinfo属性也已合并），以便日志知道分支中存在哪些修订（和哪个没有）。它还有助于避免树冲突（没人喜欢）。

选项2可能非常危险。我工作的公司完全禁止仅限记录的合并（它成为可以消防的攻击），因为如果做得不正确，代码可能会丢失。然而，它背后的理论是，当你将B重新集成到干线时，干线具有所有B（和svn:mergeinfo匹配）。仅记录到B 假设 B将不会用于生产代码（因为它不会有所有最新的更新），并且仅记录合并将提供一些信息以防止树冲突（再次，没有人喜欢）。

选项1介于两者之间。您的分支B将变得非常混乱svn:mergeinfo，但由于它是超级秘密（读取：大部分无缝处理），除非您有大量的合并，它应该可以满足您的需求。

Answer 2

你需要知道关于Reintegrate合并的所有内容，它做了什么，以及为什么这样做：

http://blogs.collab.net/subversion/2008/07/subversion-merg/

摘要：它全部是关于分支之间“同步”的修订，当您进行合并时，您希望它能够正确记住要合并的修订，以及要将其排除为已合并的修订。这是一个问题的原因是，有时您希望包含那些必须手动解决冲突的修订 - 您不想再次执行它们;但通常您不希望包含这些修订。因此，重新整合增加了管理这一点的智能，但是以通常的灵活性为代价 - 你不能一遍又一遍地重新整合，你必须在重新整合后重新开始。 因此选项＃3是颠覆家伙中唯一推荐的选项。