遇到这种大体积、非标准布局的SVN迁移确实头疼，结合你的场景，给你几个实用的解决思路：

一、拆分迁移单元，适配不同目录结构 #

你的SVN四个主目录结构差异太大，全局用--stdlayout肯定会出问题，不如把每个主目录下的子项目当成独立迁移单元，针对性指定布局参数：

• Archive目录：内部子项目都是标准branches/tags/trunk结构，直接对每个子项目单独执行：

  git svn clone --stdlayout <SVN子项目完整URL>
  

  完美适配标准布局，能最大程度保留分支标签历史。
• Firmware目录：子项目的核心布局在Source下，手动指定分支标签路径：

  git svn clone --trunk=Source/trunk --branches=Source/branches --tags=Source/tags <SVN子项目完整URL>
  

• Server目录：Source下的子项目各有独立布局，针对每个子项目单独指定：

  git svn clone --trunk=Source/[子项目名]/trunk --branches=Source/[子项目名]/branches <SVN子项目完整URL>
  

  没有tags的子项目可以省略--tags参数。
• Tools目录：结构最混乱，分情况处理：
  • 像/Tools/Deployer这种无分支标签的目录，直接克隆整个目录：

    git svn clone <SVN目录完整URL>
    

    Git会把所有SVN提交历史转换成Git主线提交。
  • 像/Tools/FtpTester/Source下有Trunc（注意拼写差异）的项目，手动指定trunk路径：

    git svn clone --trunk=Source/Trunc <SVN子项目完整URL>
    

二、排查git svn卡住的问题 #

22GB的SVN仓库体积不小，卡住不一定是报错，可能是后台在处理大量历史数据，你可以这么排查：

• 确认进程状态：打开任务管理器，查看git相关进程是否还在读写磁盘/占用CPU，如果是，说明迁移还在进行，只是耗时久，可以换性能更好的机器或者耐心等待（大仓库迁移几小时都很正常）。
• 开启 verbose 日志：重新执行克隆时加上--verbose参数，实时查看迁移进度，定位卡住的环节：

  git svn clone --verbose --stdlayout <SVN URL>
  

  这样能看到正在处理哪个SVN版本、哪个文件，方便判断是卡在某个大文件还是某个异常提交。
• 分批次迁移历史：如果是因为历史版本太多导致单次处理压力过大，用-r参数分批次拉取：

  # 先拉取最近1000个版本
  git svn clone --stdlayout -r HEAD:1000 <SVN URL>
  # 拉取剩余历史
  git svn fetch -r 999:1
  

• 检查SVN服务器连接：如果是远程迁移，可能是网络延迟导致卡住，尽量在SVN服务器本地执行迁移，减少网络影响。

三、迁移后整合到TFS Git集合 #

每个子项目迁移完成后，就可以推送到TFS 2018的[Product]GitCollection中：

1. 在TFS中为每个子项目创建对应的Git仓库；
2. 本地Git仓库添加TFS远程地址：

   git remote add tfs <TFS Git仓库URL>
   

3. 推送所有分支和标签到TFS：

   git push tfs --all
   git push tfs --tags
   

4. 设置该集合的权限为只读，只开放给需要查看历史的人员。

四、额外优化建议 #

• 清理历史大文件：22GB仓库大概率存在大文件（比如安装包、日志），可以用git filter-repo（替代已废弃的git filter-branch）移除历史中的大文件，减小Git仓库体积，加快迁移和克隆速度。
• 先做小范围测试：先挑一个小的子项目（比如Tools下的轻量项目）做迁移测试，验证参数正确性和历史完整性，没问题再推进大项目迁移。
• 保留原SVN服务器一段时间：迁移完成后不要立刻删除原SVN，等团队确认Git仓库的历史、文件都没问题，再逐步停用SVN，避免出现意外无法回滚。

内容的提问来源于stack exchange，提问作者Dev86