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

Question

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

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

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

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

然而，我想知道这是否是正确的方法。有谁知道是否有可能在subversion中管理多个发布分支？当然，必须能够管理延迟而不会影响合并能力的功能。

有没有人对我提出的你愿意分享的情景有任何经验？我只想知道如何改进我在工作场所管理版本的方式，这样就不会再发生了。

Answer 1

说实话，我不完全确定你的系统是如何工作的。 但是，我过去必须管理多个实时版本的项目。我们这样做的方式是：

1. 首先没有释放任何不在行李箱中的东西。
2. 每个版本都有自己的版本分支。
3. 更新版本分支的唯一方法是从trunk合并。

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

关键是你可以选择一个完全集成的分支 - 这是我对trunk的定义。

这不是一个完美的系统。如果你跳过版本，那么依赖会让事情变得棘手，我们真的需要图形化的东西向我们展示它在哪里，但整体似乎运作良好。

另请参阅我的回答here。

Answer 2

这不是乌龟擅长的地方。要执行复杂的合并和分支方案，您需要使用clearcase配置规范来进行版本控制。

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

Answer 3

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

Answer 4

您几乎总是希望第一个延迟分支的更改在第二个中出现。所以第二个发布分支应该从第一个发布分支进行，并且应该定期合并第一个发布分支。理想情况下，由首先制造它们的人组成。

在这种情况下，Spepladder（？）分支会很好 - 只需放弃行李箱并爬上去。

Answer 5

我公司遇到过类似问题。

我们有一个项目延迟一个版本 - 我们称之为2.0 - 几个月。与此同时，我们在当前分支上遇到了生产问题 - 让我们称之为1.5 - 这需要更多的发布。我们不能使用trunk，因为它有禁止的功能，所以我们开始从分支机构进行分支。我们的版本1.6从1.5分支，而不是主干。除了命名约定之外，1.6版本实际上只不过是1.5.1。由于这不是SOP，我们一直非常谨慎地记录我们正在做的事情。

我并不期待合并点，我们最终汇集了1.6分支和2.0。我们无法将1.6上的更改合并到主干或2.0，因为这只会使2.0问题上的QA变得更糟。我们正在运行Subversion 1.4.6，因此没有软件的帮助 - 它将全部手动合并。