如何在不替换本地文件的情况下将现有目录转换为 SVN 工作副本 (WC)？答案

【问题标题】：How do I convert an existing directory to an SVN working copy (WC) without replacing local files?如何在不替换本地文件的情况下将现有目录转换为 SVN 工作副本 (WC)？
【发布时间】：2010-10-26 01:12:13
【问题描述】：

我有一个大型 Subversion 存储库，其中包含近 15 GB 的数据，分布在大约 500,000 个文件中。现在我需要将此存储库签出到远程主机，这需要几天时间才能完成。

我要签出的主机已经拥有存储库中数据的完整副本。但是由于文件没有直接从存储库中检出，它们不构成工作副本（没有“.svn”文件夹）。

我想避免通过网络复制所有这些数据，尤其是当目标主机上已经存在这些数据时。有没有我可以使用的技巧将预先存在的目录转换为工作副本，而无需使用存储库中的相同副本替换本地文件？

【问题讨论】：

只是出于好奇：您在该存储库中保留了什么？我从来没有听说过这么大的回购。
原始音频，主要是口语。
这听起来像是“如何在清理掉 .svn 目录后恢复它们”或“我做了一个需要几天时间的导出。但我也想要 .svn 文件......”
您不能将rsync 与--ignore-existing 一起使用，并复制存储库（即.svn 目录）吗？（不确定这个世界是否有效，只是在想..）

标签： svn working-copy

【解决方案1】：

从 SVN 1.7（但不是之前）开始，您可以通过以下方式轻松做到这一点：

svn co --force http://path/to/repo

这会将本地副本视为存在，并且您会在输出中的每个文件名之前看到“E”表示存在： E some/existing/file

如果文件与存储库不同（新的或修改的），它也会根据the book 优雅地处理：

在 1.7 版之前，如果您尝试检出现有目录之上的目录，其中包含检出本身会创建的文件或子目录，Subversion 默认会报错。 Subversion 1.7 以不同的方式处理这种情况，允许检出继续，但将任何阻碍对象标记为树冲突。使用 --force 选项覆盖此保护措施。当您使用 --force 选项检出时，检出目标树中通常会阻碍检出的任何未版本化文件仍将变为版本化，但 Subversion 将按原样保留其内容。如果这些内容与该路径上的存储库文件（作为检出的一部分下载）不同，则该文件将显示为具有本地修改 - 将您检出的版本化文件转换为您在检出之前拥有的未版本化文件所需的更改out - 结帐完成时。

另请注意，SVN 1.7 可能会导致这是一个更常见的问题（可能会激发解决方案）。我在将 sub 目录移动到磁盘上的新位置时遇到了这个问题。在 1.7 之前的版本中，它会移动 .svn 目录，并且它可以独立存在。在 1.7 中，该目录实际上是未版本化的。但是svn co --force 挽救了这一天。

【讨论】：

但是，这会将存储库中的文件（如果在本地找不到）添加到本地目录。我怎么能避免这种情况？并告诉 svn：这是新的工作副本，处理它！

【解决方案2】：

我的本地计算机上有一个工作存储库，当 Eclipse 崩溃时，它的所有 .svn 文件夹都被删除了。

我能够将其连接到远程 SVN 存储库的唯一方法是按照我找到的博客 (Recovering a broken Subversion working copy) 中的这些步骤进行操作：

# Backup your project in case you run into trouble
cp -Rp /path/to/project /temporary/location

# Strip out the old .svn folders (if any)
find /path/to/project -name .svn -print0 | xargs -0 rm -rf

# Check out a clean copy
svn co http://repo/location /temporary/location2

# Move the .svn folders from the clean copy into the correct relative
# place in the broken copy
cd /temporary/location2
find . -name .svn -print0 | xargs -0 -I {} mv '{}' '/path/to/project/{}'

# Remove the clean copy
rm -rf /temporary/location2

【讨论】：

【解决方案3】：

以下命令是删除所有.svn目录。

chmod -R 0755 project_dir
find /project_dir -type d -name .svn -exec rm -rf '{}' +

如果您已经有结帐版本，您可以尝试通过将rm 替换为cp 来复制那些.svn 文件夹。不过我没试过。

【讨论】：

【解决方案4】：

svn co --force https://PATH/TO/REPO/ .

最后的. 假设您已经在要转换为工作 SVN 副本的目录中。

