### 转换工作拷贝 **svn switch**命令改变存在的工作拷贝到另一个分支,然而这个命令在分支上工作时不是严格必要的,它只是提供了一个快捷方式。在前面的例子里,完成了私有分支的建立,你取出了新目录的工作拷贝,相反,你可以简单的告诉Subversion改变你的`/calc/trunk`的工作拷贝到分支的路径: ~~~ $ cd calc $ svn info | grep URL URL: http://svn.example.com/repos/calc/trunk $ svn switch http://svn.example.com/repos/calc/branches/my-calc-branch U integer.c U button.c U Makefile Updated to revision 341. $ svn info | grep URL URL: http://svn.example.com/repos/calc/branches/my-calc-branch ~~~ 完成了到分支的“跳转”,你的目录与直接取出一个干净的版本没有什么不同。这样会更有效率,因为分支只有很小的区别,服务器只是发送修改的部分来使你的工作拷贝反映分支。 **svn switch**命令也可以带`--revision`(`-r`)参数,所以你不需要一直移动你的工作拷贝到最新版本。 当然,许多项目比我们的`calc`要复杂的多,有更多的子目录,Subversion用户通常用如下的法则使用分支: 1. 拷贝整个项目的“trunk”目录到一个新的分支目录。 1. 只是转换工作拷贝的*部分*目录到分支。 换句话说,如果一个用户知道分支工作只发生在部分子目录,我们使用**svn switch**来跳转部分目录(有时候只是单个文件),这样的话,他们依然可以继续得到普通的“trunk”主干的更新,但是已经跳转的部分则被免去了更新(除非分支上有更新)。这个特性给“混合工作拷贝”概念添加了新的维度―不仅工作拷贝的版本可以混合,在版本库中的位置也可以混合。 如果你的工作拷贝包含许多来自不同版本库目录跳转的子树,它会工作如常。当你更新时,你会得到每一个目录适当的补丁,当你提交时,你的本地修改会一直作为一个单独的原子修改提交到版本库。 注意,因为你的工作拷贝可以在混合位置的情况下工作正常,但是所有的位置必须在同一个版本库,Subversion的版本库不能互相通信,这个特性还不在Subversion 1.0的计划里。 **跳转和更新** 你注意到**svn switch**和**svn update**的输出很像?switch命令只是update命令的一个超集。 当你运行**svn update**时,你会告诉版本库比较两个目录树,版本库这样做,并且返回给客户区别的描述,**svn switch**和**svn update**两个命令唯一区别就是**svn update**会一直比较同一路径。 也就是了,如果你的工作拷贝是`/calc/trunk`的一个镜像,当运行**svn update**时会自动地比较你的工作拷贝的`/calc/trunk`与HEAD版本的`/calc/trunk`。如果你使用**svn switch**跳转工作拷贝到分支,则会比较你的工作拷贝的`/calc/trunk`与相应分支目录的HEAD版本。 换句话说,一个更新通过时间移动你的工作拷贝,一个转换通过时间和空间移动工作拷贝。 因为**svn switch**是**svn update**的一个变种,具有相同的行为,当新的数据到达时,任何工作拷贝的已经完成的本地修改会被保存,这里允许你作各种聪明的把戏。 举个例子,你的工作拷贝目录是`/calc/trunk`,你已经做了很多修改,然后你突然发现应该在分支上修改更好,没问题!你可以使用**svn switch**,而你本地修改还会保留,你可以测试并提交它们到分支。 [[11](#)] 当你的服务器位置改变,而你不想放弃存在的本地拷贝,你*可以*使用带选项`--relocate`的**svn switch**命令转换URL,见[第9章 *Subversion完全参考*]( "第9章Subversion完全参考")的**svn switch**查看更多信息和例子。