如何将现有目录转换为 SVN 工作副本 (WC)，而不替换本地文件？
我有一个大型 Subversion 存储库，其中包含近 15 GB 的数据，分布在约 500,000 个文件中。 现在我需要将此存储库签出到远程主机，这需要几天时间才能完成。
我要签出的主机已经在存储库中拥有完整的数据副本。 但由于这些文件不是直接从存储库中签出的，因此它们不构成工作副本（没有“.svn”文件夹）。
我想避免通过网络复制所有这些数据，特别是当它已经存在于目标主机上时。 我可以使用一个技巧将预先存在的目录转换为工作副本，而不用存储库中的相同副本替换本地文件吗？
I have a large Subversion repository with nearly 15 GB of data spread across ~500,000 files. Now I need to check out this repository to a remote host which would take days to complete.
The host I'm checking out to already has a complete copy of the data in the repository. But seeing as the files weren't checked out directly from the repository, they do not constitute a working copy (no ".svn" folders).
I'd like to avoid copying all this data across the network, especially when it already exists on the target host. Is there a trick I can use that will turn a preexisting directory into a working copy without replacing the local files with identical copies from the repository?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（10）
从 SVN 1.7 开始（但不是之前），您可以使用以下命令轻松完成此操作：
svn co --force http://path/to/repo这将尊重现有的本地副本，您将请参阅输出中每个文件名之前存在的“E”：
E some/existing/file如果文件与存储库不同（新的或修改的），它也会根据 本书：
另请注意，SVN 1.7 可能会导致这种情况成为更常见的问题（也许会激发解决方案）。 当我将子目录移动到磁盘上的新位置时，我遇到了这个问题。 在 1.7 之前的版本中，
.svn目录会随之移动，并且它可以单独存在。 在 1.7 中，该目录实际上已取消版本控制。 但 svn co --force 挽救了局面。As of SVN 1.7 (but not before) you can do this easily with:
svn co --force http://path/to/repoThis will respect the local copy as existing, and you'll see the "E" for existing before each file name in the output:
E some/existing/fileIf the file is different (new or modified) from the repository it will handle that gracefully too according to the book:
Also note that SVN 1.7 can lead to situations where this a more common problem (perhaps motivating the solution). I hit this problem when moving a sub directory to a new location on disk. In pre-1.7 that would have moved the
.svndirectory with it and it would have stood alone just fine. In 1.7 the directory became effectively unversioned. Butsvn co --forcesaved the day.有重定位命令： http://svnbook.red-bean.com/ en/1.1/re27.html
编辑：
如果本地文件未链接到存储库，那么您可以创建一个本地存储库，将文件导入其中，然后使用重新定位命令。
或者，如果您对两台计算机都有物理访问权限，则可以查看存储在本地，然后通过外部硬盘将文件复制到远程计算机。
There is the relocate command: http://svnbook.red-bean.com/en/1.1/re27.html
EDIT:
If the local files aren't linked to a repository then you could create a local repository, import the files into it and then use the relocate command.
Alternatively if you have physical access to both machines you can you check out the repository locally and then copy the files to the remote machine via a external HD.
如果您已经在网络上其他地方有一个受 svn 控制的工作副本，您可以尝试使用 rsync。
You could try using rsync if you already have a working copy under svn control somewhere else on the network.
svn co --force https://PATH/TO/REPO/ .其中末尾的
.假定您已经位于要转换为的目录内工作 SVN 副本。例如，如果您想让
public_html目录成为存储库的工作 svn 副本：cd /home/username/public_html; svn co --force https://PATH/TO/REPO/ 。svn co --force https://PATH/TO/REPO/ .Where the
.at the end assumes you are already inside the directory which you want to turn into a working SVN copy.For instances, if you wanted to make your
public_htmldirectory a working svn copy of a repository:cd /home/username/public_html; svn co --force https://PATH/TO/REPO/ .以下命令是删除所有 .svn 目录。
如果您已有签出版本，可以尝试通过将
rm替换为cp来复制这些.svn文件夹。 不过我没有尝试。The following command is to delete all .svn directories.
If you already have a checkout version, you can try to copy those
.svnfolders by replacingrmwithcp. I didn't try though.您可以在本地签出存储库，然后仅传输 .svn 目录（小心，它们包含工作区文件的副本，显然您不想复制这些文件）。 这应该可行，因为您将拥有正确工作副本的确切文件。
当然，您必须编写某种脚本来传输 .svn 文件。 在 Unix 系统上，您可以使用 find 和friends 来完成此操作。
You could just checkout the repository locally, then transfer only the .svn directories (careful, they contain copies of the workspace files, obviously you don't want to copy those). That should work, as you would have the exact files of a correct working copy.
Of course you'd have to write some kind of script to transfer the .svn files. On a Unix system you could do it with find and friends.
本机 svn 命令都不会检查现有文件是否匹配，并且不会下载它们。
您使用什么协议来访问存储库？ 如果是https，那可能是你的问题。 尝试本机 svn 协议（使用 svnserve），或 svn+ssh。 或者甚至可以通过托管 svn 存储库的服务器上的 file:// URL 进行结帐，然后使用 rsync 通过网络传输。
只要您不为每字节的带宽付费，让“svn co --force”在nice或（Windows上的START / LOW）下运行而不是浪费您的资源可能是有意义的自己的时间。 在签出过程中，它不会使本地文件系统上的任何内容不可用。
最后，我不明白为什么你的结帐这么慢......我们有 500K 文件存储库，通过千兆位 LAN 上的 https 在大约 6 分钟内结帐。 当然，所有文件都小得多（总共 1 GB）。 就延迟而言，您距离服务器有多远？
None of the native svn commands will checksum existing files for matches and not download them.
What protocol are you using to access the repository? If it is https, that may be your problem. Try the native svn protocol (using svnserve), or svn+ssh. Or perhaps even do a checkout via a file:// URL on the server hosting the svn repo, andthen use rsync to transfer across the network.
So long as you are not paying for the bandwidth per-byte, it might just make sense to let "svn co --force" run under nice or (START /LOW on Windows) and not waste your own time. It will not make anything on the local filesystem unavailable during the checkout process.
Finally, I can't figure out why your checkout is so slow... we have 500K file repositories that checkout in ~6 minutes via https on a gigabit LAN. Granted all the files are much smaller (1 GB total). How far away from the server are you in terms of latency?
在服务器上进行签出，在本地（服务器本地）创建工作副本，然后通过现有目录结构将该工作副本同步到远程系统。
使用 Subversion 1.7，这样就不存在带有文件原始副本的 .svn。
Do a checkout on the server, creating a working copy in local (local to the server), then rsync that working copy to the remote system over the existing directory structure.
Use Subversion 1.7, that way there's no .svn with pristine copies of the files.
我的本地计算机上有一个工作存储库，当 Eclipse 崩溃时，它的所有 .svn 文件夹都被删除了。
我能够将其连接到远程 SVN 存储库的唯一方法是按照我找到的博客中的以下步骤进行操作（恢复损坏的 Subversion 工作副本）：
I had a working repository on my local computer that got all of its .svn folders deleted when Eclipse crashed.
The only way I was able to connect it to the remote SVN repository was to follow these steps from a blog I found (Recovering a broken Subversion working copy):
我认为如果不将这 15 GB 传输到目的地就没有解决方案。
将存储库复制到那里并进行本地签出可能会更快更容易。
I don't believe there's a solution without transferring those 15 GBs to the destination.
It would probably be faster and easier to copy the repository there and do a local checkout.