背景：
我们正在研究如何控制我们的 SVN 存储库。我们正在尝试锻炼一个适用于我们日常业务流程的系统。
我们的业务基于： - T-SQL 脚本文件 - 内部脚本语言 - 通过 .csv 文件加载的业务和表单数据 - 我们不“编译”代码。
我们有 4 名开发人员接收工作订单以更改 SQL 或组件命令、数据加载脚本等。然后，开发人员将创建一个工作订单分支来保存他们从 Trunk（清洁生产脚本）或 DEV 分支（代表我们的 DEV 环境用于所有工作订单的组合更改），这尚未决定。
我们最初的存储库计划类似于：
Dev 分支（包含我们最近的所有更改） Stage 分支（我们合并即将投入生产的工作订单） Trunk（生产的原始表示）
我们经常同时处理多个工作订单。所以我们会有几个活跃的分支。在多个工单中同时更改同一个文件有点常见。
这使得跟踪在等待用户批准时被推迟的工作订单更改变得复杂。有时他们被拒绝并且永远不会进去！如果我们从 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 可能需要根据它的持续时间进行返工，IE 稍后的工作订单也会更改文件。不幸的是，只要 WO2 仍然未完成，使用此文件的任何工作订单都会遇到此问题。
另一方面，如果我们从主干分支，我们也会遇到一些问题。
- 我们缺少使用相同文件的其他最近工作订单的所有更改。因此，取决于我们在独立开发工作订单时发生了多少更改，或者在我们等待提升工作订单时发生的更改可能会导致一些严重的合并问题。假设，如果我们从 DEV 获得具有合并到 DEV 的最新更改的分支，我们可以降低这种风险。
- 同样，开发人员需要使他们的数据库和环境尽可能保持最新。但是，如果我们从主干中提取，它可能不会在正在进行的工作订单中更改数据库架构。或来自正在进行的工作订单的相关 T-SQL 脚本。
基本上，我们正在讨论从主干（生产）或 DEV（生产存储库加上最近的开发更改）分支我们的工作订单更改的好处或成本。
有了上面的信息，有人对走哪条路有任何建议吗？