无论如何，您使用 svn tags 目录做什么？答案

【问题标题】：What do you use the svn tags directory for anyways?无论如何，您使用 svn tags 目录做什么？
【发布时间】：2009-06-02 20:13:13
【问题描述】：

好的，所以我们都知道标准的 SVN 设置

trunk\
branches\
tags\

而且我意识到建议标签应该在其中包含“特殊”提交。然而，我从来没有真正使用过标签目录，我不明白为什么我会这样做。

我的理解是 tags\ 将包含诸如“Version1Release\、Version2Release\、ThatTimeWeUpgradedEverthing\”之类的内容。但事情是这样的，如果您要进入并需要对 Version1Release 进行更改，那么它应该是一个分支，如果标签应该永远不会改变，那么在源代码控制中制作副本有什么意义呢？请注意，修订版 712 是我们的第 1 版。

我想我的困惑是标签似乎是永远不应该改变的版本。但是源代码控制就是保留更改文件的历史记录。我知道这是一个次要的组织论点，但我很好奇人们的想法。

【问题讨论】：

“请注意，修订版 712 是我们的版本 1。”请记住，69.59.196.211 是 stackoverflow.com。不？为什么不？是同一个概念！
确实是同一个概念。专用于该任务的 DNS 服务会记住 stackoverflow 的 IP。它不是以不自然的方式选择另一个系统。您可以在源代码控制中保存的文本文件中，或在发布文档中，或通过 zip 文件或 100 万种不同的方式“做笔记”，这些方式不涉及使用更改跟踪系统来存储永远不会存储的内容改变。
嗯，存储它不会占用任何空间。而且您不需要让人们访问您的主干，同时仍然允许他们将源下载到发布版本。

标签： svn version-control organization

【解决方案1】：

请注意，修订版 712 是我们的第 1 版。

这对团队中的开发人员来说已经足够了，也许（假设您有一个文档存储可以在其中做这样的笔记），但是要求任何不熟悉存储库的人“记住”很快就会变得非常不合理。

例如，假设您的存储库可通过 'net.用户可能会选择签出并为他们喜欢的但晦涩的 *nix 风格构建一个副本，并希望在添加他们不喜欢的功能之前获取几个版本的版本。标签使这种事情变得容易。

标签也非常适合作为“触发点”。在我自己的存储库中，提交标签会自动启动（通过 post-commit 挂钩）构建、打包并将其发布到我们的网站的脚本。

最后，标签是廉价的复制品。如果您想以一种表示快照永远不会更改的方式“快照”您的构建，请标记它。它不像它花费你很多。 :-)

编辑：

为了解决“作为分支实现”的想法——它们不是。真的。事实上，Subversion 根本没有实现分支或标记。这些完全是用户创造的想法，两者碰巧使用相同的命令svn copy。但是，您也可以使用该命令在主干中复制文件；没什么特别的。分支或标签本身也没有什么特别之处。它们只是普通目录，我们决定对其进行特殊处理（甚至可以通过挂钩强制执行）以简化项目管理。

【讨论】：

没错，因为 SVN 将副本存储为增量，所以创建标签几乎没有开销。标记基本上只是修订号和人类可读名称（以及关联的 URL）之间的语义关联。
从技术上讲，可以签出文件的标签副本并提交吗？ svn 不会抛出任何错误？纯粹是开发人员应该按照它的设想/定义来对待它，对吗？

【解决方案2】：

请注意，修订版 712 是我们的第 1 版。

对我来说，制作标签就是说明 rev 712 是第 1 版。

只需查看 Tags 文件夹，就可以很容易地查看所有构建、里程碑、发布等。

如果您考虑标签在 VSS 中的工作方式，标签会更快、更容易使用，但完成同样的事情。只是不要过度分析它是像分支一样使用复制命令制作的事实。

编辑：如果您对某人提交对 Tag 文件夹的更改感到偏执，您可以使用预提交挂钩来防止用户这样做。

【讨论】：

但是SVN的实现是这样的，你可以修改它。充其量是奇怪的，最坏的情况是它向那些不明白它的人找麻烦
“获取”源代码控制是正确使用它的第一步。如果您不明白，标签可能是您最不关心的问题。
那真是离题了。为什么要提供一种机制来鼓励您以错误的方式使用它？
Trunk、Tags 和 Branches 无论如何都是系统之上的用户结构。随心所欲地使用系统。我喜欢将它与标签文件夹一起使用的方式，它适用于我和我的同事。

【解决方案3】：

请注意，修订版 712 是我们的第 1 版。

但在这种情况下，您必须做一个明确的注释，将该注释存储在每个人都可以看到并查找的地方。

只需从修订版 712 创建一个名为“version 1 release”的标签（即从 r712 复制到标签目录）要容易得多。并且每个人都立即知道这是版本，而无需首先查看版本 1 版本是哪个修订版。

【讨论】：

哦，很常见，您可以在发布文档中制作它，甚至可以在存储在源代码管理中的文件中制作它。我的问题更多在于标签的目的与主干或分支的目的完全不同
你是对的。标签与树干或树枝不同；这就是标签存在的原因。它们的用途与树干或树枝不同。

