使用Subversion进行代码升级

Tod*_*ier 6 svn

我正在努力将我们的开发团队迁移到Subversion并改进我们的存储库结构和流程.我们基本上采用标准的trunk/branches/tags设置.我原本打算使用发布分支策略(branches/1.0,branches/2.0等),但现在我倾向于代码推广模型(测试和生产分支).对于我们团队的工作方式来说,它会更好一些,更直观,但是发布会不那么简单:我们有效地需要测试分支成为生产分支.(生产分支始终可用于维护版本,但在一个版本的部署和下一个版本的测试就绪之间不需要存在测试分支.)

使用代码促销的任何人都可以推荐实现从测试到生产推广分支的最佳方法吗?我认为这些是我的选择,但不知道他们是否有重大利弊:

一个.将测试分支完全合并到生产分支中,删除测试分支
b.删除生产分支,将测试复制到生产,删除测试分支
c.删除生产分支,将测试分支重命名为生产

谢谢你的建议!

Pet*_*ker 2

第一:选项 b) 和 c) 在 subversion 中是相同的,因为 subversion 重命名实际上是复制和删除。

也就是说你只有两个选择:

  1. 将测试分支完全合并到生产分支,删除测试分支

    这就是颠覆意义上的干净方式。您可以在 svn 日志中看到哪些修订已合并到生产中,并且每个人的工作副本都保持不变。

    但它是有代价的:您必须手动进行合并并解决潜在的冲突(如果生产分支发生更改)。

    然而,您通常可以用少量的开销来做到这一点

  2. 删除生产分支,将测试分支重命名为生产

    这是一种简单的 方法,因为您只需执行一个非常小的可编写脚本的操作。

    缺点:

    您将使所有指向 testbranch 的工作副本失效(已成为生产版本!)

    合并跟踪要困难得多,因为您无法轻松查看旧的生产分支。生产分支中的直接更改会丢失(没有通知)!

另请记住,您可能不希望生产中测试分支中的所有提交(如果一切顺利,为什么要测试?)。所以我强烈建议选择A