Svn 如何管理subversion中的多个发布分支？

在我为之工作的公司，我们使用subversion和OrtoiseSVN来管理我们的源代码。每个项目都是从主干上分支出来的。当我们需要为发布集成不同的项目时，我们会创建一个发布分支，其中包含将被集成、测试和部署到生产中的代码。通常我们只有一个发布分支

然而，最近，其中一个项目中的一些项目被推迟，并计划进入下一个版本。因此，有人请求创建第二个版本分支来保存延迟的更改，并防止它们合并到当前版本中

到目前为止，这给我们带来了很多悲伤和树冲突，因为未来版本分支中的某些项依赖于当前版本分支中的项。我们能够解决这些问题的唯一方法是等待当前版本部署，将发布分支合并到主干中，将主干合并到未来发布分支中，然后将项目分支中的更改合并到未来发布分支中

由于这个问题，我们不得不建议永远不要有多个发布分支，因为它会导致合并问题

然而，我想知道这是否是正确的方法。有人知道在subversion中是否可以管理多个发布分支吗？当然，在不影响进行合并的能力的情况下，管理延迟的特性是可能的

---

有没有人对我介绍的场景有任何经验，你愿意分享？我只是想知道如何改进我工作场所的发布管理方式，这样就不会再发生这种情况。

这不是乌龟擅长的地方。要执行复杂的合并和分支场景，您需要像clearcase配置规范这样的东西来进行版本控制

---

如果您使用的是Ortoise，您最好保持主干不变，然后在主干上运行连续集成，或者为每个功能创建分支，在功能开发完成后将它们合并回主干。如果您这样做，那么您将只在测试的主干上有代码。然后选择一个发布点，进行集成并将所需的修复带回主干中，同时允许您的团队继续开发。

我认为您需要合并跟踪，可以通过svnmerge.py，也可以通过Subversion 1.5的内置合并跟踪。这允许您阻止将某些更改合并到分支中，然后可以对只希望合并到下一版本中的功能相关的所有更改进行合并。

您几乎总是希望第一个延迟分支上的更改在第二个分支中出现。所以，应该从第一个发布分支创建第二个发布分支，并且应该定期合并第一个发布分支的更改。理想的情况是由最初制造它们的人制造的

---

Spepladder（？）分支在这种情况下工作得很好——只需放弃主干并向上爬。

老实说，我不完全确定您的系统在描述中是如何工作的。 然而，过去我不得不用几个实时版本来管理项目。我们的做法是：

没有任何东西不首先在主干中被释放

每个版本都有自己的版本分支

更新版本分支的唯一方法是从主干合并

通过这种方式，我们可以选择哪个版本中有哪些功能。使用合并跟踪，它还可以让我们构建一个网页，以图形方式向我们显示什么去了哪里

关键是要有一个完全集成的分支，您可以从中选择—这是我对主干的定义

这不是一个完美的系统。如果您跳过了版本，那么依赖关系会让事情变得棘手，我们确实需要图形化的东西来显示位置，但总体上看起来效果不错

---

另请参阅我的答案。

我的公司也有类似的问题

我们有一个项目将一个版本——我们称之为2.0——推迟了几个月。与此同时，我们在当前分支上遇到了生产问题——我们称之为1.5——这就需要更多的发布。我们不能使用主干，因为它有禁止使用的特性，所以我们开始从分支分支。我们的1.6版是从1.5版扩展而来的，而不是主干版。除了命名约定之外，1.6版本实际上只不过是1.5.1。由于这不是SOP，我们一直非常小心地记录我们正在做的事情

---

我并不期待合并点，我们最终将1.6分支和2.0合并在一起。我们无法将1.6上的更改合并回trunk或2.0，因为这只会使2.0上的QA问题变得更糟。我们运行的是Subversion 1.4.6，因此没有来自软件的帮助——这将是所有手动合并。

您所说的“每个项目都是主干的分支”是什么意思？你是说你使用功能分支吗？@wcoenen我不太清楚该怎么解释。稍后我将用一张我们如何做事的图表来更新我的问题，希望能让事情变得更清楚。不幸的是，对我们的分支过程最了解的人要到星期一才能回来。