在SCM中正确使用标签

Question

我的同事和我正在讨论发布/ SCM系统中标签的价值和用法.我们期待StackOverflow社区提出他们的想法,以帮助我们解决问题.

一方声称标签是发布管理的有价值的补充.它们的一个使用示例:我们做了一个Maven版本,它发布了一个新的Tag(称之为1.0),这是用于此版本的代码快照.此标记应为READONLY分支.当需要修复bug时,我们可以将Tag的副本复制到一个新的分支中(称之为1.1).错误修复去那里.这些修复程序可能会合并回Trunk,以便主dev分支获取错误修复程序.最后,1.1发布并自动创建Tag 1.1.这个循环继续.Tag的主要好处是,如果您因任何原因需要重新发布版本1.0,您可以放心发布Tag 1.0,并确信它从未被任何人更改过.另外,说"Release Tag 1.0"比说"发布版本1的分支1.0是没有修复的原始1.0"更清晰.

另一方声称标签没有提供任何有价值的好处,特别是在像Subversion这样具有全局修订的系统中,这些系统就像CVS中的标签一样.另外,Subversion仅在提交标签时发出警告; 它实际上并没有阻止它.他们的方法是在Trunk中开发,一旦发布,你就会创建一个名为1.0的Branch.您将继续在Trunk中修复错误,如果您需要将这些错误修复重新发布到生产中,您可以将它们合并到1.0 Branch并重新发布1.0.在某些时候,也许在Trunk中的主要修复或功能之后,您将发布并创建Branch 1.1.循环继续.如果您需要发布原始1.0版本,则必须查看Branch 1.0版本1.

显然这两种方法都有效.我想听听社区对哪种方法首选以及为什么这样做的想法.

编辑:我有点担心"最佳"方式取决于底层的SCM系统.要么在Subversion上找到答案,要么尽可能保持SCM不可知.

Answer 1

从与 SCM 无关的角度来看，标签与修订版有很大不同。

两者可能以相同的方式实现，都代表一条“时间线”，但他们的目标不同：

• 标签代表一种不可变的状态，其中所有文件都由唯一的 ID 引用。这是一个代表很多东西的名字，但主要是一种稳定的状态，......）
• 修订版代表提交事务（并非所有 SCM 都有这些事务，尤其是采用“逐文件方法”的旧版本）。所有提交并不代表“稳定”状态（如成功“编译”或“执行”）。它们只是全球历史的一个新元素。

SVN 的问题在于修订版、标签和分支的实现都是相同的。
但我仍然更喜欢将标签用作“只读”分支的选项。