用于 Web 开发和改进的 SVN 布局

Question

我们正在开发一个 CMS，它正在大力开发中，

branches/cases/#432    (Under Development By Coder X)
branches/cases/#499    (Under Development By Coder Z)

branches/next-release  (Under QA)
  (Pending Merges by X&Z Coders)

tags/was-on-LIVE-before-v1.x

trunk/on-LIVE

当前结构如上，当我们从支持软件获得一个新案例时，我们从 branches/next-relase 切出一个分支到 cases/# CASEID 会自动为该开发人员设置 ftp 帐户和网络主机作为我们开发服务器上的工作区。
编码员通过 FTP 进行更改，完成后，他将更改提交（还添加/恢复/删除）他的 branches/cases/#CASEID 部分。
之后，我们在开发人员门户上有一个按钮，它尝试在自动合并

时自动合并：
我们更新branches/next-release（它也是团队检查所有提交的演示位置），然后尝试：

svn merge --dry-run --reintegrate \
  svn://SVN_SERVER/branches/cases/#CASEID \
  /development/workspaces/next-release | grep "C "

如果发生冲突，我们会向编码人员发出详细警告，例如“合并将导致下一个版本有冲突，因此您必须在本地检出并手动合并”，如果没有任何冲突，开发门户将在没有它的情况下重新运行合并命令，并在 /development/workspaces/next-release。

我遇到的一些问题：

• 虽然开发人员从 branches/next-release 中剪切了 #432 分支并开始编码，但做了很多更改，但仍在工作中
• 其他一些开发人员打开 #499 并对其他文件进行了一些更改，并与 branches/next-release 合并，
• 然后当“#432 Guy”时完成他的工作并将他的分支与 branches/on-QA-phase 合并，而不是“#499 Guy”所做的一些更改丢失/被 #432 覆盖旧文件。

我们的 SVN 布局/工作流程有何改进？
还有关于我们可以为此做些什么的问题？也许只合并文件只更改了文件或下一个版本到案例分支合并之前案例分支到下一个版本合并？

Answer 1

基本上，每当 SVN 涉及重新集成工作流程时，您都需要首先将目标分支合并到本地分支，然后将所述本地分支重新集成回集成分支。
请参阅“重新集成工作流程”。

这种工作流程会遇到的问题之一是“重新集成”操作的“最终”方面，这意味着，一旦重新集成，您将无法对案例分支进行其他更改（并再次重新集成） ).
另外，管理您的mergeinfo仔细元数据。

Answer 2

首先，使用 DVCS，git 解决了世界饥饿问题，是有史以来最好的事情。
好的，现在我们已经解决了这个问题，我们可以解决您的具体问题:)

重新集成应该按预期工作 - 它获取您分支的原始点和当前分支头之间的差异，并将这些差异应用回主干合并时。它还检查您是否尚未从主干合并到分支，如果已经合并，它会排除已合并的更改。

我想知道这是否是问题所在 - 开发人员从主干合并到分支，但没有合并所有修订，只将最后一个修订带到分支。在这种情况下，您会期望合并回来覆盖跳过的修订版 - 毕竟，开发人员会告诉合并跳过它们（即，r10处的分支，有人添加了版本11和12，开发人员将r12合并到分支，并且然后当他合并回来时，系统将计算差异，从而覆盖 r11 - 这就是他告诉它要做的）。

同样，如果 #432 的家伙遇到冲突，试图通过告诉系统跳过有人敢于在他之前提交的那些修订来解决它，那么是的，它会“覆盖”它们（它实际上不是覆盖它们，而是实际上删除它们 -将它们合并起来，就好像开发人员自己删除了代码一样）

我可能无法理解的另一个方面是您在下一个版本中分支，但您的问题指的是“#432 Guy”与分支/on-QA 阶段合并。这可能与问题有关吗？

有一篇 Collabnet 博客文章 描述了 Reintegrate 是什么以及它是如何实现的作品。

