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

Question

​

​

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

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

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

现在，我的问题是：

1. 这种方法对产品开发有多精确？
2. 比方说，在将1.1代码合并到主干后，T主干位于1.1和1.1分支结束(expires)，之后我在1.1代码中发现了一个bug。现在，我将立即创建一个fix修复分支，并将修复提交到中继中。那么，这个错误应该被推入1.2分支和供应商分支吗？或者不应该推送它，因为这些分支处理的是不同版本的中继(1.0)？
3. 如何处理供应商分支下的开发？比方说，我需要修复供应商分支中的bug，应该直接将更改提交到供应商分支吗？

我也希望你在重组/重新设计这一进程方面提出建议。

Answer 1

对我来说没问题。不过，我会将其简化一点--如果我认为供应商分支定期从主干获得刷新，那么您就不需要从bugfix分支进行显式合并--只需将bit修复程序(例如1.1bugfix)合并回主干，然后从主干合并到所有供应商分支。

从主干合并到供应商的诀窍是准确跟踪已经合并的内容。理想情况下，您将合并所有东西，并按时间顺序分块完成。(我发现带有票证/特征号的标记提交非常有用，因此我可以从svn log中看到需要在特定时间合并的内容。这确保了我不会将半个功能发送到另一个分支。

提交合并时，我将添加合并字符串(例如，"(merge -r1234:2345 -r2667:3123 ./躯干)“以及合并的描述。在查看日志(例如在供应商分支上)以发现最早未合并的主干修订版时，这确实很有帮助。

不过，我也倾向于在不同的分支上保持1.0和1.1。因此，如果1.0主干在1.1分支合并后变为1.1，那么在此之前从主干获取分支1.0副本可能是合适的。最初，修补程序将对主干( 1.1 )进行修复，然后直接与从1.1分支派生的任何供应商合并。但是，它可能不适用于从1.0派生的供应商(或可能与此无关)。在本例中，首先将它们应用到1.0分支，然后从那里合并到早期版本的所有供应商。

当然，您可能会发现只与1.0相关的bug，或者在1.1中不相关或不存在的bugs -因此这个单独的分支也会在那里提供帮助。

因此，考虑到这种方法，最好在可能的情况下将每个供应商从非常老的版本升级，以便将需要维护的并发版本的数量降到最低。您是理所当然地这样做，还是作为新的许可/合同的一部分，这是您的业务的问题。