我发现这个问题有任何好的答案，通常是因为读者对问题的用户缺乏了解，所以我将会非常详细 . 例如这个问题：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与我的相似，只是试图回答的人似乎并不完全理解这些微妙之处 .
我'm setting up a more sophisticated staging environment for a fast growing project. The current environment consists of a main production branch along with build branches. Builds are not a problem as we can just tag the head revision of the build branch when it' s "done"并将其合并回 生产环境 中 . 更微妙的部分是能够设置一个自动化过程，该过程使用标签为每个文件标记任意版本的任意文件集，以便您可以将该标签同步到登台服务器 . 现在在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集成的工具（是的，我仍然需要构建ticket-to-changeset关联层） .
所以我的问题是 .
-
是否有任何开源SCM具有标签的概念？我看起来有点像mercurial和队列扩展，但它再次似乎解决了类似但不完全相同的问题 . （随意纠正我并说"nope queues solve this perfectly just to this..."）
-
如果没有任何工具以这种方式工作，那么有关如何最好地设置它的任何建议吗？我当然可以写一个有点伪造标签的脚本并手动同步每个单独的文件，但这在很多方面看起来很糟糕 .
基本上我要做的是能够允许诸如任务被移出几天或从非补丁状态转换到可修补状态的操作，以便能够影响登台服务器上的代码状态以放置它们在“这是我们正在计划修补”的状态，在任务发生变化后没有任何人为干预 .
谢谢您的帮助 .
1 回答
[这个答案试图总结上述评论中的讨论 . ]
现代DVCS（例如Git，Mercurial）将更改作为提交序列而不是文件集进行管理 . 因为如果这种不同的范式，很难想一个从特定修订中选择特定文件的“标签” . 提交可以触摸多个文件，提交可以触摸给定文件（尽管文件内部的更改可能重叠也可能不重叠） .
要使用Git管理分阶段发布，您可以做的是：
grab 以前的版本分支 .
拉出每个分支或挑选每个要在下一个分段测试中提交的提交（您可以在开发工作站上执行此操作） .
推送到临时存储库 .
将其拉入登台服务器 .
当分段检出时，将同一分支拉到 生产环境 中 .
在（希望）常见的情况下，您不需要任何更改，然后步骤2变为单步合并 . 如果您不想进行特定更改，那么您可以选择您想要的更改 .
一些有用的资源：
Pro Git - 关于Git的免费书籍
A successful Git branching model - 使用Git管理多个更改和暂存版本的一种方式的说明（带图片）