【发布时间】：2011-09-27 13:19:48
【问题描述】：
我已经搜索了该系列的管子一段时间，并没有找到任何好的答案，这通常是由于问题读者对用例的理解不足，所以我将成为详细得令人发指。例如这个问题：Create a "label" in subversion indicating what files should be in the next release（5 票的答案似乎很接近，但并不完全在那里）和这个问题：Using Subversion Tags to Deploy to Development/Staging/Testing Server 与我的相似，除了试图回答的人似乎并不完全理解其中的微妙之处。
我正在为一个快速发展的项目设置一个更复杂的暂存环境。当前环境由主生产分支和构建分支组成。构建不是问题，因为我们可以在构建分支“完成”时标记其头部修订并将其合并回生产。更微妙的部分是能够设置一个自动化过程，该过程为带有标签的每个文件的任意修订标记任意文件集，以便您可以将该标签同步到登台服务器。现在在 SCM 世界中，标签已重载，因此我将明确说明，在这种情况下，我在 perforce (http://www.perforce.com/perforce/doc.current/manuals/cmdref/label.html) 意义上使用标签，意思是一组文件的名称，其中文件处于任意选择的修订版中，并且集合是可变的。
举个简单的例子：假设我有文件 A 和 B。文件 A 的头版本是该文件的版本 13，文件 B 的头版本是版本 4。目前在生产中我们有 A@10 和 B@2。对文件 A 的更改已经过 QAd 并且已确定已准备好进行修补。对文件 B（修订版 3）的第一次更改已准备好修补，但业务方面已确定需要对头部更改（修订版 4）进行更多工作，因此不应修补并推迟到以后的日期.因此，要修补到生产环境，我们需要标记 B@3 和 A@13 以进行发布。所以这就是每个人都说“哦，好好使用标签”的地方。因此，对于 20110703 夜间补丁来说，这一切都很好。但是在舞台环境中，我们还希望能够在最好描述为“如果我们现在要标记分支，这就是它的样子”状态下测试不必要的头部修订文件全天（周、月等）。不要误会我的意思，我不想在生产分支中做一堆编码，但有时这是必要的。
到目前为止，我忽略的一点是，还有一个票务系统，其中提交与任务/票证相关联，而任务/票证与特定的发布日期相关。所以工作流是用户创建一个任务，以变更集的形式附加代码（具有一个任务对多的变更集关系），任务通过审批流程，最终被命名为准备好修补。然后有一系列自动化脚本来确定将在第 X 天修补哪些文件修订并将暂存环境（或生产环境）同步到适当的文件版本。我遇到问题的特定脚本是给定一组任务的脚本，并通过它们的变更集准备修补，我们能够将一组文件同步到适当的修订版，以模拟未来的生产补丁将看起来像。如果我要使用 perforce，我可以使用可变标签来完成此操作，并且基本上只保存用户可以同步到的 (filename, filerevision) 值的集合。但我希望使用开源工具，特别是与 Redmine 集成的工具（是的，我仍然需要构建票据到变更集关联层）。
所以我的问题是。
- 是否有任何包含标签概念的开源 SCM？我看了一点 mercurial 和队列扩展，但它似乎再次解决了一个类似但不完全相同的问题。 （请随时纠正我并说“不，队列完美地解决了这个问题......”）
- 如果没有任何工具可以完全按照这种方式工作，有什么建议可以最好地设置吗？我当然可以编写一个有点伪造标签并手动同步每个单独文件的脚本，但这在很多方面看起来都很糟糕。
基本上，我想要做的是能够允许诸如将任务移出几天或从不可修补状态转换为可修补状态之类的操作，以便能够影响暂存服务器上的代码状态在任务更改后，无需任何人工干预即可将它们置于“这是我们计划修补的”状态。
感谢您的帮助。
【问题讨论】：
-
我怀疑您还没有完全找到您要查找的内容的原因是现代版本控制系统在 commit 级别而不是 file 上工作 级。提交级别不同，因为 (a) 提交可以跨越多个文件，并且 (b) 给定文件有多个可能影响它的提交。处理逐个文件的发布分期似乎很棘手，除非几乎所有的提交都是完全不相交的（这在实践中似乎不太可能）。您是否考虑过任何其他分期方案？
-
所以提交级别的粒度很好，因为这实际上是与任务相关联的，因此被指定为准备发布。但是，如果我使用文件 A、B、C 提交系统范围的修订版 6，并使用文件 D、E、F 提交系统范围的修订版 7，并且想要修补没有 7 的修订版 6（或没有 6 的 7 版），我应该能够做到这一点以一种自动化的方式并且没有我引用的标签概念，这似乎很困难。唯一的麻烦，并且在实践中需要手动工作，是如果 6 和 7 包含文件 A、B、C |分别为 C、D、E。然后人类通常会修复文件 C 问题。
-
两个修订版具有一组不相交的受影响文件（A、B、C 和 D、E、F）的情况对于使用 Git 或 Mercurial 等 DVCS 进行管理是微不足道的（我使用 Git，所以我'我最熟悉的）。此外，如果文件 C 中的实际更改在每个修订版之间重叠，则一组重叠的文件（A、B、C 和 C、D、E）仅需要人工干预。如果它们不重叠，则没有问题，可以自动处理选择。
-
可能值得您退后一步，看看A Successful Git Branching Model 之类的东西，它描述了一种使用 Git 管理分阶段发布的方法。
-
我要做的是（用 Git 术语），在我自己的工作站上，通过合并和挑选必要的方法来准备一个用于暂存的分支。然后我会将该分支推送到某个存储库，然后将其拉到登台服务器。一旦它经过测试并准备好用于生产，请转到生产服务器并拉出 same 分支。由于现代 DVCS 的灵活性，有许多不同的方式来安排它，您可能会找到适合您的不同方式。
标签： svn version-control release perforce release-management