转换工作拷贝

### 转换工作拷贝 **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**查看更多信息和例子。