SVN产品开发 - 这个过程有多好？

Question

我在图片中添加了一个图例，使其自我解释。

最初，我项目的trunk中的代码是1.0版本。

我将使用此版本的代码创建4个分支：Vendor-A，Vendor-B，1.1和1.2。红线代表这些并行的开发分支。供应商特定的开发和发布在供应商分支上执行，供应商分支中的代码永远不会与主干合并。向供应商发布版本时，会标记这些版本。

现在，我的问题是：

1. 这种产品开发方法的准确度如何？
2. 说，在将1.1代码合并到trunk后，Trunk处于1.1和1.1分支结束（到期），之后我在1.1代码中发现了一个错误。现在，我会立即创建一个bugfix分支并将修复提交到Trunk。那么，这个错误修复是否应该被推入1.2分支和供应商分支？或者不应该推，因为这些分支正在处理不同版本的Trunk（1.0）？
3. 如何在供应商分支下解决开发问题？说，我需要修复供应商分支中的错误，我应该直接将更改提交到供应商分支吗？

我将非常感谢您在重组/重新设计流程时提出的建议。

Answer 1

似乎对我好。我稍微简化了一下 - 如果我认为供应商分支机构定期从主干刷新，那么你不需要从bugfix分支进行显式合并 - 只需将错误修正（例如1.1 bugfix）合并回主干，然后从主干到所有供应商分支进行合并。

从主干到供应商合并时的技巧是保持已经合并的内容的准确跟踪。理想情况下，您将合并所有内容，并按时间顺序按块进行。 （我发现标记提交的票证/功能号很有用，所以我可以从svn log看到需要在特定时间合并的内容。这可以确保我不会将半功能发送到另一个分支。

当我提交合并时，我将添加合并字符串（例如“（merge -r1234：2345 -r2667：3123 ../../trunk）”以及合并描述。这真的有帮助查看日志（比如在供应商分支上）以发现最早的未合并主干版本。

然而，我也倾向于在不同的分支上保持1.0和1.1。因此，如果1.1分支合并后1.0主干变为1.1，那么在此之前从主干获取分支1.0副本可能是合适的。最初将对trunk（1.1）进行错误修正，然后直接合并到从1.1分支派生的任何供应商。但是，它可能不适用于从1.0派生的供应商干净（或可能不相关）。在这种情况下，首先将它们应用于1.0分支，然后从那里合并到早期版本的所有供应商。

当然，您可能会发现仅与1.0相关的错误，并且在1.1中不相关或不存在 - 所以这个单独的分支也会有帮助。

考虑到这种方法，因此最好尽可能地将每个供应商从非常旧的版本升级，以便最大限度地减少需要维护的并发版本数量。无论您是理所当然地，还是作为新许可/合同的一部分，都是您的事业所在。