【发布时间】：2013-09-13 17:42:52
【问题描述】：
背景：
我们正在研究如何控制我们的 SVN 存储库。我们正在尝试建立一个适用于我们日常业务流程的系统。
我们的业务基于： - T-SQL 脚本文件 - 内部脚本语言 - 通过 .csv 文件加载的业务和表单数据 - 我们不“编译”代码。
我们有 4 名开发人员接收工作订单，以更改 SQL 或组件命令、数据加载脚本等。然后，开发人员将创建一个工作订单分支来保存他们从 Trunk（清洁生产脚本）或 DEV 所做的更改分支（代表我们的 DEV 环境，用于所有工作订单的组合更改），这尚未决定。
我们最初的存储库计划是这样的：
Dev 分支（包含我们最近的所有更改） 阶段分支（我们合并即将投入生产的工作订单） 树干（生产的原始表示）
我们经常同时处理多个工作订单。所以我们会有几个活跃的分支。在多个工单中同时更改同一个文件有点常见。
这使得跟踪在等待用户批准时被推迟的工单更改变得复杂。有时他们被拒绝并且永远不会进去！如果我们从 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 可能需要重新处理，具体取决于它还存在多长时间，即后来的工单也改变了文件。不幸的是，只要 WO2 仍然未完成，使用此文件的任何工作订单都会遇到此问题。
另一方面，如果我们从主干分支，我们也会遇到一些问题。
- 我们缺少使用相同文件的其他近期工作订单的所有更改。 因此，取决于我们在开发工单时发生了多少变化 独立或在我们等待提升工作订单时的更改可能会导致 在一些严重的合并问题上。假设我们可以降低这种风险，如果我们得到 来自 DEV 的分支，它具有合并到 DEV 的最新更改。
- 同样，开发人员需要使他们的数据库和环境保持最新，因为 可能的。但是如果我们从主干中提取它可能没有数据库架构更改 在正在进行的工作订单中制作。或来自正在进行的工作订单的相关 T-SQL 脚本。
基本上，我们正在讨论从主干（生产）或 DEV（生产存储库加上最近的开发更改）分支我们的工作订单更改的好处或成本。
有了上面的信息，有人对走哪条路有任何建议吗？
【问题讨论】：
-
感谢懒獾的回复。我明白你关于我们的“树干”是一个“伪装”标签的观点。我们可以简单地存储标签并完全摆脱我所谓的“主干”。我们很可能会这样做。从这一点开始，我将称之为“主线”干线。我相信我会遵循您的项目符号建议。但是，我有一些问题需要解决……尤其是关于第 2 条、第 3 条、合并以及我们的版本/安装要求。
-
我必须安装我们在验证测试中使用的 SVN 文件的确切版本号。由于我可能在两个工作订单中有相同的文件，我需要将它们合并，然后将该合并文件和该合并文件的确切版本移动到生产中。我一直在考虑如何做到这一点，我想出了以下可能。
-
我需要在某处合并工单文件，并且我需要确保在生产中使用与验证中使用的文件相同的版本。所以我可以将工单合并到主干中（是的，我知道这打破了第 3 个项目符号）。这意味着主干中的版本将是我们测试的版本和投入生产的版本。然后我可以在最后一个标签和主干之间使用“dif”来识别需要复制到验证（测试）和生产的文件。
-
基本上，除了在我验证工作订单期间，主干是纯粹的。如果验证有效，那么我们会将文件移动到 prod.xml 中。我们将在安装后使用另一个标签，以便标签反映生产中的更改，并且主干再次纯净。如果验证失败，则违规工作订单将被修复或删除，验证将继续。一旦验证完成，最终会产生一个新标签。
-
现在这将我带到项目符号 2 中的分支问题。如果我让人们从主干分支，如果我正处于验证期的中间，它可能不是纯粹的。为了解决这个问题，我们可以从标签中创建我们的分支。这意味着开发人员不会意外抓取正在验证的工作订单中的代码。这样做的缺点是，如果正在验证，开发人员将与其他所有人的代码甚至他们自己的代码隔离工作。但是，如果我们不孤立地工作，我们可能会引入
标签： svn version-control