我有一个很大的存储库，有 100,000 多个修订版，分支因子非常高。使用 git-svn 对完整 SVN 存储库的初始获取已经运行了大约 2 个月，并且仅达到了 60,000 修订版。有什么办法可以加快速度吗？
由于 git-svn 像筛子一样泄漏内存，我已经定期杀死并重新启动 fetch。传输是通过本地 LAN 进行的，因此链接速度应该不是问题。存储库位于由专用光纤通道阵列支持的专用机器上，因此服务器应该有足够的功能。我能想到的唯一另一件事是从 SVN 存储库的本地副本进行克隆。
其他人在类似情况下做了什么？
【问题讨论】：
git gc 和 git svn gc 不时出现时间也可能会有所帮助。
在工作中，我使用 git-svn 来处理 ~170000 修订版 SVN 存储库。我所做的是使用git-svn init + git-svn fetch -r... 将我的初始获取限制为合理的修订数量。您必须小心选择实际上在您想要的分支中的修订。即使有截断的历史记录除了git-blame，一切都可以正常运行，这显然将所有比您的起始版本更早的行都归因于第一个版本。
您可以使用忽略路径来进一步加快这一速度，以修剪掉您不想要的子树。
您可以稍后添加更多修订，但这会很痛苦。您将不得不重置 rev-map（可悲的是，我什至写了 git-svn reset，如果它会删除 all 修订，我不能随便说，所以它可能是手动的）。然后git-svn fetch 更多修订和git-filter-branch 将您的旧根重新设置为新树。这将重写每个提交，但不会影响源 blob 本身。当人们对 svn 存储库进行大规模重组时，您必须进行类似的手术。
如果您确实需要 所有 的修订（例如用于迁移），那么您应该考虑一些 svn-fast-export + git-fast-import 的风格。可能有一个添加 rev 标记以匹配 git-svn，在这种情况下，您可以快速导入，然后只移植到 svn 远程。即使现有的 svn-fast-export 选项没有该功能，您也可以在原始克隆完成之前添加它！
【讨论】：
显然没有好的答案。一些工作正在 git-fast-import 上完成，但还没有准备好迎接黄金时段。他们仍在试图弄清楚如何检测和表示“svn cp”动作。一个亮点是名单上的某个人提出了对 git-svn 的优化，似乎产生了很大的影响。
http://permalink.gmane.org/gmane.comp.version-control.git/168718
【讨论】：
如果你能找到一个有足够 RAM 的服务器，请在 ramdisk 上执行整个克隆操作。在 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 存储库指向您真正的 svn 存储库，如下所述：https://git.wiki.kernel.org/index.php/GitSvnSwitch
- 编辑.git/config中的svn-remote url URL指向新域名
- 运行 git svn fetch - 这需要从 svn 中获取至少一个新版本！
- 将svn-remote url改回原来的url
- 运行 git svn rebase -l 进行本地 rebase（使用上次 fetch 操作中的更改）
- 将 svn-remote url 改回新的 url
- 运行 git svn rebase 现在应该可以再次运行了！
这只有在 git svn fetch 步骤实际获取任何东西时才有效！ （我花了一段时间才发现...我必须对我们的 svn 存储库进行一个虚拟修订才能实现它！）
我刚刚这样做，并且能够在大约 3 小时内将 4.7G 12000 修订版 svn 存储库克隆到 git。
【讨论】：
在一个有 20k 次提交的存储库中，我遇到了类似的问题。就我而言，结果证明 subversion 中有一些奇怪的标签会导致问题。有复制 / 而不是 /trunk 的标签。这导致 git svn fetch 进入无限循环。 我通过分块转换来修复它。
git svn fetch -r0:1000
git svn fetch -r0:2000
git svn fetch -r0:3000
观察输出，如果您没有看到新的 r... 偶尔会出现问题。
使用git log --all 查看转换的程度。假设你到了 1565。然后像这样继续获取。
git svn fetch -r1567:2000
这很乏味，但它完成了工作。
【讨论】：
-r0:1000 之一并且您根本看不到任何输出，那么它似乎已经完成了该部分。运行 git log --all 并从稍后的 SVN 提交开始。还没有完成结帐，但我希望一切顺利。 :)
我有一个包含 8k+ 评论和大约 240 个标签的仓库。我尝试运行并估计我在 windows 上最初的 git svn clone 需要几个月的时间，只是这样做
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 存储库复制到了我的机器上
svnrdump dump https://link.to.repo > repos.dump
我创建了一个本地 svn 仓库
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 天的时间。克隆完成后我会发布更新。
【讨论】：
我认为你在正确的轨道上
本地文件访问可以为您提供 1 到 2 个订单加速。
不确定针对 bdb 或基于文件的 svn 后端运行 git svn 是否会更快。
【讨论】：
我之前使用 git-svn 下载了一个接近 100,000 修订版的 SVN 存储库。它花了大约 48 小时，并且没有通过本地 LAN。诚然，您确实说过您的存储库具有很高的分支因子，而我下载的存储库没有（尽管它确实有几十个分支）
我建议努力找出瓶颈所在。 git-svn 及其子进程是否使用 100% CPU？客户端或 SVN 服务器上的磁盘灯是否常亮？使用了多少带宽？一旦您知道限制因素是什么，您就可以研究如何解决它。
【讨论】：
2017 年来电。我正在迁移一个 45k 修订版存储库，我发现 Linux 上的 git-svn 的运行速度比我的 Windows 机器上的 git-svn 快 10 倍。虚拟机 与我的 svn 存储库在同一个 HyperV 上，所以可能就是这样。
【讨论】：