再次，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 351.

这个例子假设/calc/tags目录已经存在。（如果不存在，请参见 svn mkdir）。复制完成后，新的release-1.0目录将永远是您进行复制时项目在HEAD修订版中的快照。当然，您可能希望更精确地确定要复制的修订版，以防其他人可能在您没有注意到的情况下对项目进行了更改。因此，如果您知道修订版 350 的/calc/trunk正是您想要的快照，您可以通过传递-r 350给 svn copy 命令来指定它。

但是等等：这个标签创建过程不是我们用来创建分支的过程吗？是的，实际上是。在 Subversion 中，标签和分支之间没有区别。两者都是通过复制创建的普通目录。与分支一样，复制目录成为“标签”的唯一原因是因为 人 决定将其视为标签：只要没有人提交到目录，它将永远保持为快照。如果人们开始提交到它，它就变成一个分支。

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

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

例如，假设您的项目比我们的calc示例大得多：假设它包含许多子目录和更多文件。在您的工作过程中，您可能会决定需要创建一个工作副本，该副本设计为具有特定的功能和错误修复。您可以通过选择性地将文件或目录回滚到特定修订版（ liberally 使用 svn update -r）或将文件和目录切换到特定分支（使用 svn switch）来完成此操作。完成后，您的工作副本将是来自不同修订版的版本库位置的大杂烩。但是经过测试后，您知道它是您需要的精确数据组合。

是时候创建快照了。将一个 URL 复制到另一个 URL 这里行不通。在这种情况下，您要对您的精确工作副本安排进行快照，并将其存储在版本库中。幸运的是，svn copy 实际上有四种不同的用法（您可以在第 9 章中阅读），包括将工作副本树复制到版本库的能力

$ ls
my-working-copy/

$ svn copy my-working-copy http://svn.example.com/repos/calc/tags/mytag

Committed revision 352.

现在版本库中有一个新的目录，/calc/tags/mytag，它正是您的工作副本的快照——混合修订版、URL 和所有内容。

其他用户发现此功能有其他有趣的用途。有时会出现这样的情况：您对工作副本进行了一些本地更改，并且希望您的合作者看到这些更改。与其运行 svn diff 并发送补丁文件（无法捕获树更改），不如使用 svn copy 将您的工作副本“上传”到版本库的私有区域。然后，您的合作者可以签出您的工作副本的逐字副本，或者使用 svn merge 来接收您的精确更改。