Git svn clone: 错误格式错误后是否可以恢复 XML: 没有找到元素?
Git svn clone: Is it possible to resume after error Malformed XML: no element found?
我正在尝试使用 git svn
和以下命令进行从颠覆到 Git 的单向迁移大型颠覆存储库(仅在迁移后重要 Git将被使用):
git svn clone --no-minimize-url --trunk=/trunk/GBI --branches=/branches/GBI --tags=/tags/GBI --authors-file=authors.txt https://yyy/svn-repos/zzz/ GBI
几个小时后 运行,克隆进程崩溃并出现以下错误:
r79791 = 00349b8063f90447ea8a040751cd2a40e74b74f3 (refs/remotes/origin/trunk)
Error from SVN, (175009): Malformed network data: The XML response contains invalid XML: Malformed XML: no element found
然后我想也许有一个聪明的方法可以在有问题的修订之后立即恢复进程......这可能吗?
首先知道导致此错误的原因吗?
建议首先使用 --log-window-size
来防止此问题发生……我可以添加该选项并从失败的修订版重试吗?那么这个问题是 git svn
内存使用问题还是仅与损坏的颠覆版本有关的问题?
是否有 git svn option 来强化流程以忽略错误,而不只是因为这个错误而停止冗长的流程?
更新:我在 Atlassian Stash Migrating to Git guide 之后到达了这一点,这表明使用 git svn
及其 svn-migration-scripts.jar
实现
git-svn
不是 一次性转换存储库或存储库部分的正确工具。如果您想使用 Git 作为现有 SVN 服务器的前端,这是一个很好的工具,但是对于一次性转换,您应该 而不是 使用 git-svn
,但是svn2git
更适合这个用例。
有很多名为 svn2git
的工具,最好的可能是来自 https://github.com/svn-all-fast-export/svn2git 的 KDE。我强烈建议使用 svn2git
工具。这是我所知道的最好的,而且你可以非常灵活地使用它的规则文件。
如果您不是 100% 了解存储库的历史,http://blog.hartwork.org/?p=763 中的 svneverever
是一个很好的工具,可以在将 SVN 存储库迁移到 Git 时调查其历史.
尽管 git-svn 更容易上手,但除了它的灵活性之外,这里还有一些为什么使用 KDE svn2git
而不是 git-svn
更优越的原因:
svn2git
(如果使用了正确的),历史重建得更好更干净,对于具有分支和合并等的更复杂的历史尤其如此
- 标签是真正的标签,而不是 Git
中的分支
- with
git-svn
标签包含一个额外的空提交,这也使它们不属于分支,因此正常的 fetch
将不会得到它们,直到您将 --tags
给命令,因为默认情况下也只获取指向已获取分支的标签。使用正确的 svn2git 标签是它们所属的地方
- 如果您更改了 SVN 中的布局,您可以使用
svn2git
轻松配置它,使用 git-svn
您最终将丢失历史记录
- 使用
svn2git
您还可以轻松地将一个 SVN 存储库拆分为多个 Git 存储库
- 或将同一个 SVN 根中的多个 SVN 存储库轻松合并为一个 Git 存储库
- 正确
svn2git
的转换速度比 git-svn
快无数倍
git-svn
更差而 KDE svn2git
更优越的原因有很多。 :-)
我最近
Error from SVN, (175009): Malformed network data: The XML response contains invalid XML: Malformed XML: unclosed token
几乎相同并在 git 克隆创建的存储库文件夹中执行 git svn fetch
,正如 在评论中提到的那样,确实在发生错误的修订版继续运行 直到最后一次 SVN 修订。
我正在尝试使用 git svn
和以下命令进行从颠覆到 Git 的单向迁移大型颠覆存储库(仅在迁移后重要 Git将被使用):
git svn clone --no-minimize-url --trunk=/trunk/GBI --branches=/branches/GBI --tags=/tags/GBI --authors-file=authors.txt https://yyy/svn-repos/zzz/ GBI
几个小时后 运行,克隆进程崩溃并出现以下错误:
r79791 = 00349b8063f90447ea8a040751cd2a40e74b74f3 (refs/remotes/origin/trunk)
Error from SVN, (175009): Malformed network data: The XML response contains invalid XML: Malformed XML: no element found
然后我想也许有一个聪明的方法可以在有问题的修订之后立即恢复进程......这可能吗?
首先知道导致此错误的原因吗?
--log-window-size
来防止此问题发生……我可以添加该选项并从失败的修订版重试吗?那么这个问题是 git svn
内存使用问题还是仅与损坏的颠覆版本有关的问题?
是否有 git svn option 来强化流程以忽略错误,而不只是因为这个错误而停止冗长的流程?
更新:我在 Atlassian Stash Migrating to Git guide 之后到达了这一点,这表明使用 git svn
及其 svn-migration-scripts.jar
实现
git-svn
不是 一次性转换存储库或存储库部分的正确工具。如果您想使用 Git 作为现有 SVN 服务器的前端,这是一个很好的工具,但是对于一次性转换,您应该 而不是 使用 git-svn
,但是svn2git
更适合这个用例。
有很多名为 svn2git
的工具,最好的可能是来自 https://github.com/svn-all-fast-export/svn2git 的 KDE。我强烈建议使用 svn2git
工具。这是我所知道的最好的,而且你可以非常灵活地使用它的规则文件。
如果您不是 100% 了解存储库的历史,http://blog.hartwork.org/?p=763 中的 svneverever
是一个很好的工具,可以在将 SVN 存储库迁移到 Git 时调查其历史.
尽管 git-svn 更容易上手,但除了它的灵活性之外,这里还有一些为什么使用 KDE svn2git
而不是 git-svn
更优越的原因:
svn2git
(如果使用了正确的),历史重建得更好更干净,对于具有分支和合并等的更复杂的历史尤其如此- 标签是真正的标签,而不是 Git 中的分支
- with
git-svn
标签包含一个额外的空提交,这也使它们不属于分支,因此正常的fetch
将不会得到它们,直到您将--tags
给命令,因为默认情况下也只获取指向已获取分支的标签。使用正确的 svn2git 标签是它们所属的地方 - 如果您更改了 SVN 中的布局,您可以使用
svn2git
轻松配置它,使用git-svn
您最终将丢失历史记录 - 使用
svn2git
您还可以轻松地将一个 SVN 存储库拆分为多个 Git 存储库 - 或将同一个 SVN 根中的多个 SVN 存储库轻松合并为一个 Git 存储库
- 正确
svn2git
的转换速度比git-svn
快无数倍
git-svn
更差而 KDE svn2git
更优越的原因有很多。 :-)
我最近
Error from SVN, (175009): Malformed network data: The XML response contains invalid XML: Malformed XML: unclosed token
几乎相同并在 git 克隆创建的存储库文件夹中执行 git svn fetch
,正如