本文档旨在描述 Apache™ Subversion® 的 1.7.x 系列。如果您运行的是其他版本的 Subversion,强烈建议您访问 https://svnbook.subversion.org.cn/ 并查阅适合您 Subversion 版本的文档。
svn relocate — 将工作副本重新定位到不同的仓库根 URL。
有时,管理员可能会更改仓库的位置(或从客户端的角度来看,是明显的位置)。仓库的内容不会改变,但仓库的根 URL 会改变。主机名可能会改变,因为仓库现在正在从不同的计算机上提供服务。或者,URL 方案可能会改变,因为仓库现在正在通过 SSL(使用 https://
)而不是普通 HTTP 提供服务。这些类型的仓库重新定位有很多不同的原因。但理想情况下,仓库的 “地址变更” 不应该突然导致所有指向该仓库的工作副本永远无法使用。幸运的是,情况并非如此。Subversion 提供了 svn relocate 命令,它可以 “重写” 工作副本的管理元数据以引用新的仓库位置,而不是强制用户在仓库重新定位时检出一个新的工作副本。
第一个 svn relocate 语法允许您通过本质上等同于在记录在这些工作副本中的仓库根 URL 中进行查找和替换来更新一个或多个工作副本。Subversion 将在这些 URL 中用字符串 TO-PREFIX
替换初始子字符串 FROM-PREFIX
。这些初始 URL 子字符串可以根据需要长或短,以区分它们。显然,要使用此语法形式,您需要知道工作副本指向的仓库的当前根 URL 和该仓库的新 URL。(您可以使用 svn info 来确定前者。)
第二种语法不需要您知道工作副本关联的当前仓库根 URL,只需要知道它应该指向的新仓库 URL (TO-URL
)。在这种语法形式下,一次只能重新定位一个工作副本。
警告 | |
---|---|
用户经常会混淆 svn switch 和 svn relocate 的区别。这里有一个经验法则:
|
让我们从一个反映本地仓库 URL 的工作副本开始
$ svn info | grep URL: URL: file:///var/svn/repos/trunk $
有一天,管理员决定重命名磁盘上的仓库目录。我们错过了备忘录,因此在下一次尝试更新工作副本时,我们看到了错误。
$ svn up Updating '.': svn: E180001: Unable to connect to a repository at URL 'file:///var/svn/repos/trunk'
在角落里找到管理员后,我们了解到仓库被移动了,并被告知了新的 URL。但是,我们没有检出一个新的工作副本,而是简单地要求 Subversion 重新编写工作副本元数据以指向新的仓库位置。
$ svn relocate file:///var/svn/new-repos/trunk $
Subversion 没有告诉我们它做了什么,但嘿,无错误操作是我们真正需要的,对吧?我们的工作副本再次可以用于在线操作。
$ svn up Updating '.': A lib/new.c M src/code.h M src/headers.h …
注意 | |
---|---|
再次强调,这种类型的重新定位仅影响 工作副本元数据。它不会更改您的版本化或未版本化文件内容,执行任何版本控制操作(例如提交或更新)等等。 |
几个月后,我们被告知公司正在将开发迁移到独立的机器,我们将使用 HTTP 访问仓库。因此,我们再次重新定位了工作副本。
$ svn relocate http://svn.company.com/repos/trunk $
现在,每次我们执行这种类型的重新定位时,Subversion 都会联系仓库(当然,在它的新 URL 上)以验证一些事情。
首先,它希望将仓库的 UUID 与存储在工作副本中的 UUID 进行比较。如果这些 UUID 不匹配,则不允许工作副本重新定位。也许这毕竟不是同一个仓库(只是在新的位置)?
其次,Subversion 希望确保更新后的工作副本元数据与仓库 内部 的目录位置相符。Subversion 不会让您意外地将仓库中分支的工作副本重新定位到同一仓库中不同分支的 URL。(这就是 svn switch 的作用,如 svn switch (sw) 中所述。)
此外,Subversion 不会允许您重新定位工作副本的子树。如果您要重新定位工作副本,则必须重新定位整个工作副本。这是为了保护工作副本元数据和整体行为的完整性。(实际上,您很难找到一个令人信服的理由来仅仅重新定位工作副本的一部分。)
让我们看一下最后一次重新定位的机会。在使用 HTTP 访问一段时间后,公司迁移到仅 SSL 访问。现在,存储库 URL 的唯一更改是方案从 http://
变为 https://
。我们可以通过两种不同的方式使我们的工作副本反映此更改。第一种方法是像以前一样,重新定位到新的存储库 URL。
$ svn relocate https://svn.company.com/repos/trunk $
但是,我们还有另一个选择。我们可以简单地要求 Subversion 交换 URL 中更改的前缀。
$ svn relocate http https $
无论哪种方法,我们都将获得一个工作副本,其元数据已更新以指向正确的存储库位置。
默认情况下,svn relocate 将遍历嵌套在工作副本中的任何外部工作副本,并尝试重新定位这些工作副本。使用 --ignore-externals
选项来禁用此行为。