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帐户和webhost设置为开发人员作为我们开发的工作区服务器。
编码器通过FTP进行更改，当他完成后，他提交（也添加/恢复/删除）他branches/cases/#CASEID部分的更改。
之后，我们在开发人员门户网站上获得了一个按钮，尝试自动合并

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

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

如果我们收到冲突，我们会向编码员发出警告，例如“合并会导致下一次发布冲突，因此您必须在本地签出并手动合并”，如果没有任何冲突，则devel portal重新运行合并没有它的命令，并在/development/workspaces/next-release上提交更改。

我遇到的一些问题：

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

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

Answer 1

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

这种工作流程的一个问题是“重新整合”操作的“最终”方面，这意味着，一旦重新整合，您将无法对案例分支进行其他更改（和再次重新融入它。）另外，管理your mergeinfo metadata carefully。

Answer 2

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

重新整合应该按预期工作 - 它采用您分支的原始点与当前分支头之间的差异，并在合并时将这些差异应用回主干。它还会检查您是否已经从主干到您的分支机构合并，如果有，它会排除已经合并的更改。

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

同样，如果＃432家伙发生冲突，试图通过告诉系统跳过某人敢于在他之前提交的那些修订来解决它，然后是的，它会覆盖它们（它实际上没有覆盖它们，它实际上是删除它们 - 将它们合并，如果dev已经删除了代码本身）

我可能没有得到的另一个方面是你分支下一个版本，但是你的问题是指“＃432 guy”与分支/ on-QA-phase合并。这可能与问题有关吗？

有一个Collabnet blog post描述了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刷新Dev分支”。这个单独的“仅合并更改”提交还可以在事情严重错误的情况下轻松撤消合并，而不会丢失任何功能更改。

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

注意发布分支提交修订号，并向开发分支提供“阻塞”合并。对于此示例，假设我们将revision_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

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

3 个答案: