标签

另一个常见的版本控制系统概念是标签(tag),一个标签只是一个项目某一时间的“快照”,在Subversion里这个概念无处不在—每一次提交的修订版本都是一个精确的快照。

然而人们希望更人性化的标签名称,像release-1.0。他们也希望可以对一个子目录快照,毕竟,记住release-1.0是修订版本4822的某一小部分不是件很容易的事。

建立最简单的标签

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),拷贝完成之后,一个表示当时HEAD版本的/calc/trunk目录的镜像已经永久的拷贝到release-1.0目录。当然,你会希望更精确一点,以防其他人在你不注意的时候提交修改,所以,如果你知道/calc/trunk的版本350是你想要的快照,你可以使用svn copy加参数 -r 350

但是等一下:标签的产生过程与建立分支是一样的?是的,实际上在Subversion中标签与分支没有区别,都是普通的目录,通过copy命令得到,与分支一样,一个目录之所以是标签只是人们决定这样使用它,只要没有人提交这个目录,它永远是一个快照,但如果人们开始提交,它就变成了分支。

如果你管理一个版本库,你有两种方式管理标签,第一种方法是禁止命令:作为项目的政策,我们要决定标签所在的位置,确定所有用户知道如何处理拷贝的目录(也就是确保他们不会提交他们),第二种方法看来很过分:使用访问控制脚本来阻止任何想对标签目录做的非拷贝的操作(见第 6 章 配置服务器)这种方法通常是不必要的,如果一个人不小心提交了到标签目录一个修改,你可以简单的取消,毕竟这是版本控制啊。

建立复杂的标签

有时候你希望你的“快照”能够很复杂,而不只是一个单独修订版本的一个单独目录。

举个例子,假定你的项目比我们的的例子calc大的多:假设它保存了一组子目录和许多文件,在你工作时,你或许决定创建一个包括特定特性和Bug修正的工作拷贝,你可以通过选择性的回溯文件和目录到特定修订版本(使用svn update -r)来实现,或者转换文件和目录到特定分支(使用svn switch),这样做之后,你的工作拷贝成为版本库不同版本和分支的司令部,但是经过测试,你会知道这是你需要的一种精确数据组合。

是时候进行快照了,拷贝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来接受你的精确修改。