应用错误收集

背景：

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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