3

为什么在版本控制系统中移动标签是一种不好的做法？我经常遇到这个一般性建议，但从未见过背后的解释。

注意：我使用的是我认为与 CVS 更相关的术语“移动标签”。但是对于 SVN，当我们只在标签文件夹中提交更改时，这是一个类似的概念。

我的具体情况在这里：我使用SVN。我将使用构建系统自动创建标签。在创建新标签后，构建系统将标签描述信息放入已标记文件之一，提交，并在此更改的文件上移动标签。

我可以理解，如果在项目上设置了标签，并且对项目进行了测试，那么对标签进行更改可能会导致团队之间的误解。有人可能会签出旧版本的标签，而另一个人可能会签出新版本。但是在正式宣布之前对标签进行更改有什么不好的吗？

我想是否移动标签的决定可能取决于项目类型（商业、开源、个人）、从事项目的人数、标签创建后经过的时间、开发过程类型。

4

3 回答 3

3

标签旨在代表您的源代码的项目范围的特定修订，不应用于其他目的。也就是说，严格遵守这一原则可能会导致不得不跳过版本号，这可能同样是不可接受的。

对于复杂的构建过程，您应该尝试在发布候选分支中执行大部分工作，并且只在最后时刻进行标记。但是，您可能需要在中途修复某些东西，我认为对标记版本执行小的、受控的更改是可以接受的，特别是如果它的存在尚未正式宣传。

于 2012-09-25T11:48:37.717 回答
2

为什么在版本控制系统中移动标签是一种不好的做法？

因为它是普遍接受的约定。您必须遵守规则才能获得所需的结果，否则您将陷入混乱和无政府状态

在您的情况下，您的工作流程格式不正确，这违反了常见规则。“正确的方法”是改变工作流程，而不是规则。

我看到至少 2 个可能的版本：

  1. 从 repo 修订版 N 检出 CI，成功构建后在 WC 中添加文件，提交到主干，将主干 HEAD 复制到标签中（标签将为 N+2）
  2. CI 像现在一样创建标签，但必须添加额外的元数据作为此标签的自定义修订属性（属性）（svn help propset，propset PROPNAME --revprop -r REV PROPVAL [TARGET]版本）
于 2012-09-25T14:36:23.253 回答
2

标签通常被认为是存储库特定状态的不可变快照。有几个工具，例如 CI 工具，适用于这个假设。这是一条重要的规则，它确保您有一种独特的方式来引用项目的特定状态。

这就像 SVN 中的修订号或 Git 中的 SHA1 提交哈希。当人员或工具使用提交标识符引用提交时，他们确定他们正在谈论特定版本。

这同样适用于标签。如果您使用的规则是一旦存储库的状态被标记就不能改变，这意味着每个人（包括人员和工具）都可以安全地假设如果有问题，每个人都存在问题。如果应用程序行为或行为不端，那么对于检查该特定标签的任何人，它都会表现或行为不端。

这是一个需要牢记的非常重要的概念，因为一旦你打破了这个假设，你最终可能会花费更多的时间来尝试使用你在阅读 CI 日志或与其他开发人员交谈时引用的标签版本进行调试。

于 2012-09-25T11:33:52.093 回答