目前我们使用Subversion进行源代码管理，但我们发布的所有合并工作都是手动完成的。我们每年发布几次，因此为每个版本创建一个分支。来自早期分支的所有工作必须使其成为后来的分支。后期分支机构的工作不得进入较早的分支机构（这在我们的合同中）。我相信这被称为促销模式。
我认为下面的图表最能说明我们所需的工作流程，每当新版本开始工作时都会创建分支，并且从早期分支流向后来的分支。
| 1 | |\ | \ | 2 3 | |\| 4 | | |\ 5 | \ | 6 | | | 7 |\|\| | |\| 8 9 |\ | | | \ |\| | 10 x |\| | | |\| | | | a b c d
修改 - 添加更多信息。
传统的不稳定中继模型可能不适合的原因如下图所示。每个版本的功能不一定按发布顺序完成（某些客户可能很难确认要求）。我们希望尽快将更改从早期分支传播到后一分支。
a
|
1
|
b|\ a
| \
| 2
3 |
| |
4 |
b/|c |
/ 5 |
| | 6
7 | |
b c a
在这种情况下，我们想要分支b中的功能2（在分支a中完成），但由于这是子到父的合并，因此Subversion不支持，因此必须手动完成。类似地，特征6必须手动合并两次。与自动跟踪的合并相比，我预计这是一个相对缓慢且容易出错的过程。
答案 0 :(得分：1)
你说：
早期分支机构的所有工作必须 把它变成后来的。稍后工作 分支机构不得早些进入 （这是在我们的合同中）
在这里，如果我们用发布替换分支（我怀疑你的客户知道或关心“分支”），我们得到：
早期版本的所有工作都必须 把它变成后来的。稍后工作 版本不得早些进入 （这是在我们的合同中）
我没有看到任何要求建议您提出的非常复杂的分支方案 - 您可以使用经典的“不稳定主干”开发方式来实现。要么你有更多的要求你没有告诉我们，要么你过度工程。
答案 1 :(得分：1)
如果我理解你的情况，你的要求中没有任何东西可以使你看起来像制作它们那么复杂。你也过分强调自动与手动合并的优点（稍后会详细介绍）。 CVS分支本来是另一回事，但不是SVN处理“分支”的方式（即它没有）。
您可以拥有主要（不稳定或稳定）开发线，并为每个客户或版本（或两者）创建分支。在验证功能时，它们要么合并回主线，以便稍后分支可以包含这些更改，要么始终从父分支单向合并。没有什么要求你关闭分支，并且合并的自动化程度不低于支持你的第一个（混乱）图表，因为你有多个并发的开发线。
要求您只合并前向声音，只需要合并主线的子集修订，在给定的分支修订后进行修订。以这种方式进行合并将允许您根据需要随时将任意分支的更改合并到主线（因为它们已经与客户确认），并且可以放心地应用于仅应用了经过验证的更改。您可以设置自动合并以跟踪该副本修订（请参阅--stop-on-copy和基于范围的合并）。发布分支然后获取从给定点开始发生的已确认更改的集合。
SVN不会“跟踪合并”而不是支持分支（它不支持分支，它们只是轻量级副本）。你告诉它（或svnmerge告诉它）要合并的范围并应用这些更改。无论如何，您都可以获得合同要求支持的效果。
回答你提出的问题：
我不认为你提出的模型非常有效。相反，它增加了特征跟踪混乱的可能性，因为您可能必须扫描分支以进行更改并多次向前合并。此外，它无疑会使熟悉SVN的开发人员和更传统的SVN组织结构感到困惑。
不确定。这应该与您选择的结构完全无关。无论如何，您都需要/想要跟踪您的修订点（可能通过一些简单的脚本更糟糕）。
不确定。在服务器端SVN中的分支实际上没有成本。如果您进行完整的根检查，客户端会有成本，但这通常是一件愚蠢的事情。同样，忽略/删除分支也没有问题。这只是全局修订层次结构的另一个变化，就像任何其他复制/删除/重命名/等一样。
无论采用何种“分支”组织结构，这都应该有效。对于SVN中的“分支”来说，这听起来有点误解。您应该能够设置所需的内容并相对轻松地执行“手动”合并，然后在几次客户更新后设置自动合并，以便您更好地了解合并步骤。
干杯！