git svn fetch 反复无故失败
git svn fetch repeatedly fails for no apparent reason
背景
我们计划在 Azure DevOps 中将 SVN 单向迁移到 Git,这样我们就可以保留消息的提交历史记录。正如您可能预料的那样,我们进行了一次试验 运行,在我们想出经过 26 小时处理后最终起作用的命令列表之前,我们做了很多头发拉扯和站在其他同事的肩膀上。
这些命令是:
运行 in Git Bash 以 Git 格式从 SVN 获取所有作者的列表:
svn log -q | awk -F '|' '/^r/ {sub("^ ", "", ); sub(" $", "", ); print " = "" <"">"}' | sort -u > authors-transform.txt
运行 in Windows cmd shell 作为管理员,注意复制完成是因为经过多次尝试,这些是使用 git 忽略命令和 git lfs 跟踪命令因此保存以供重复使用。 git 配置文件也是如此,我告诉它要处理的显式 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
然后我们从 /.git/config 中删除“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 服务器压缩的 .BAK 文件,用于作为构建测试、自动集成测试等的一部分进行恢复...Azure Git repo 花了大约 11 分钟克隆。希望使用 Git LFS 可以使这些文件的影响更容易接受,但决定进行另一项测试:
- **/*.bak 已添加到 .git忽略文件
- *.bak LFS 跟踪线已从 .git 属性文件中删除
- 运行 与上面相同的一组命令,但在随机时间后,但通常在 1 到 2 小时范围内,我得到以下 3 个错误之一,这些错误出现在不同的 SVN revisions/files 显示为输出中出现之前的最后一行:
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 解决方法
用于 Git LFS 能够正确处理更大的文件,即
是以下命令:git config http.version HTTP/1.1
我在没有 运行 那个命令的情况下再次尝试,但仍然得到了其中一个
以上 2 个错误。
后续尝试我只是 运行 从上面执行 git svn fetch 命令,以防它只是一些暂时性的问题 - 不,它不是!
最近的尝试我清空文件夹重新开始,跳过了 Azure devops 行,它没有再次失败,但是只有一个小时左右。
难倒
在使用 Git 方面,我相当菜鸟。我知道它是分布式的,这与 SVN 根本不同。我只是不明白相同的命令如何在没有更详细的错误的情况下随机爆炸。 SVN repo 的唯一区别是多了 50-100 次提交
更新:08/03/2021
尝试通过 Git Bash 运行 整件事而不是仅仅一些,现在开始报告第三个错误。我在这里抓着救命稻草。我什至尝试将 log-window-size 参数从 2500 减少到 1000,然后再减少到 500。仍然没有快乐。
更新:2021 年 9 月 3 日
我们的一位系统管理员查看了 SVN 日志,它似乎被来自 2 台不同机器的同一通用用户所攻击。我联系了负责这些机器的相关人员,并让其中一台机器停止了它正在做的事情,所以理论上减少了大约 50% 的持续流量到 SVN 服务器再次尝试并得到错误 4 我添加到上面的错误列表。所以看来这不是超时问题。
我不是 100% 知道以下内容是否属实,但 git svn fetch
现在正在顺利完成或只是中途停止。
我检查了来自服务器的 SVN 日志,在发生错误的时候,SVN 日志在一天结束时的大小为 0.5GB,其中大部分不是我的 Git 迁移。我怀疑发生了某种形式的超时,令人沮丧的是 git 只是没有帮助或没有错误消息。当 git svn fetch
命令起作用时,SVN 日志在一天结束时下降到 70MB。
因此,故事的寓意似乎是检查您的 SVN 日志,因为 git 不会告诉您任何有用的信息。
背景
我们计划在 Azure DevOps 中将 SVN 单向迁移到 Git,这样我们就可以保留消息的提交历史记录。正如您可能预料的那样,我们进行了一次试验 运行,在我们想出经过 26 小时处理后最终起作用的命令列表之前,我们做了很多头发拉扯和站在其他同事的肩膀上。
这些命令是:
运行 in Git Bash 以 Git 格式从 SVN 获取所有作者的列表:
svn log -q | awk -F '|' '/^r/ {sub("^ ", "", ); sub(" $", "", ); print " = "" <"">"}' | sort -u > authors-transform.txt
运行 in Windows cmd shell 作为管理员,注意复制完成是因为经过多次尝试,这些是使用 git 忽略命令和 git lfs 跟踪命令因此保存以供重复使用。 git 配置文件也是如此,我告诉它要处理的显式 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
然后我们从 /.git/config 中删除“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 服务器压缩的 .BAK 文件,用于作为构建测试、自动集成测试等的一部分进行恢复...Azure Git repo 花了大约 11 分钟克隆。希望使用 Git LFS 可以使这些文件的影响更容易接受,但决定进行另一项测试:
- **/*.bak 已添加到 .git忽略文件
- *.bak LFS 跟踪线已从 .git 属性文件中删除
- 运行 与上面相同的一组命令,但在随机时间后,但通常在 1 到 2 小时范围内,我得到以下 3 个错误之一,这些错误出现在不同的 SVN revisions/files 显示为输出中出现之前的最后一行:
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 解决方法 用于 Git LFS 能够正确处理更大的文件,即 是以下命令:
git config http.version HTTP/1.1
我在没有 运行 那个命令的情况下再次尝试,但仍然得到了其中一个 以上 2 个错误。
后续尝试我只是 运行 从上面执行 git svn fetch 命令,以防它只是一些暂时性的问题 - 不,它不是!
最近的尝试我清空文件夹重新开始,跳过了 Azure devops 行,它没有再次失败,但是只有一个小时左右。
难倒
在使用 Git 方面,我相当菜鸟。我知道它是分布式的,这与 SVN 根本不同。我只是不明白相同的命令如何在没有更详细的错误的情况下随机爆炸。 SVN repo 的唯一区别是多了 50-100 次提交
更新:08/03/2021 尝试通过 Git Bash 运行 整件事而不是仅仅一些,现在开始报告第三个错误。我在这里抓着救命稻草。我什至尝试将 log-window-size 参数从 2500 减少到 1000,然后再减少到 500。仍然没有快乐。
更新:2021 年 9 月 3 日 我们的一位系统管理员查看了 SVN 日志,它似乎被来自 2 台不同机器的同一通用用户所攻击。我联系了负责这些机器的相关人员,并让其中一台机器停止了它正在做的事情,所以理论上减少了大约 50% 的持续流量到 SVN 服务器再次尝试并得到错误 4 我添加到上面的错误列表。所以看来这不是超时问题。
我不是 100% 知道以下内容是否属实,但 git svn fetch
现在正在顺利完成或只是中途停止。
我检查了来自服务器的 SVN 日志,在发生错误的时候,SVN 日志在一天结束时的大小为 0.5GB,其中大部分不是我的 Git 迁移。我怀疑发生了某种形式的超时,令人沮丧的是 git 只是没有帮助或没有错误消息。当 git svn fetch
命令起作用时,SVN 日志在一天结束时下降到 70MB。
因此,故事的寓意似乎是检查您的 SVN 日志,因为 git 不会告诉您任何有用的信息。