分支从DEV分支或分支从主干?

时间:2013-09-13 17:42:53

标签: svn version-control

背景:

我们正在研究如何控制SVN存储库。我们正在努力锻炼一个适合我们日常业务流程的系统。

我们的业务基于:    - T-SQL脚本文件    - 内部脚本语言    - 通过.csv文件加载的业务和表单数据    - 我们不“编译”代码。

我们有4名开发人员接收工作订单以更改SQL或组件命令,数据加载脚本等。然后,开发人员将创建工作订单分支,以便从Trunk(清洁生产脚本)或DEV中保存更改branch(代表我们的DEV环境,用于所有工单的组合变更),这还有待确定。

我们的初始存储库计划类似于:

Dev Branch(包含我们最近的所有更改) Stage Branch(我们合并即将投入生产的工单) 树干(原始的生产代表)

我们经常同时处理多份工单。所以我们会有几个活跃的分支。同时在多个工单中更改同一文件有点常见。

这使得跟踪在等待用户批准时推迟的工单变更变得复杂。有时他们被拒绝,永远不会进去!如果我们从DEV分支,我们冒着无意中推销这些推迟的工作单的代码的风险。

以下示例说明了DEV的分支问题:

  • 天X.
    • 1 WO1分支 - 获取文件版本1(来自DEV)
    • 2 WO2分支 - 获取文件版本1(来自DEV)
    • 3 WO2合并回DEV - 文件版本2
    • 4 WO3分支 - 获取文件版本2(来自DEV)
    • 5 WO1合并回DEV - 文件版本3
    • 6 WO3合并回DEV - 文件版本4

现在我们获得批准推广WO1& WO3。 WO2落后,但我们必须将其他人投入生产。

这是故障。我如何确定WO3有WO2变化? DIF将显示变化,但这是预期的。我们无法安装来自WO2的任何内容,因为它会破坏我们的审核要求。

理想情况下,我们需要提取WO2变更返工WO3。使问题复杂化WO2可能需要重新加工,这取决于它还能延长多长时间,I.E。以后的工作订单也会更改文件。不幸的是,只要WO2仍然未完成,我们就会对使用此文件的任何工作单发生此问题。

在硬币的另一面,如果我们从树干分支,我们也有一些问题。

  • 我们错过了使用相同文件的其他近期工单的所有更改。 因此,取决于我们制定工作订单时发生了多少变化 在我们等待推广工单时可以独立或改变 在一些严重的合并问题。假设我们可以减少风险 DEV的分支,具有合并到DEV的最新更改。
  • 同样,开发人员需要使他们的数据库和环境保持最新状态 可能。但是如果我们从trunk中撤出它可能没有数据库架构更改 正在进行的工作订单。或来自正在进行的工作订单的依赖T-SQL脚本。

基本上,我们正在讨论从主干(生产)或DEV(生产存储库加上最近的开发变更)分支工作单变更的好处或成本。

如果有中间的上述信息有没有人有任何建议去哪条路?

1 个答案:

答案 0 :(得分:1)

  1. 您是过早合并的受害者
  2. 您已经认真考虑过使用BASE分支:重叠功能,主干稍微伪装标签 ......

    • 使用单个分支作为真正的“主线”,没有其他变更集,而不是“WorkOrders”分支的合并集
    • 始终从“主线”的HEAD创建WO分支
    • 永远不要将未经批准的WO分支合并到主线
    • 如果在分支生命周期内主线发生变化,则执行从主线到WIP WO分支的同步合并