1

我正在将我们的 SVN 迁移到 Git。我们的 Jenkins 工作需要一个特定的文件夹,在某些分支中该文件夹可能是空的。因此,我已将 --preserve-empty-dirs 参数提供给git svn clone --preserve-empty-dirs --prefix "" ....

不幸的是,这总是在相同的版本中失败,并显示以下消息:

Found possible branch point: http://<svn>/tags/2008-03-26-1000-BINDING, 656
Found branch parent: (refs/remotes/tags/2008-03-26-1000-BINDING) cc93e7405337b31d9fce7ec28ab67a9ac3af3811
Following parent with do_switch
couldn't truncate file at /usr/share/perl5/Git.pm line 1410.

如果没有 --preserve-empty-dirs 标志,我可以成功克隆它。这个问题有什么解决方法吗?

git 版本 2.11.0,svn 版本 1.9.5

4

1 回答 1

-1

因为一次性迁移git-svn不是转换存储库或存储库部分的正确工具。如果您想使用 Git 作为现有 SVN 服务器的前端,这是一个很棒的工具,但对于一次性转换,您不应该使用,但它更适合这个用例。git-svnsvn2git

有很多称为svn2git的工具,可能最好的是来自https://github.com/svn-all-fast-export/svn2git的 KDE 工具。我强烈建议使用该svn2git工具。这是我所知道的最好的,并且在你可以用它的规则文件做什么方面非常灵活。

您将能够轻松配置svn2gits 规则文件以从当前 SVN 布局中生成所需的结果,您还可以通过为其提供命令行选项来告诉它保留空目录,使其将空.gitignore文件放入目录中以保留它们.

如果您不是 100% 了解存储库的历史,那么在将 SVN 存储库迁移到 Git 时,svnevereverhttp ://blog.hartwork.org/ ?p=763是一个调查 SVN 存储库历史的好工具。


尽管git-svn更容易开始,但除了灵活性之外,还有一些使用 KDEsvn2git而不是更优越的原因:git-svn

  • 通过(如果使用正确的),历史被重建得更好,更清晰,svn2git对于具有分支和合并等的更复杂的历史尤其如此
  • 标签是真正的标签,而不是 Git 中的分支
  • 标签包含git-svn一个额外的空提交,这也使它们不是分支的一部分,因此在fetch您提供命令之前,正常情况下不会获取它们,--tags因为默认情况下也只会获取指向已获取分支的标签。使用正确的 svn2git 标签是它们所属的地方
  • 如果您更改了 SVN 中的布局,您可以轻松地配置它svn2gitgit-svn最终您将失去历史
  • 您还可以轻松地svn2git将一个 SVN 存储库拆分为多个 Git 存储库
  • 或轻松将同一个 SVN 根目录中的多个 SVN 存储库合并到一个 Git 存储库中
  • svn2git正确的转换比使用正确的要快无数倍git-svn

你看,有很多原因导致git-svnKDE 更差而 KDEsvn2git更胜一筹。:-)

于 2017-04-06T07:52:23.540 回答