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

Question

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

最初，我的项目的主干中的代码是在版本1.0。

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

现在，我的问题是：

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

我很感谢您在重组/重新设计过程中的建议。

Answer 1

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

从中继线到供应商合并的诀窍是保持准确的跟踪，以确定已合并的内容。理想情况下，你会合并一切，并按时间顺序按块进行。 （我发现标记提交的票据/功能号码很有用，所以我可以从svn log看到需要在特定时间合并的内容，这样可以确保我不会向另一个分支发送半功能功能。当我提交合并时，我将添加合并字符串（例如“（merge -r1234：2345 -r2667：3123 ../../trunk）”以及合并描述。日志（比如在供应商分支上）发现最早的未合并中继版本修改

但是我也会倾向于在不同的分支上维护1.0和1.1所以，如果1.0中继在1.1分支合并后变成1.1 ，那么在此之前从主干上取一个分支1.0版本可能是合适的。最初的bug将会被修改为tr unk（1.1），然后直接合并到源自1.1分支的任何供应商。然而，它可能不适用于源自1.0的供应商的清洁（或可能不相关）。在这种情况下，首先将它们应用到1.0分支，然后从那里合并到早期版本的所有供应商。

当然，您可能会发现仅与1.0有关的bug，并且与1.1无关或不存在 - 因此，此独立分支也将在此处提供帮助。

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