Subversion：有没有比“svnsync”更快的东西？
因此，我将我的颠覆存储库存储在某个云上（例如 code.google.com），但由于各种原因，我需要将我的代码设为非公开。
我决定需要下载整个存储库并迁移到我自己的 svn 服务器。
所以我开始使用：
svnsync init DEST SRC
svnsync sync DEST
存储库的每个修订大约需要 0.5 秒！
幸运的是，我的仓库只有大约 200 个修订……所以需要等待几分钟。但是那些有 200,000 或 2,000,000 次修改的成熟项目呢？
... 2e6 * 0.5 / 60 / 60 / 24 ~ 约11天！
有什么比“svnsync”更快地从云下载您的存储库吗？
So I have my subversion repository stored on some cloud (for example code.google.com) but due to various reasons I need to make my code non-public.
I decided I needed to download the entire repository and migrate to my own svn server.
So I went about using:
svnsync init DEST SRC
svnsync sync DEST
And it took about 0.5 seconds for each revision of the repo!
Luckily my repo only had like 200 revisions... so a couple of minutes to wait. But what about mature projects that have 200,000 or 2,000,000 revisions!
... 2e6 * 0.5 / 60 / 60 / 24 ~ about 11 days!
Is there anything faster than "svnsync" to download your repo from a cloud?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
我在拥有数十万个修订的存储库集合中也遇到了同样的问题。这是我解决这个问题的方法：
--force-uuid。现在您已准备好在主服务器上运行 svnsync。这将从您的转储停止的地方继续。
I have this same problem in my collection of repositories that have hundreds of thousands of revisions. Here is how I get around it:
--force-uuid.Now you are ready to run svnsync on your master server. This will continue from wherever your dump left off at.
是的，有。 VisualSVN 分布式文件系统 (VDFS) 执行的复制至少 10 次比通过 svnsync 进行复制更快。此外，镜像 VDFS 存储库是可写的。
该技术使分布式团队能够以相同的速度使用 Subversion 存储库，就好像他们都在同一个本地网络中一样。采用 VDFS 技术，主存储库可以跨多个站点和位置进行复制，从而实现高达 1000% 的读取操作加速。例如，50Gb 工作副本只需 10 分钟即可检出。通过常规互联网连接执行相同的任务至少需要一个小时。
Yes, there is. Replication performed by VisualSVN Distributed File System (VDFS) is at least 10 times faster than replication via
svnsync. Moreover mirrored VDFS repositories are writable.The technology enables distributed teams to work with Subversion repositories at the same speed as if they all were in the same local network. Employing the VDFS technology, the main repository can be replicated across multiple sites and locations which results in up to 1000% read operations speedup. For instance, the 50Gb working copy can be checked out in as little as 10 minutes. The same task performed over a regular internet connection would take an hour at the very least.
嗯，显然您可以自己在服务器上备份它，然后压缩并下载它。或者您可以不下载所有历史记录。
但这个问题有什么意义呢？这有点学术性，因为你的问题已经解决了。
Well, obviously you could back it up yourself on the server and then zip it and download it. Or you could just not download all the history.
But what's the point of this question? It's a bit academic, as your problem is solved.
在OP的情况下，您没有控制台访问svn服务器的情况，
svnsync（本质上是来自URL 1的svn checkout与svn commit相结合code> 到 URL 2) 就如您所愿。但如果您确实有权访问服务器，则有比 svnsync 更快的方法。构建镜像的一种好方法是使用 svnadmin hotcopy 制作存储库的初始副本，然后使用 svnsync init --allow-non-empty 选项 在subversion 1.7中添加将其变成镜像。这也为您提供了钩子等的备份，否则 svnsync 不会这样做。
请注意，您需要将
hooks目录移动到hooks-original或其他目录，这样镜像就不会使用它们——特别是如果您有一个 post-调用 svnsync 同步的原始存储库上的提交钩子！In the OP's case, where you do not have console access to the svn server,
svnsync(which is essentiallysvn checkoutfrom URL 1 combined withsvn committo URL 2) is as good as you are going to get.But if you do have access to the server, there are faster ways than
svnsync. One good method to build a mirror is usesvnadmin hotcopyto make the initial copy of the repository, then use thesvnsync init --allow-non-emptyoption added in subversion 1.7 to turn it into a mirror. This also gives you a backup of your hooks etc. which svnsync will not otherwise do.Note that you will want to move your
hooksdirectory tohooks-originalor something so that they will not be used by the mirror---especially if you have a post-commit hook on the original repo that callssvnsync sync!