Answer 3

我们有一个非常相似的工作流程，但开发人员必须遵循几个关键步骤，以避免大部分合并的痛苦。与您的工作流程的主要区别在于，我们的每个开发人员都有一个长期存在的开发分支，这与您的案例分支类似。将修复/功能从开发分支合并到发布分支后，开发人员可以继续使用其开发分支来处理下一个修复/功能。总之，我们的工作流程如下：

注意： $SVN_REPOS 是一个环境变量，其中包含 Subversion 存储库的 URL。

从发布分支的 HEAD 为开发人员创建一个新的开发分支：

svn copy $SVN_REPOS/branches/release_branch $SVN_REPOS/branches/development_branch

开发人员检查他们的开发分支并在开发分支工作区域中实现他们的修复/功能 - 最好经常提交到存储库。

在将开发分支更改重新集成到发布分支之前，他们必须将对发布分支所做的任何新更改合并回其开发分支。这一步基本上是开发人员将其更改与创建开发分支以来所执行的工作集成的地方。我们对此有几个规则：

• 一个干净的development_branch工作区域用于从发布分支进行合并，即所有修复/功能更改都已提交。拥有一个干净的工作区域可以避免与未提交的代码发生任何合并冲突。
• 发布分支的合并发生在工作区目录树的根部。这避免了混合修订工作区域，并确保 svn:mergeinfo Subversion 属性记录在开发分支代码树的顶部。
• 开发人员被教育要了解他们在这个阶段正在集成其他人的代码，因此他们需要仔细考虑冲突解决。如果以草率的方式解决冲突，那么这是失去其他开发商变更的主要国家。描述冲突解决步骤和典型场景的良好 wiki 页面也是一个好主意。
• 从发布分支合并的更改已提交，无需进行任何其他修复/功能更改。这确保我们得到一个仅包含从发布分支合并的更改的单个修订提交，我们还有一个必须用于此提交的标准提交注释 - “从release_branch刷新开发分支”。这个单一的“仅合并更改”提交还可以在出现严重错误时轻松撤消合并，而不会丢失任何功能更改。

在进行了功能更改并刷新了开发分支后，开发人员现在要求将他们的更改合并到发布分支。我们有一个特定的人负责管理发布分支并执行开发分支的所有合并。他们将签出发布分支的新副本，并执行从开发分支到发布分支工作区域的重新集成合并。与我们所有的合并一样，这发生在代码树的根部。任何冲突都会发送回开发人员，而不会将任何内容提交到发布分支。开发人员需要从发布分支刷新其开发分支并解决冲突，然后再请求另一次合并到发布分支。 注意： 如果开发分支“过时”，svn merge --reintegrate 命令将在合并开始之前报告错误。

记录发布分支提交修订号，并将“阻塞”合并提交到开发分支。对于此示例，假设我们将development_branch更改提交到修订版112的发布分支。在开发分支的工作区域中：

svn merge --record-only -c 112 $SVN_REPOS/branches/release_branch
svn commit --depth=immediates . -m "Block development_branch to release_branch merge revision 112 from being merged back into rel_05_01_001"

这是长期存在的开发分支的关键。当开发人员下次使用新的发布分支更改更新其开发分支时，合并不会引入 rev 112，其中包含开发分支上已进行的更改。这避免了一大堆冲突。本质上，--record-only 合并让 Subversion 认为修订版 112 尚未合并到开发分支中，而事实上它只是一个标记，没有文件被合并。

总之，我们主要避免合并问题，因为我们总是合并到“干净”的工作区域并始终在代码树的顶部合并。 --record-only 技巧很方便，因为我们更愿意避免为每个修复/功能创建专用分支的开销。这是一篇很好的文章，它真正介绍了 Subversion 如何通过 mergeinfo Subversion 属性跟踪合并：

• http://www.collab.net/community/subversion/articles/merge-info.html