SVN分支作为永久维护的版本

Question

在我工作的公司中，我们每发布x次（通常是三个月）都会发布一次。在那段时间里，我们有四到六个'分支可释放'冲刺，我们所有的代码都进入了这个分支。

某段时间后，分支版本以xxx版本的形式发布，我们将转到下一个版本。但由于通常的承诺，我们必须继续维持几个月/年的旧版本。

我不知道分支版本是否正确。正因为如此，我们的发布版本分支从未完全重新集成到主干中。他们永远活着。为了维护它们，当在分支中发现一个错误时，我们将它修复到主干中，并手动将它移植到分支（我更喜欢这个分支），或者我们在分支中工作并移植它（在主干中有一个提交分支，重新融入）回到树干。请注意，肯定可能会发生这样的情况，即trunk包含的代码不会/不能合并到一个分支中，可能是因为该分支太旧以致无法支持巨大的更改。

您知道我们使用的方法的好处/缺点吗？你有另一种方式来处理可维护版本吗？也许外面svn？

Answer 1

不知分支的版本到版本是正确的。

嗯，至少它不是完全不正确的 - 你有管理代码所有的时间。未完全重新整合的分支是您的内部游戏，您可以在不摧毁主要任务的情况下玩这款游戏 - 随着时间的推移发布产品并修复旧版问题。不同的代码行是你的代价

从PM POV你的“混合”工作流（2个来源，合并集和分支中的普通线性历史记录）难以从日志转换为最终的“完成列表”发布，我会更喜欢为“每个任务的分支”工作流程（在任何SCM中）做广告和宣传活动 - 这种方式使分支（开发，大多数）是短期的，可集成的工作部分和主线&版本分支将只获得合并集合，这更容易观察。但它只是个人喜好和口味

Answer 2

我想我会一直保留最新的稳定代码在树干中，当前的开发版本将会在分支中出现（因为不同的人会根据不同的要求工作，所以分支中会有很多版本）。之后，当我代码将准备发布我将它合并到主干，因为这将是一个最新的稳定代码。同时我会用最新的版本号和发布日期标记到标签文件夹中。

现在既然你有最新的稳定代码到躯干和最新发布的源代码转换为标签可以删除特定分支。

Answer 3

基本上有两种不同的“主干政策”：稳定躯干其中干线应始终释放的质量和所有的发展发生在重返分支机构，不稳定的主干在积极发展发生在躯干，并且在释放之前它被分支以稳定。

无论哪个干线政策使用的，一个发布版本应始终未重返一个分支。

继不稳定的主干政策（树干积极发展，需要进行分支，稳定在释放之前）的一个例子：

开发的进展，在树干1.0。在某个时候，1.X的分支被创建并且代码是稳定的。一旦代码被认为是稳定的，它被标记为1.0并被释放。与此同时，第二版的主干上的工作进展很快，该版本很快将在2.X分支中进行分支，以此类推。

在版本1.0中发现一个错误可被固定在1.X分支，1.1版可从与所述缺陷修复该分支释放。如果该错误在主干中相关，则可以合并。但是该功能可能会被删除或在主干中重建，从而使这个错误修复合并到干线毫无意义或不可能。如果通过版本2的beta版测试人员在主干中发现了该错误，那么您可以在此处修复该错误，并稍后查看旧的维护分支（如1.X）是否存在该错误，然后将错误修复合并到此处。它适用于两种方式。

我不知道怎么有可能比分支每个版本（在我的例子每主版本的一个分支，而不是每个版本）更好的政策，我没有看到的情况下一个版本/发布分支应该重新整合到后备箱中。