背景
我们计划在Azure DevOps中将SVN单向迁移到Git，这样我们就可以保留消息的提交历史记录。正如你所料，我们进行了一次试运行，在我们提出经过26个小时处理后最终有效的命令列表之前，我们对其他同事进行了多次拉毛和站在他们的肩膀上。
这些命令是：
在Git Bash中运行，以Git格式从SVN获取所有作者的列表：
svn log -q | awk -F '|' '/^r/ {sub("^ ", "", $2); sub(" $", "", $2); print $2" = "$2" <"$2">"}' | sort -u > authors-transform.txt
以管理员身份在Windows cmd shell中运行，请注意，复制完成是因为在多次尝试后，这些命令是使用git ignore命令和git lfs track命令创建的，因此保存以供重复使用。git-config文件也是如此，我告诉它要处理的显式SVN标记：
git svn init --prefix "" --no-metadata --trunk=Trunk --branches=Branches --tags=Tags https://jeeves/svn/ResourceDirectoryPortal/
git lfs install
copy ...gitattributes
copy ...gitignore
copy ..authors-transform.txt
copy ..config ..git
git add .gitattributes
git add .gitignore
git commit -m "Preparation"
git svn fetch --log-window-size=2500 -A authors-transform.txt
在Git Bash中运行以创建Git标签：
for t in $(git for-each-ref --format='%(refname:short)' refs/remotes/tags); do git tag ${t/tags//} $t && git branch -D -r $t; done
通过批处理文件在Windows cmd中运行以下一系列命令来清除错误创建的标记，因为这样做比尝试修复并等待26小时的迁移时间更容易：
git tag -d NameOfTagHere
然后，我们移除"；SVN"；部分，然后删除/.git/svn文件夹。之后，我们以管理员身份从Windows cmd shell运行：
git remote add origin https://AzureDevops.url.here/for-empty-git-repo
git config http.version HTTP/1.1
git push origin --all
git push origin --tags
问题
因为我们在repo中有一些SQL Server压缩的.BAK文件，用于作为构建测试、自动集成测试等的一部分进行恢复…Azure Git repo克隆大约需要11分钟。希望使用Git LFS可以让这些文件的影响更容易被接受，但决定做另一个测试，通过：
- **/*.bak已添加到.gitignore文件中
- *已从.gitattributes文件中删除.bak LFS跟踪行
- 运行与上述相同的一组命令，但在随机的一段时间后，但通常在1到2小时的范围内，我会出现以下3个错误之一，不同的SVN修订/文件在输出中出现之前显示为最后一行：
ls-tree, command error 127
error closing pipe: Broken pipe at C:/Program Files/Git/mingw64/share/perl5/Git/IndexInfo.pm line 32. at /usr/lib/perl5/vendor_perl/SVN/Ra.pm line 623
rev-parse --git-path svn: command returned error: 127
config svn-remote.svn.tags-maxRev 2062: command returned error: 127
测试的理论
我认为这可能是AzureDevops的解决方案I用于Git LFS，以便能够正确处理较大的文件是以下命令：
git config http.version HTTP/1.1我在没有运行该命令的情况下再次尝试，但仍然得到了一个以上2个错误。
在随后的尝试中，我只是从上面运行gitsvn-fetch命令，以防这只是一个暂时的问题——不，不是！
最近的一次尝试我清空了文件夹，重新开始，跳过了Azure devops行，它还没有再次失败，但只有大约一个小时。
Stumped
当谈到使用Git时，我相当迟钝。我知道它是分布式的，这与SVN有根本的不同。我只是不明白，同样的命令怎么会在没有更详细错误的情况下随机爆炸。SVN回购的唯一区别是的提交次数增加了50-100次
更新：2021年3月8日尝试通过Git Bash运行整个程序，而不是仅运行一些程序，现在开始报告第三个错误。我在这儿抓救命稻草。我甚至尝试将日志窗口大小参数从2500降低到1000，然后再降低到500。仍然没有快乐。
更新：2021年3月9日我们的一名系统管理员查看了SVN日志，它似乎被来自两台不同机器的同一个普通用户锤击。我联系了负责这些机器的相关人员，让其中一台maachine停止了它正在做的事情，所以理论上减少了大约50%的SVN服务器的持续流量，再次尝试，得到了错误4，我将其添加到了上面的错误列表中。所以这似乎不是一个超时问题。
我不100%知道以下是否为真，但git svn fetch现在正在完成，没有错误，或者只是中途停止。
我检查了服务器上的SVN日志，在出现错误时，截至当天结束，SVN日志的大小为0.5GB，其中大部分不是我的Git迁移。我怀疑发生了某种形式的超时，令人沮丧的是，git只是收到了一条毫无帮助或没有错误的消息。当git svn fetch命令工作时，到当天结束时，SVN日志已降至70MB。
因此，这个故事的寓意似乎是检查你的SVN日志，因为git不会告诉你任何有用的东西。