正确使用分支和主干的 SVN

Question

我有一个关于在我的 SVN 项目中正确使用主干和分支的问题。对于我团队的项目，我们每年会创建 3 个主要版本，有时会在其间创建一个或两个次要版本。在任何时候，我们都可能会积极开发 2 甚至 3 个版本。我们一直在分支中进行所有开发，其结构如下：

/branches/project1/2009.01
/branches/project1/2009.06
/branches/project1/2009.09
/branches/project1/2009.10

到目前为止，每当我准备为下一个版本创建分支时，我都会将当前分支的更改合并到主干，然后从主干创建新分支。然后，我通过主干合并手动保持最新的开发分支与先前版本分支的错误修复保持同步。从未在主干上执行任何开发或提交（合并的提交除外）。 现在我想知道我什至需要后备箱做什么。直接从前一个发布分支创建下一个发布分支并将错误修复更新直接从一个分支合并到下一个分支会有什么问题。我可以直接删除trunk下的项目吗？

所有 SVN 最佳实践文档似乎都表明使用主干进行开发，但对每个版本使用单独的分支对我来说似乎更容易，因为我们可以同时处理 2 或 3 个版本。我的 SVN 使用有什么技术问题吗？有什么建议吗？

谢谢！

Answer 1

你的工作方式很好。目前，一切都通过主干，所以你有一个单一的参考点来知道一切在哪里。不使用主干的问题在于对错误的去向有充分的了解。对于树干，问题是线性问题。没有主干，它会变成指数级，因为您必须将每个分支与其他每个分支进行比较才能查看其中的内容。

我个人不希望看到任何代码源自发布分支 - 首先在开发分支中进行修复，然后通过主干合并到发布分支。有时这是不切实际的，但合并历史总是可以被修改以使它看起来就像发生了什么。一般来说，从开发分支、主干到发布的稳定代码流是可以理解的。

这样做的原因是您可以为每个修复分配一个主干修订号，并通过简单地检查每个版本的合并历史与主干来跟踪该修订。您甚至可以将其制成表格以准确查看已发布的修复程序。 （比如看我的回答here）。

如果修复可以源自发布分支，则这种比较变得更加困难。虽然我想还是有可能的。但是，如果没有主干，您必须将每个版本相互比较，这将变得更加困难。

Answer 2

我同意 the_mandriill - 你所做的事情没有错，但总是质疑你是否可以做得更好也没有错（至少在 IMO）。

cmcrossroads 有一篇很棒的文章，它将为您提供有关管理代码的不同方法的足够多的想法。

K

Answer 3

我认为您的工作方式完全没有问题。如果它适用于您和您的团队，那就太好了。保留主干的一个好处是你的所有分支都从主干上脱落，而不是导致每个新产品分支都挂在前一个产品分支上的更混乱的情况。如果您要绘制修订图，您会发现它会很快变得复杂。