好的，所以我们都知道标准的 SVN 设置
trunk\
branches\
tags\
而且我意识到建议是标签中应该有“特殊”提交。然而，我从来没有真正使用过标签目录，我不明白我为什么会这样做。
我的理解是 tags\ 将包含诸如“Version1Release\、Version2Release\、ThatTimeWeUpgradedEverthing\”之类的内容。但事情就是这样，如果您要进入并需要对 Version1Release 进行更改，那么它应该是一个分支，如果标签应该是永远不会改变的，那么在源代码控制中制作副本有什么意义呢？请注意，修订版 712 是我们的第 1 版发布。
我想我的困惑是标签似乎是永远不应该改变的版本。但是源代码控制就是保留更改文件的历史记录。我知道这是一个次要的组织论点，但我很好奇人们的想法。
请注意，修订版 712 是我们的第 1 版发布。
这对团队中的开发人员来说已经足够好了，也许（假设您有一个文档存储可以在其中做这样的笔记），但是要求任何不熟悉存储库的人“只记住”很快就会变得非常不合理。
例如，假设您的存储库可通过 'net. 用户可能会选择签出并为他们喜欢的但晦涩的 *nix 风格构建副本，并希望在您添加他们不喜欢的功能之前获取几个版本的版本。标签使这种事情变得容易。
标签也非常适合作为“触发点”。在我自己的存储库中，提交标签会自动启动（通过 post-commit 挂钩）构建、打包并将其发布到我们的网站的脚本。
最后，标签是廉价的副本。如果您想以一种表示快照永远不会更改的方式“快照”您的构建，请标记它。它不像它花费你很多。:-)
编辑：
为了解决“作为分支实现”的想法——它们不是。真的。事实上，Subversion 根本没有实现分支或标记。这些完全是用户创造的想法，两者碰巧使用相同的命令，svn copy. 但是，您也可以使用该命令在主干中复制文件；没什么特别的。分支或标签本身也没有什么特别之处。它们只是普通目录，我们决定对其进行特殊处理（甚至可以通过挂钩强制执行）以简化项目管理。
请注意，修订版 712 是我们的第 1 版发布。
对我来说，制作标签就是记下 rev 712 是版本 1。
只需查看 Tags 文件夹，也很容易查看所有构建、里程碑、发布等。
如果您考虑标签在 VSS 中的工作方式，标签会更快、更容易使用，但完成同样的事情。只是不要过度分析它是使用复制命令制作的事实，就像分支一样。
编辑：如果您对某人提交对 Tag 文件夹的更改感到偏执，您可以使用预提交挂钩来防止用户这样做。
请注意，修订版 712 是我们的第 1 版发布。
但在这种情况下，你必须做一个明确的笔记，将该笔记存储在每个人都可以看到并查找的地方的某个地方。
只需从修订版 712 创建一个名为“version 1 release”的标签（即，从 r712 复制到标签目录）要容易得多。并且每个人都立即知道这是版本，而无需首先查看版本 1 版本是哪个修订版。
Subversion 存储库只是一棵文件和文件夹树，您可以在其中随时获取该树历史中任何版本的任何部分。
正如其他人所说，标签/分支/主干只是一个约定，颠覆允许您将树的一部分复制到其他地方（几乎）免费，但在它的核心，就是这样。
你是对的，你的版本需要一个维护分支。该标签充当您发送到外部某处的任何特定版本的名称 - 创建该标签时的提交评论让您有机会解释它的去向和原因（例如，“公开测试版”、“请求评论”）。
有几个钩子脚本可以防止你对标签进行修改，但默认情况下它们不会被实现，因为有些人以完全不同的方式使用 subversion（例如，配置文件备份等）。Subversion 是一个通用工具，没有“正确”的使用方式，只有针对常见情况的强大约定。
事实上，collabnet 开始考虑如何将版本控制用于非开发 项目。标签树干和分支的整个想法可能与其中一些无关。
在考虑源代码存储库时，我的惯例是：
标签还可以为您提供可用的文档 url，例如：
“该版本可在http://svnserver/myproject/tags/1.0 获得”它可能是：“该版本可在http://svnserver/myproject/trunk@4483获得”
但是当您浏览存储库时，您永远不会遇到@4483 并且知道它有任何特别之处。
标签应该引用一组文件的不可变“应用程序版本”。
（“应用程序的版本”而不是“VCS 使用的技术内部版本号”，例如 SVN 的修订版，或 Git 的 SHA-1，或 ClearCase 的 id，或者......）
它们应该作为参考在另一个工作区中查询和部署（用于测试或 UAT - 用户验收测试 -）
由于 SVN 实现了类似分支的标签：作为目录，因此修改标签中文件的动机可能很强烈，但会破坏标签的目的。其他 VCS 具有标签（或“基线”）的概念，一旦设置，就不能再移动了。
George Mauer对此评论说：
嗯，这就是我所说的。标签永远不应更改，因此将它们作为分支实现是非常...奇怪的。
“实施”？但是他们没有“实现”标签的概念。SVN 本身没有“标签”。他们只是重复使用他们的分支并说它也可以用作标签。
SVN RedBook明确指出：
但是等一下：这个标签创建过程不就是我们用来创建分支的过程吗？是的，事实上，它是。
在 Subversion 中，标签和分支之间没有区别。两者都只是通过复制创建的普通目录。
就像分支一样，复制的目录是“标签”的唯一原因是因为人类已经决定这样对待它：只要没有人提交到目录，它就永远是一个快照。如果人们开始致力于它，它就会变成一个分支。
我们用它来标记有趣但不发布的特定构建，例如：“Investor Demo”等。
标签不打算被修改，如果你想这样做，你应该做一个分支。
您可以从标签创建一个分支，这可能是您想要做的，然后将该分支的结果重新标记为不同的版本。
您不应该签出标签进行编辑。
在 SVN 中分支（复制）不会丢失任何历史记录。这一切都联系在一起。
每次我将项目从开发服务器提升到生产服务器时，我都会创建一个标签。这让我了解了将哪些代码提升到生产环境的历史。如果有任何问题，我可以快速回滚到以前的生产版本。
您不想签出/更改/提交标签目录中的任何内容。它只是一个保存给定时间点的代码快照的地方。
根据我的经验，标签用于发布标记，并且您不太可能进行修改。
如果您创建“release2-0”分支，然后需要进行更改（例如修复发布后发现的错误），则它不再代表您为 2.0 版发布的内容。
相反，如果您创建“release2-0”标签并发现需要修补该版本，则可以创建一个新分支，在那里进行修复，并将其标记为“release-2-0-1”。
这样您就可以轻松访问您的任何版本。