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

我在图片中添加了一个图例，使其不言自明

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

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

现在，我的问题是：

这种产品开发方法的准确性如何

比如说，在将1.1代码合并到主干中之后，主干位于1.1，1.1分支结束（过期），之后我在1.1代码中发现了一个bug。现在，我将立即创建一个bug修复分支，并将修复提交到主干中。那么，是否应该将此错误修复推到1.2分支和供应商分支中？或者不应该推送它，因为这些分支处理的是不同版本的主干（1.0）

我如何处理供应商分支下的开发？比如说，我需要修复供应商分支中的bug，我是否应该直接将更改提交给供应商分支

---

我也非常感谢您在重组/重新设计流程方面提出的建议

我觉得还可以。不过，我会简化一下-如果我认为供应商分支会定期从主干中刷新，那么您不需要从错误修复分支进行显式合并-只需将错误修复（例如1.1错误修复）合并回主干，然后从主干合并到所有供应商分支

从主干到供应商合并的诀窍是准确跟踪已经合并的内容。理想情况下，您将合并所有内容，并按时间顺序分块执行。（我发现使用票据/功能编号标记提交很有用，因此我可以从

svn log

查看在特定时间需要合并的内容。这确保我不会将半个功能发送到另一个分支

提交合并时，我将添加合并字符串（例如“（merge-r1234:2345-r2667:3123../。/trunk）”以及合并说明。这在查看日志（比如供应商分支）以发现最早未合并的主干修订时非常有帮助

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

当然，您可能会发现只与1.0相关的bug，而这些bug与1.1无关或不存在于1.1中，因此这个单独的分支也将在这方面提供帮助

---

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

关于从主干到供应商的合并r分支-这是个好主意吗？我的意思是，如果您的供应商分支代码是v1.0，那么将您的主干代码（位于v1.1）合并到供应商分支中有什么意义？我会不会丢失位于v1.0的供应商特定代码？我预感到会有人问这个问题，并添加了一个新的部分

：）

@Jay:^（不确定您是否会收到上面的通知）。修补程序应该首先重新整合到主干中，然后分发到需要的任何地方，以确保您始终拥有一个主副本。其余的似乎适合非敏捷系统性更改管理。@Jay，您如何处理这些问题？