再一次，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 实际上有四种不同的用途（参见 svn copy (cp)，位于 svn 参考 - 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 来接收你的精确更改。

虽然这是一种上传工作副本快速快照的好方法，但请注意，这 不是 创建分支的最佳方法。 创建分支应该是一个单独的事件，而这种方法将创建分支与对文件的额外更改混为一谈，并且这些更改都在单个修订版中完成。 这使得以后很难识别单个修订版号作为分支点。