加快最初的git-svn获取
我有一个很大的存储库，100,000多个修订版本，具有很高的分支因子。 使用git-svn初始获取完整的SVN仓库已经运行了大约2个月，直到修订版本60,000。 有什么办法可以加速这件事吗？
我已经经常杀死并重新启动取回，因为git-svn泄漏内存就像一个筛子。 传输发生在本地局域网上，所以链路速度不应该成为问题。 该存储库位于专用光纤通道arrays的专用机器上，所以服务器应该有很多的优点。 我唯一能想到的其他事情就是从SVN存储库的本地副本中进行克隆。
其他人在类似情况下做了什么？
在工作中，我使用git-svn来对付〜170000版本的SVN回购。 我所做的就是使用git-svn init + git-svn fetch -r...将我的初始获取限制在合理数量的修订版本中。 您必须小心select实际在您想要的分支中的修订。 即使是截断的历史， 除了 git-blame ，所有的function都是完全正常的，这显然会把所有比你的开始rev更早的行归入第一个rev。
你可以用忽略path进一步加速，删除你不想要的子树。
您可以稍后添加更多版本，但这将是痛苦的。 你将不得不重置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选项没有这个function，你也可以在原始的克隆完成之前添加它！
显然没有好的答案。 一些工作正在进行git-fast-import，但尚未准备好黄金时段。 他们仍然试图找出如何检测和表示'svn cp'行动。 其中一个亮点就是名单上的某个人对git-svn进行了优化，似乎已经产生了很大的影响。
http://permalink.gmane.org/gmane.comp.version-control.git/168718
在一个有20k提交的仓库中，我有类似的问题。 在我的情况下，事实certificate，在颠覆中有一些奇怪的标签，造成了问题。 有标签复制/而不是/ trunk。 这导致git svn进入无限循环。 我通过大块转换来修复它。
git svn fetch -r0:1000 git svn fetch -r0:2000 git svn fetch -r0:3000
观察输出，如果你没有看到新的r …偶尔有一些错误。 使用git log --all查看转换得到了多less。 假设你到了1565年，然后继续这样的取回。
git svn fetch -r1567:2000
这是非常繁琐的，但它完成了工作。
如果您可以find具有足够RAM的服务器，请在虚拟磁盘上执行整个克隆操作。 在Linux系统上，您可以使用由RAM支持的/ dev / shm。
> 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 repo，而不是像这里所描述的那样： https ： //git.wiki.kernel.org/index.php/GitSvnSwitch
- 编辑.git / config中的svn-remote url URL指向新的域名
- 运行git svn fetch – 这需要从svn获取至less一个新版本！
- 将svn-remote url更改回原始url
- 运行git svn rebase -l来执行本地rebase（使用最后一次fetch操作时所做的更改）
- 将svn-remote url更改回新的url
- 运行git svn rebase现在应该再次工作！
这只会工作，如果git svn获取步骤实际上获取任何东西！ （花了我一段时间才发现…我不得不把一个虚拟修改版本放到我们的svn仓库中来实现它！）
我只是做了这个，并能够克隆4.7G 12000版本svn回购混合约3个小时。
我认为你是在正确的轨道上
本地文件访问可以给你1到2的订单加速。
不知道如果对bdb或基于svn后端文件运行git svn会更快。
我以前使用git-svn下载了一个接近100,000的SVN版本库。 它花了大约48小时，并没有通过本地局域网。 无可否认，你确实说过你的仓库有很高的分支因子，而我下载的仓库没有（尽pipe它有几十个分支）
我会build议找出瓶颈在哪里。 git-svn和它的subprocess使用100％CPU吗？ 客户端或SVN服务器上的光盘灯是否一直点亮？ 正在使用多less带宽？ 一旦你知道限制因素是什么，你可以研究如何解决这个问题。
2017年调用英寸我正在迁移一个45K修订版回购，我发现在Linux上git-svn的工作速度比git-svn快了我的窗口框。 Vm与我的svn repo在同一个HyperV上，所以可以这样做。
我有一个8K +评论和大约240个标签回购。 我试图运行，估计我在Windows上的初始git svn克隆需要几个月，干脆就这样做了
git svn clone --stdlayout --no-metadata --authors-file=users.txt https://link.to.repo
克隆人平均需要5秒才能input1次修正。 请注意，无论何时遇到标签，克隆都将从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
-
我创build了一个本地的SVN回购
svnadmin create svnreposvnadmin load svnrepo < repos.dump
如https://stackoverflow.com/a/10407464/1448276中所述;
-
我创build并安装了基于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天。 一旦克隆完成，我将发布更新。
