使用开放源码工具建立复杂的阶段环境

Question

我已经搜索了一段时间，并且没有找到这个问题的好答案，通常是因为问题的读者对用例是什么缺乏了解，所以我会非常详细。例如，这个问题：在subversion中创建一个“标签”，指示下一个版本中应该包含哪些文件。 (5票的答案似乎很接近，但不完全是这样)，而这个问题：使用Subversion标记部署到开发/暂存/测试服务器与我的相似，除了那些试图回答的人似乎并不完全理解其中的微妙之处。

我正在为一个快速增长的项目建立一个更复杂的分期环境。当前环境包括一个主要的生产分支和构建分支。构建并不是一个问题，因为我们可以在构建分支“完成”时标记它的头版本，并将其合并到生产中。更微妙的是能够设置一个自动化的过程，在每个文件的任意修订处用标签标记任意一组文件，以便您可以同步到该标签到临时服务器。现在，在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天将出现哪些文件修订，并将暂存环境(或生产)同步到相应版本的文件。我遇到麻烦的特定脚本就是给定一组任务，并通过它们进行更改的脚本，这些任务可以修补，我们可以将一组文件同步到适当的修订版，以模拟未来的生产修补程序将是什么样子。如果我要强制使用，我可以使用可变的标签来实现这一点，并且基本上只保存一个用户可以同步到的(文件名、文件视觉)值的集合。但我希望使用开源工具，特别是与Redmine集成的工具(是的，我仍然需要构建票证到变更集的关联层)。

所以我的问题是。

1. 是否有任何开源的SCM中有标签的概念？我看过一些mercurial和队列扩展，但它似乎再次解决了一个类似但不完全相同的问题。(请随时纠正我，并说“不，排队解决这个问题，就这样.”)
2. 如果没有任何工具是这样工作的，那么对于如何最好地设置它，有什么建议吗？我当然可以编写一个脚本，它可以伪造标签，手动同步每个单独的文件，但在很多方面似乎都不太好。

基本上，我想要做的是能够允许一些行动，比如一个任务被移出几天，或者从一个非补丁状态转换到一个可扩展状态，从而能够影响到暂存服务器上的代码状态，从而使它们处于“这就是我们计划修补的”状态，而在任务改变之后没有任何人工干预。

谢谢你的帮助。

Answer 1

这一回答试图总结上述评论中的讨论。

现代DVCS (如( Git，Mercurial)将更改管理为提交序列，而不是一组文件。因为如果这种不同的范例，很难想到从特定修订中选择特定文件的“标签”。提交可以接触多个文件，而提交可以同时接触到给定的文件(尽管文件中的更改可能重叠，也可能不重叠)。

要使用Git管理分阶段发行版，您可以做的是：

1. 抓取上一个发布分支。
2. 在下一次阶段测试中，将每个分支或樱桃选择每个提交(您可以在开发工作站上这样做)。
3. 推到暂存存储库。
4. 把它拉到临时服务器上。
5. 当阶段检查正常时，将同一分支拉到生产中。

在(希望)常见的情况下，没有任何您不想要的更改，那么步骤2就变成了一个单一步骤的合并。如果你不想要一个特别的改变，那么你可以选择你想要的改变。

一些有用的资源：

• 关于Git的亲Git免费书籍
• 一个成功的Git分支模型 -使用Git管理多个更改和暂放版本的一种方法的描述(有图片)