本节内容尚未完善,可能会发生重大变更,可能无法准确描述任何已发布的 Apache™ Subversion® 软件版本。将此页面设为书签或以其他方式向他人推荐此页面可能不是明智之举。请访问 https://svnbooks.subversion.org.cn/ 获取此书的稳定版本。
svn relocate - 将工作副本重新定位到不同的仓库根 URL。
svn relocate FROM-PREFIX TO-PREFIX [PATH...]
svn relocate TO-URL [PATH]
有时,管理员可能会更改仓库的位置(或从客户端角度来看的明显位置)。仓库的内容不会改变,但仓库的根 URL 会改变。主机名可能会更改,因为仓库现在在不同的计算机上提供服务。或者,URL 方案可能会更改,因为仓库现在通过 SSL(使用 https://
)而不是普通 HTTP 提供服务。这些类型的仓库重新定位有很多不同的原因。但理想情况下,仓库的“地址变更”不应突然导致指向该仓库的所有工作副本永远不可用。幸运的是,情况并非如此。Subversion 提供了 svn relocate 命令,它可以“重写”工作副本的管理元数据以引用新的仓库位置,而不是强迫用户在仓库重新定位时签出新的工作副本。
第一个 svn relocate 语法允许您通过实质上等同于在工作副本中记录的仓库根 URL 中进行查找和替换来更新一个或多个工作副本。Subversion 将在这些 URL 中将初始子字符串 FROM-PREFIX
替换为字符串 TO-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 (sw) 中描述的 svn switch 的作用。)
此外,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
选项可以禁用此行为。