我有一个大型存储库，100,000多个修订版，具有非常高的分支因子。使用git-svn初始获取完整的SVN存储库已经运行了大约2个月，并且只能达到修订版60,000。有没有办法加速这件事？
由于git-svn像筛子一样泄漏内存，我已经经常杀死并重新启动抓取。传输通过本地LAN进行，因此链接速度不应成为问题。存储库位于专用光纤通道阵列支持的专用机器上，因此服务器应该有足够的功能。我能想到的另一件事是从SVN存储库的本地副本进行克隆。
其他人在类似情况下做了什么？
答案 0 :(得分：22)
在工作中我使用git-svn对抗~170000修订版SVN回购。我所做的是使用git-svn init + git-svn fetch -r...将我的初始提取限制为合理数量的修订。您必须小心选择实际位于所需分支中的修订。即使截断历史除了 git-blame，所有内容都完全正常运行，这显然将所有早于起始转速的行归于第一轮。
您可以使用ignore-paths进一步加快速度，以删除您不想要的子树。
您可以稍后添加更多修订，但这会很痛苦。你将不得不重置rev-map（遗憾的是我甚至写了git-svn reset并且我不能随便说它是否会删除所有版本，所以它可能是手工制作的）。然后git-svn fetch多次修订，git-filter-branch将旧的根重新显示到新树。这将重写每次提交，但不会影响源blob本身。当人们对svn回购进行大规模的重组时，你必须做类似的手术。
如果您确实需要所有修订版（例如迁移），那么您应该看一下svn-fast-export + git-fast-import的一些风格。可能有一个添加rev标签来匹配git-svn，在这种情况下你可以快速导入然后只是移植到svn遥控器。即使现有的svn-fast-export选项没有该功能，您也可以在原始克隆完成之前添加它！
答案 1 :(得分：14)
显然没有好的答案。一些工作正在进行git-fast-import，但尚未准备好迎接黄金时段。他们仍在试图弄清楚如何检测和表示'svn cp'动作。一个亮点是名单上的某个人想出了git-svn的优化，这似乎产生了很大的影响。
http://permalink.gmane.org/gmane.comp.version-control.git/168718
答案 2 :(得分：5)
在拥有20k提交的存储库中，我遇到了类似的问题。在我的情况下，事实证明subversion中有一些奇怪的标签导致了问题。有标签复制/而不是/ trunk。这导致git svn fetch进入无限循环。 我通过转换块来修复它。
git svn fetch -r0:1000
git svn fetch -r0:2000
git svn fetch -r0:3000
观看输出，如果你偶尔看不到新的......那就错了。
使用git log --all查看转化的程度。假设你到了1565.然后继续像这样取。
git svn fetch -r1567:2000
这非常繁琐，但它完成了工作。
答案 3 :(得分：3)
如果您可以找到具有足够RAM的服务器，请在ramdisk上执行整个克隆操作。在Linux系统上，您可以使用/ dev / shm，它由RAM支持。
> svnadmin hotcopy /path/to/svn/repo /dev/shm/svn-repo
> git svn clone file:///dev/shm/svn-repo /dev/shm/git-repo
一旦完成，你可以将git repo指回你真正的svn回购，而不是如下所述：https://git.wiki.kernel.org/index.php/GitSvnSwitch
- 编辑.git / config中的svn-remote url URL以指向新域名
- 运行git svn fetch - 这需要从svn获取至少一个新版本！
- 将svn-remote网址更改回原始网址
- 运行git svn rebase -l以执行本地rebase（包含上次提取操作所带来的更改）
- 将svn-remote网址更改回新网址
- 运行git svn rebase现在应该再次运行！
这只有在git svn fetch步骤实际取任何东西时才有效！ （花了一些时间才发现......我不得不对我们的svn存储库进行虚拟修改以实现它！）
我刚刚做了这个，并且能够在大约3个小时内将4.7G 12000版本的svn repo克隆到git。
答案 4 :(得分：1)
我认为你走在正确的轨道上
本地文件访问可以为您提供1到2个订单加速。
不确定对bdb或基于文件的svn后端运行git svn会更快。
答案 5 :(得分：1)
我之前使用git-svn下载了接近100,000版本的SVN存储库。它花了大约48个小时，而且不通过本地局域网。不可否认，你确实说你的存储库有很高的分支因素，而我下载的存储库没有（尽管它确实有几十个分支）
我建议你弄清楚瓶颈在哪里。 git-svn及其子进程是否使用100％CPU？客户端或SVN服务器上的磁盘指示灯是否一直亮着？使用了多少带宽？一旦你知道限制因素是什么，你就可以找出解决方法。
答案 6 :(得分：1)
我有8k +评论和大约240个标签的回购。我试图运行并估计我在Windows上的初始git svn克隆需要几个月，只需要做
git svn clone --stdlayout --no-metadata --authors-file=users.txt https://link.to.repo
克隆是用了5秒钟平均导入1个修订版。 请注意，无论何时遇到标记，克隆都会从rev 1重新启动，因此可能会有8k * 240次操作= 111天
我为加快这一过程而采取的所有步骤摘要：
linux和osx实现比windows上的cygwin快得多。我使用的是linux虚拟机。请查看https://stackoverflow.com/a/21599759/1448276
我使用svnrdump将整个svn repo复制到我的机器
svnrdump dump https://link.to.repo > repos.dump
我创建了一个本地的svn repo
svnadmin create svnrepo
svnadmin load svnrepo < repos.dump
，如https://stackoverflow.com/a/10407464/1448276
我创建并安装了一个基于ram的磁盘
svnadmin hotcopy svnrepo/ /dev/shm/svnrepo
如上所述，https://stackoverflow.com/a/39030862/1448276
最后运行了克隆
git svn clone --stdlayout --no-metadata --prefix=origin/ --authors-file=users.txt file:///dev/shm/svnrepo
这里克隆平均每秒处理12.5次修订，所以我预计这将花费不到2天。克隆完成后我会发布更新。
答案 7 :(得分：0)