再次，svn copy 来拯救我们。如果您想创建 /calc/trunk 的快照，使其与 HEAD 版本中的一致，请复制它

$ svn copy http://svn.example.com/repos/calc/trunk \
           http://svn.example.com/repos/calc/tags/release-1.0 \
      -m "Tagging the 1.0 release of the 'calc' project."

Committed revision 902.

此示例假设 /calc/tags 目录已经存在。（如果不存在，您可以使用 svn mkdir 创建它。）复制完成后，新的 release-1.0 目录将永远成为 /trunk 目录在您创建复制时在 HEAD 版本中外观的快照。当然，您可能希望更精确地指定要复制的版本，以防其他人可能在您没有注意的时候提交了项目更改。因此，如果您知道 /calc/trunk 的第 901 个版本正是您想要的快照，则可以通过将 -r 901 传递给 svn copy 命令来指定它。

但请稍等：这种标签创建过程难道不是我们用来创建分支的过程吗？是的，实际上是。在 Subversion 中，标签和分支之间没有区别。两者都是通过复制创建的普通目录。就像分支一样，复制的目录被称为 “标签” 的唯一原因是 人类 决定以这种方式对待它：只要没有人提交到该目录，它就会永远保持为快照。如果人们开始提交到它，它就会成为分支。

如果您是仓库管理员，您可以采用两种方法来管理标签。第一种方法是 “放任自流”：作为项目策略的一部分，决定您的标签将在哪里，并确保所有用户都知道如何对待他们复制的目录。（也就是说，确保他们知道不要提交到它们。）第二种方法更加谨慎：您可以使用 Subversion 提供的访问控制脚本之一来阻止任何人除了在标签区域创建新副本之外的任何操作（参见 第 6 章，服务器配置）。但是，谨慎的方法通常没有必要。如果用户意外地将更改提交到标签目录，您可以简单地撤消该更改，如上一节所述。毕竟，这就是版本控制！

有时您可能希望您的 “快照” 比单个目录在单个版本中更复杂。

例如，假设您的项目比我们的 calc 示例大得多：假设它包含许多子目录和更多文件。在您的工作过程中，您可能会决定需要创建一个工作副本，该工作副本旨在具有特定功能和错误修复。您可以通过选择性地将文件或目录回退到特定版本（使用 svn update 以及大量使用 -r 选项），通过将文件和目录切换到特定分支（使用 svn switch），或者甚至只是通过进行一些本地更改来完成此操作。完成之后，您的工作副本是来自不同版本的仓库位置的混合体。但是经过测试后，您知道它正是您需要标记的数据组合。

是时候创建快照了。将一个 URL 复制到另一个 URL 这里行不通。在这种情况下，您希望对您的确切工作副本排列创建快照，并将其存储在仓库中。幸运的是，svn copy 实际上有四种不同的用途（您可以在 第 9 章，Subversion 完整参考 中阅读有关它们的信息），包括将工作副本树复制到仓库的能力

$ ls
my-working-copy/

$ svn copy my-working-copy \
           http://svn.example.com/repos/calc/tags/mytag \
           -m "Tag my existing working copy state."

Committed revision 940.

现在仓库中有一个新的目录，/calc/tags/mytag，它是一个对您的工作副本的精确快照——混合版本、URL、本地更改等等。

其他用户也发现此功能有趣。有时会出现您对工作副本进行了一些本地更改，并且您希望合作者看到这些更改的情况。与其运行 svn diff 并发送补丁文件（它不会捕获目录、符号链接或属性更改），您可以使用 svn copy 将您的工作副本“上传”到仓库的私有区域。然后，您的合作者可以查看您的工作副本的逐字副本，也可以使用 svn merge 来接收您的确切更改。

虽然这是上传工作副本的快速快照的好方法，但请注意，这 不是 初始创建分支的好方法。分支创建应该是一件独立的事情，而这种方法将分支的创建与对文件的额外更改混为一谈，全部在一个版本内完成。这使得（以后）很难将单个版本号识别为分支点。