例如，如果您想让您的public_html 目录成为存储库的工作 svn 副本：

cd /home/username/public_html; svn co --force https://PATH/TO/REPO/ .

【讨论】：

这个答案比当前接受的包含相同信息的答案好多少？
接受的答案忽略了当前目录显式表达式的重要性。

【解决方案5】：

在服务器上进行检查，在本地（服务器本地）创建工作副本，然后通过现有目录结构将该工作副本同步到远程系统。

使用 Subversion 1.7，这样就没有带有原始文件副本的 .svn。

【讨论】：

【解决方案6】：

本机 svn 命令都不会校验现有文件的匹配项并且不会下载它们。

您使用什么协议来访问存储库？如果是https，那可能是您的问题。试试原生 svn 协议（使用 svnserve），或者 svn+ssh。或者甚至可以通过托管 svn 存储库的服务器上的 file:// URL 进行结帐，然后使用 rsync 通过网络传输。

只要您不为每字节的带宽支付，让“svn co --force”在 nice 或（Windows 上的 START /LOW）下运行可能是有意义的，并且不要浪费自己的时间。它不会在结帐过程中使本地文件系统上的任何内容不可用。

最后，我无法弄清楚为什么您的结帐速度如此之慢...我们有 500K 文件存储库，通过千兆位 LAN 上的 https 在大约 6 分钟内结帐。当然，所有文件都小得多（总共 1 GB）。就延迟而言，您离服务器有多远？

【讨论】：

【解决方案7】：

您可以在本地签出存储库，然后仅传输 .svn 目录（小心，它们包含工作区文件的副本，显然您不想复制这些）。这应该可行，因为您将拥有正确工作副本的确切文件。

当然，您必须编写某种脚本来传输 .svn 文件。在 Unix 系统上，您可以使用 find 和 Friends 来完成。

【讨论】：

-1 如果他有大约 500,000 个文件，想象一下“小心”移动所有 .svn 文件夹？
当然你会使用一些脚本。 “小心”是在编写这样的脚本时警告潜在的问题。
我考虑过这一点，但正如 Victor 指出的那样，对于如此大的回购，这可能会非常乏味。此外，工作副本的“.svn/text-base”文件夹包含 repo 中所有文件的原始副本，因此即使仅复制 .svn 文件夹仍需要完整的数据副本。
是的，当然，这就是我提到脚本的原因。我不希望任何人手动复制所有内容：-/。当然，您不会复制 text-base 下的内容，您只需创建 emtpy 目录“.svn/text-base”，然后将现有文件从目标复制到 text-base。是的，这可能需要一些编程，但它仍然胜过重新复制 15 GiB。

【解决方案8】：

如果您在网络上的其他地方已经有一个受 svn 控制的工作副本，您可以尝试使用 rsync。

【讨论】：

这不是一个坏主意，但正如另一条评论中提到的，.svn/text-base 文件夹包含所有 repo 文件的原始副本，因此 rsync 最终会复制所有数据反正结束了。您可以告诉 rsync 忽略复制“text-base”，然后在 .svn 文件夹同步后编写脚本来填充“text-base”。

【解决方案9】：

如果不将这 15 GB 传输到目的地，我认为没有解决方案。将存储库复制到那里并进行本地签出可能会更快、更容易。

【讨论】：

好吧，有趣的是，你提出这个建议是因为我尝试只检查服务器本身的本地工作副本。即使是本地结帐也需要一天多的时间才能完成，这不包括转储/复制/加载到远程主机上的新存储库所需的时间。

【解决方案10】：

有重定位命令：http://svnbook.red-bean.com/en/1.1/re27.html

编辑：如果本地文件没有链接到存储库，那么您可以创建一个本地存储库，将文件导入其中，然后使用 relocate 命令。

或者，如果您对两台计算机都有物理访问权限，您可以在本地签出存储库，然后通过外部 HD 将文件复制到远程计算机。

【讨论】：

我不明白你如何在这里使用 relocate。 relocate 仅更新 .svn 文件夹中的元数据。根据 OP，没有 .svn 文件夹。
我怀疑这会起作用，因为您只能重新定位到具有相同存储库 UID 的存储库
我上面链接的文档说：如果工作副本仍然反映相同的存储库目录，但存储库本身的位置已经改变，那么使用 svn switch --relocate。