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

Question

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

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

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

我可以理解，如果在项目上设置了标签，并且项目已经过测试，那么对标签进行更改可能会导致团队之间产生误解。有人可能会检查旧版本的标签，而另一个人可能会更新。但在正式公布标签之前对标签进行更改是不是很糟糕？

我认为移动标签的决定可能取决于项目类型（商业，开源，个人），项目工作人员数量，标签创建后的时间，开发过程类型。

Answer 1

标记用于表示源代码的项目范围特定修订，不应用于其他目的。也就是说，严格遵守这一原则可能导致不得不跳过发布号码，这可能是不可接受的。

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

Answer 2

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

它类似于SVN中的修订号或Git中的SHA1提交哈希。当人员或工具使用提交标识符引用提交时，他们确信他们正在讨论特定版本。

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

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

Answer 3

  

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

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

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

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

1. 来自repo revision N的CI checkout，成功构建在WC中添加文件，提交到trunk，将trunk HEAD复制到tag（tag将是N + 2）
2. CI现在创建标记，但必须添加其他元数据作为此标记的自定义修订属性（属性）（svn help propset，propset PROPNAME --revprop -r REV PROPVAL [TARGET]版本）