没有克隆标签的 git svn 克隆



我想跳过所有标签的导入。 这是正确的语法吗?

git svn clone "http://svn/svn/IT_Udvikling" git-DataLicense --revision 37000:HEAD --trunk="/FID/DataLicense/trunk" --branches="/FID/DataLicense/branches"  --no-minimize-url --authors-file=../authors-transform.txt   

我正在尝试跳过标签的导入,因为 git svn 克隆过程需要很长时间。 它已经运行了 3 天。

加快一次性迁移git-svn的最佳方法是根本不使用git-svn。跳过标签可能不会为您节省太多时间,因为在典型的SVN存储库中,几乎没有标签独有的提交,通常每个标签只有一个。但是,是的,如果您没有直接或间接指定-t--tags(例如,通过使用-s--stdlayout,则不应获取任何标签。但正如我所说,它不会大大加快这一进程。

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

有很多工具叫做svn2git,最好的可能是来自 https://github.com/svn-all-fast-export/svn2git 的KDE。我强烈建议使用该svn2git工具。这是我所知道的最好的,它非常灵活地处理其规则文件。

您将能够轻松配置svn2git规则文件,以从当前的SVN布局中生成所需的结果,包括可能存在的任何复杂历史记录。

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


尽管git-svn更容易上手,但除了灵活性之外,以下是使用 KDEsvn2git而不是git-svn更优越的进一步原因:

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

你看,有很多原因可以解释为什么git-svn更差,而KDEsvn2git更胜一筹。

最新更新