【解决方案4】：

Subversion 存储库只是文件和文件夹的单个树，您可以随时在其中获取该树的任何部分在其历史记录中的任何版本。

正如其他人所说，标签/分支/主干只是一个约定，颠覆允许您将树的一部分复制到其他地方（几乎）免费，但在它的核心，就是这样。

您是对的，您的版本需要一个维护分支。该标签充当您在外部某处发送的任何特定版本的名称 - 创建标签时的提交评论让您有机会解释它的去向和原因（例如，“公开测试版”、“请求 cmets”）。

有几个钩子脚本可以防止你对标签进行修改，但默认情况下它们不会被实现，因为有些人以完全不同的方式使用 subversion（例如，配置文件备份等）。 Subversion 是一种通用工具，没有“正确”的使用方式，只有针对常见情况的强大约定。

事实上，collabnet 开始考虑如何将修订控制用于non-development projects。标记主干和分支的整个想法可能与其中一些无关。

我在考虑源代码存储库时的惯例是：

Trunk - 可能发布的完整修订列表
任务 - 对一组修订进行分组的作业/错误的外部描述
开发分支 - 一组尚未准备好用于主干的修订
维护分支 - 从主干收集修订以进行发布的地方
标签 - 维护分支的命名快照

标签还可以为您提供一个可用的文档网址，例如：

“该版本可在http://svnserver/myproject/tags/1.0 获得” 它可能是： "该版本可在http://svnserver/myproject/trunk@4483 获得"

但是当您浏览存储库时，您永远不会遇到 @4483 并且知道它有任何特别之处。

【讨论】：

确实我理解这个论点，似乎因为标签被用作不可变标签，所以应该有一个单独的机制来表示它们 - 比如可能在提交消息中放置一个特殊标签或东西。

【解决方案5】：

我们用它来标记有趣但不发布的特定构建，例如：“Investor Demo”等。

【讨论】：

【解决方案6】：

标签不打算被修改，如果你想这样做，你应该创建一个分支。

您可以从标记创建一个分支，这可能是您想要做的，然后将该分支的结果重新标记为不同的版本。

您不应该签出标签进行编辑。

在 SVN 中分支（复制）不会丢失任何历史记录。这一切都联系在一起。

【讨论】：

【解决方案7】：

标签应该引用一组文件的不可变“应用程序版本”。
（“应用程序的版本”而不是“VCS 使用的技术内部版本号”，例如 SVN 的修订版，或 Git 的 SHA-1，或 ClearCase 的 id，或...）
它们应该用作 reference 以在另一个工作区中查询和部署（用于测试或 UAT - 用户验收测试 -）

由于 SVN 实现了像分支一样的标签：作为目录，修改标签中文件的动机可能很强烈，但会破坏标签的目的。其他 VCS 具有标签（或“基线”）的概念，一旦设置，就不能再移动了。

George Mauercmets：

嗯，这就是我所说的。标签永远不应更改，因此将它们作为分支实现是非常...奇怪的。

“实现”？但是他们没有“实现”标签的概念。 SVN 本身没有“标签”。他们只是重复使用了他们的分支，并说它也可以用作标签。

SVN RedBook 明确指出：

但是等一下：这个标签创建过程不就是我们用来创建分支的过程吗？是的，事实上是这样。
在 Subversion 中，标签和分支之间没有区别。两者都只是通过复制创建的普通目录。
就像分支一样，复制的目录是“标签”的唯一原因是因为人类已经决定这样对待它：只要没有人提交到目录，它就永远是一个快照。如果人们开始致力于它，它就会变成一个分支。

【讨论】：

@VonC：你可以把它翻译成我们普通人理解的英语版本。什么是“应用版本”？为什么是“认证”而不是“批准”？
嗯，这就是我所说的。标签永远不应更改，因此将它们作为分支实现是非常...奇怪的。
@George — 我认为您在这里遇到的问题是 Subversion 根本没有 实现分支或标签。作为用户，我们决定创建名为 /branches 和 /tags 的目录并特别对待它们，但 Subversion 根本没有。标签不是“实现为分支”。它们被实现为副本。分支恰好以相同的方式实现。
我认为对标签的唯一有效更改是首先纠正使用标签的问题。我们在需要更改打包文件的旧标签中遇到了工具问题。纯粹的观点是创建一个新分支，进行更改，然后创建一个新标签。

【解决方案8】：

每次我将项目从开发服务器升级到生产服务器时，我都会创建一个标签。这让我了解了将哪些代码提升到生产环境的历史。如果有任何问题，我可以快速回滚到以前的生产版本。

您不想在标签目录中签出/更改/提交任何内容。它只是一个保存给定时间点的代码快照的地方。

【讨论】：

【解决方案9】：

根据我的经验，标签用于发布标记，并且您不太可能进行修改。

如果您创建“release2-0”分支，然后需要进行更改（例如，修复发布后发现的错误），则它不再代表您为 2.0 版发布的内容。

如果您创建了“release2-0”标签并发现需要修补该版本，则可以创建一个新分支，在那里进行修复，然后将其标记为“release-2-0-1”。

这样您就可以轻松访问您的任何版本。

【讨论】：