你到底用 svn 标签目录做什么？
好的，我们都知道标准 SVN 设置，
trunk\
branches\
tags\
并且我意识到建议是标签中应该有“特殊”提交。 然而，我从未真正使用过标签目录，而且我不明白为什么我会这样做。
我的理解是，tags\ 将包含诸如“Version1Release\、Version2Release\、ThatTimeWeUpgradedEverthing\”等内容。但事情是这样的，如果您要进入并需要对 Version1Release 进行更改，那么它应该是一个分支，如果标签应该是永远不会改变的，那么在源代码管理中制作副本有什么意义呢？ 请注意，修订版 712 是我们的版本 1 版本。
我想我的困惑是标签似乎是永远不应该改变的版本。 但源代码控制的目的就是保留文件更改的历史记录。 我知道这是一个小小的组织争论，但我很好奇人们的想法。
Ok so we all know the standard SVN set-up of
trunk\
branches\
tags\
And I realize that the recommendation is that tags should have "special" commits in it. I've never really used the tags directory however and I don't see why I ever would.
My understanding is that tags\ would contain things like "Version1Release\, Version2Release\, ThatTimeWeUpgradedEverthing\" etc. But here's the thing, if you are going in and need to make a change to the Version1Release then it should be a branch, and if tags are supposed to be never-changing then whats the point of making a copy in source-control anyways? Just make a note revision 712 was our version 1 release.
I guess my confusion is that it seems like tags are versions that are never supposed to change. But source control is all about keeping a history of changing files. I know this is a minor organizational argument, but I'm curious what people think.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（9）
每次将项目从开发服务器提升到生产服务器时，我都会创建一个标签。 这为我提供了哪些代码被提升到生产环境的历史记录。 如果有任何问题，我可以快速回滚到以前的生产版本。
您不想在标签目录中签出/更改/提交任何内容。 它只是保存给定时间点的代码快照的地方。
I create a tag every time I promote a project from a development server to a production server. This gives me a history of what code was promoted to production. If there are any issues, I can quickly roll back to the previous production version.
You would not want to checkout/change/commit anything in the tags directory. It is simply a place to keep a snapshot of your code from a given point in time.
根据我的经验，标签用于发布标记，并且您不太可能进行修改。
如果您创建“release2-0”分支，然后需要进行更改（例如修复发布后发现的错误），它不再代表您为版本 2.0 发布的内容。
相反，如果您创建“release2-0”标记并发现需要修补该版本，则可以创建一个新分支，在那里进行修复，并将其标记为“release-2-0-1”。
这样您就可以轻松访问您的任何版本。
In my experience tags are used for release markers, and where you aren't likely to make modifications.
If you create a "release2-0" branch, and then need to make changes (e.g. to fix a bug found post-launch) it no longer represents what you released for version 2.0.
If instead you create the "release2-0" tag and find you need to patch that version, you can create a new branch, make the fix there, and tag that as "release-2-0-1".
This way you can easily access any of your releases.
这对于团队中的开发人员来说可能足够有效（假设您有一个文档存储来记下此类注释），但是要求任何不熟悉存储库的人“记住”很快就会变得非常不合理。
例如，假设您的存储库可通过“网络”访问。 用户可能会选择签出并构建一个他们喜欢的但晦涩难懂的 *nix 风格的副本，并希望在添加他们不喜欢的功能之前获取几个版本之前的版本。 标签使这种事情变得容易。
标签作为“触发点”也是极好的。 在我自己的存储库中，提交标签会自动启动（通过提交后挂钩）一个脚本，该脚本会构建、打包并将其发布到我们的网站。
最后，标签是廉价的复制品。 如果您想以一种表示快照永远不会改变的方式对您的构建进行“快照”，请对其进行标记。 这并不像它花费你太多。 :-)
编辑：
为了解决“作为分支实现”的想法 - 但事实并非如此。 真的。 事实上，Subversion 根本不实现分支或标记。 这些完全是用户创建的想法，两者碰巧使用相同的命令，
svn copy。 但是，您还可以使用该命令在主干中复制文件； 没什么特别的。 分支或标签本身也没有什么特殊之处。 它们只是普通目录，我们决定对其进行特殊处理（甚至可能通过挂钩强制执行）以简化项目管理。This works well enough for developers on the team, perhaps (assuming you have a document store to make such notes in), but asking anyone not intimately familiar with the repository to "just remember" gets pretty unreasonable pretty quickly.
For example, say your repository is available over the 'net. A user might choose to check out and build a copy for their preferred, but obscure, flavor of *nix and want to grab a release which is a couple of versions back, before you added a feature they don't like. Tags make this kind of thing easy.
Tags are also excellent as a "trigger point". In my own repositories, committing a tag automatically launches (via post-commit hook) a script which builds, packages, and posts it to our web site.
In the end, tags are cheap copies. If you ever want to "snapshot" your build in a way which represents that the snapshot won't ever change, tag it. It isn't like it costs you much. :-)
Edit:
To address the "implemented as branches" idea — they aren't. Really. In fact, Subversion doesn't implement branching or tagging at all. Those are entirely user-created ideas, both of which happen to use the same command,
svn copy. However, you'd also use that command to copy a file within the trunk; there's nothing special about it. And there's nothing inherently special about branches or tags, either. They're just ordinary directories which we've decided to treat specially (and may even enforce that via hooks) to ease project administration.对我来说，创建标签就是记下 rev 712 是版本 1。
只需查看 Tags 文件夹，也可以很容易地看到所有构建、里程碑、发布等。
如果您考虑标签在 VSS 中的工作方式，就会发现标签更快、更容易使用，但完成的任务是相同的。 只是不要过度分析它是使用复制命令创建的，就像分支一样。
编辑：如果您对某人向标签文件夹提交更改感到偏执，您可以使用预提交挂钩来阻止用户这样做。
To me, making a Tag is making a note that rev 712 was version 1.
It is also very easy to see all of the builds, milestones, releases, etc., just by looking at the Tags folder.
If you consider how Labels worked in VSS, Tags are much faster and easier to work with, but accomplish the same thing. Just don't over analyze the fact that it is made using the copy command just like a branch is.
Edit: If you are paranoid about someone committing changes to a Tag folder, you could use pre-commit hooks to prevent it by user.
但在这种情况下，您必须做出明确的注释，并将该注释存储在每个人都可以看到并查找的地方。
从修订版 712 创建一个名为“版本 1 发行版”的标签（即从 r712 复制到标签目录）要容易得多。 每个人都立即知道这是一个版本，而无需首先查找版本 1 版本是哪个版本。
But in that case, you have to make an explicit note, store that note somewhere in a place where everybody can see it and look for it.
It's much easier to just create a tag from revision 712 (i.e., copy from r712 to the tag directory) with the name "version 1 release". And everybody immediately knows that this is the release, without first having to look up which revision the version 1 release was.
Subversion 存储库只是一个文件和文件夹树，您可以随时在其历史记录中的任何版本中获取该树的任何部分。
正如其他人所说，标签/分支/主干只是一种约定，颠覆允许您将树的一部分复制到其他地方（几乎）免费，但在其核心，仅此而已。
你是对的，你的版本需要一个维护分支。 该标签充当发送到外部某处的任何特定版本的名称 - 创建标签时的提交评论使您有机会解释它的去向和原因（例如，“公开测试版本”、“请求评论”）。
有几个钩子脚本可以阻止您对标签进行修改，但默认情况下它们不会被实现，因为有些人以完全不同的方式使用 subversion（例如，配置文件备份等）。 Subversion 是一个通用工具，没有“正确”的使用方法，只有针对常见情况的强大约定。
事实上，collabnet 开始考虑如何将版本控制用于 非开发 项目。 标签主干和分支的整个想法可能与其中一些无关。
在考虑源代码存储库时，我的惯例是：
标签还可以为您提供可用的文档 url，例如：
“该版本可在 http://svnserver/myproject/tags/1.0"
它可能是：
“该版本可在http://svnserver/myproject/trunk@4483”
但是当你'浏览存储库时，您永远不会遇到 @4483 并知道它有任何特殊之处。
A subversion repository is just a single tree of files and folders, where you can get any portion of that tree at any version in its history at any time.
As others have said tags/branches/trunk is all just a convention on top of that, subversion allows you to copy one portion of the tree to somewhere else for (almost)free, but in it's core, that's about it.
You're right that you will need a maintenance branch for your version. The tag acts as your name for any particular version sent somewhere external - and the commit comment when you create the tag gives you a chance to explain where it went and why (eg, "public beta release", "requesting comments").
There are several hook scripts out there that prevent you making modifications to a tag, but they won't be implemented by default because some people use subversion in a completely different way (eg, config file backup, etc). Subversion is a generic tool, there's no 'right' way to use it, just strong conventions for common situations.
In fact, collabnet are starting to consider how revision control is used for non-development projects. The whole idea of tags trunk and branches may be irrelevant for some of these.
My convention when thinking about a source code repository is:
Tags can also give you a usable url for documentation, eg:
"The release is available at http://svnserver/myproject/tags/1.0"
It could be:
"The release is available at http://svnserver/myproject/trunk@4483"
But when you're browsing through the repository, you'll never come across @4483 and know that it was in any way special.
我们用它来标记有趣但不发布的特定构建，例如：“投资者演示”等。
We used it to tag specific builds that were interesting but not releases, e.g.: "Investor Demo", etc.
标签不打算被修改，如果你想这样做，你应该创建一个分支。
您可以从标签创建一个分支，这可能是您想要做的，然后将该分支的结果重新标记为不同的版本。
您不应该签出标签进行编辑。
在 SVN 中分支（复制）不会丢失任何历史记录。 这一切都是联系在一起的。
Tags are not intended to be modified, you should make a branch if you want to do that.
You can make a branch from a tag, which is probably what you would want to do, then re-tag the results of that branch as a different version.
You shouldn't checkout a tag for editing.
You don't lose any history by branching(copying) in SVN. It all is linked together.
标签应该引用一组文件的不可变“应用程序版本”。
（“应用程序的版本”而不是“VCS 使用的技术内部版本号”，例如 SVN 的修订版本、Git 的 SHA-1 或 ClearCase 的 id，或者...）
它们应该作为参考在另一个工作区中查询和部署（用于测试或 UAT - 用户验收测试 -），
因为 SVN 实现了像分支这样的标签：作为目录，修改文件中的文件的动机标签可以很强大，但会违背标签的目的。 其他 VCS 具有标签（或“基线”）的概念，一旦设置，就不能再移动。
George Mauer 对此评论：
“实施”？ 但他们并没有“实现”标签的概念。 SVN 本身没有“标签”。 他们只是重复使用了他们的分支，并说它也可以用作标签。
SVN RedBook 明确指出：
Tags are supposed to reference immutable "version of the application" of a set of files.
("version of the application" as opposed to "technical internal version number used by the VCS", like revision for SVN, or SHA-1 for Git, or id for ClearCase, or...)
They are supposed to serve as reference to be queried and deployed in another workspace (for testing or UAT - User Acceptance Tests -)
Since SVN implements tags like branches: as directory, the incentive to modify files in a tag can be strong, but would defeat the purpose of a tag. Other VCS has the notion of label (or "baseline") which, once set, can not be moved anymore.
To which George Mauer comments:
"implements" ? But they did not "implemented" the notion of tag. SVN has no "tag" per se. They just reused their branches and said it could be also used as a tag.
SVN RedBook clearly states: