【问题标题】:SVN to Git using a fast import/export stream使用快速导入/导出流的 SVN 到 Git
【发布时间】:2018-07-10 20:47:02
【问题描述】:

我一直致力于将约 32,000 次提交的 SVN 存储库转换为任何 DVCS(Git、Bazaar、Mercurial、Plastic SCM)。一两周后,我意识到最好的选择是将 SVN 存储库转换为 Git,获取快速导出流,然后将 .fe 流导入任何 DVCS,因为它们都支持 git 快速导出/导入方法。

我已经尝试了互联网上的所有内容:Windows 7 和 Linux Ubuntu。由于 repo 的大小,我使用 reposurgeon 和 git-svn 取得了最大的成功。但是同样,由于大小的原因,这两种工具都无法一次性隐藏完整的 repo。我也尝试过 SubGit,虽然它可以工作,但它非常慢(处理 1060 次提交大约需要 24 小时)。

所以我想我可以分别转换 repo 中的每个文件夹(主干、分支、标签、自定义文件夹),然后在 Git 中组合。然后我意识到这是不可能的,因为 git 的 repo 结构与 SVN 有很大不同。

我的问题是,是否可以使用我上面的方法并通过一些魔法将单独的转换合并到一个 Git 存储库中?

基本上我需要为我的 SVN 存储库获得一个快速的导出/导入流,以将其转换为另一个 DVCS,并且认为 Git 中间步骤是最简单的。如果有的话,还有哪些其他选项可用于成功转换?

提前致谢。

【问题讨论】:

  • 您真的需要所有这些 32000 次提交来维护您的软件的当前版本吗?切断每一个超过一年的提交可能有助于减少需要处理的数据量,而不会真正丢失任何相关数据。通常你并不关心两年前谁提交了那组有错误的行——你关心的是“那些行真的很老而且有问题,让我们修复和重构吧”。
  • 干杯@Sven。我同意你的看法;所有 32000 次提交都不是必需的,但越多越好,因为我们希望可能完全离开 SVN。仍然考虑到这一点,我该怎么做才能真正成功转换?有哪些选择?

标签: git svn git-svn reposurgeon


【解决方案1】:

单独转换文件夹并合并 git 存储库原则上应该可以工作,但要正确处理会非常棘手,所以我建议不要 它。

无论如何,32,000 次提交并不多,git-svn 应该可以 处理它,虽然它可能需要一天左右的时间。 但是,如果速度太慢,您将不得不进行一些实验。

可能会减慢 git-svn 的克隆操作的事情

SVN 存储库速度

首先,当然是 SVN 存储库的速度。尝试创建 SVN 存储库的本地镜像(使用 svnadmin dump/loadsvnsync),然后克隆它。

“子目录”分支/标签

分支或标签(git 对待它们的方式相同)可能会成为问题。每当git-svn clone 遇到一个SVN 分支,它不是 主干的副本,而是一个子目录的副本,它会重新读取分支子目录自创建以来的整个SVN 历史记录(您可以在git svn clonehere is an explanation by the author 的输出中看到这一点)。这意味着克隆的速度不仅与SVN修订的数量n成正比,还与“子目录分支”的数量b成正比,即如果b = 10,则克隆最多可能需要10次更长。

这个问题没有简单的解决方案。首先,您可以尝试不带标签的克隆 - 通常标签只是恢复为 SVN 修订 ID,因此拥有标签列表就足够了(除非您有包含更改的标签......呃)。如果这还不够,也许还可以跳过一些分支......不过你必须决定是否有任何你可以不用的。

极端的解决方案是使用选项--no-follow-parent。这将防止git svn 从头开始​​重新读取分支。仍然会读取分支,但是,它们不会连接到历史的其余部分。这仍然向您展示了那里所做的事情,但使它们很难合并回来。


最后,请注意您可以中断和恢复克隆过程。要恢复,请运行 git svn fetch。 您可能需要重新启动几次,但请耐心等待克隆完成。

【讨论】:

  • 顺便说一句:这里还讨论了多次获取修订:stackoverflow.com/questions/1140428/…
  • 非常感谢。我正在使用 repo 的本地副本。很快意识到直接脱网转换会很傻。这也解释了为什么我会在转换过程中看到转数跳来跳去。也许有几个子目录分支。多年来,大约有 30 位开发人员参与了这个项目,因此很难判断标签是否只是标签,或者分支是否仅来自主干,但我会记住这一点,以及 --no-跟随父母选项是最后手段的需要。
  • 使用 svnadmin dump/load 使用 svn repo 的本地副本基本固定速度。
  • 关于从 SVN 存储库的镜像克隆的建议 - 我认为它不会起作用,因为 git svn fetch 将存储库 URL 保存为提交哈希的一部分,它需要 @ 987654335@ 查看所有提交,以便在从镜像导入后切换到使用原始提交。
  • @DanielHershcovich:这个问题是关于“转换”的,所以我认为 SVN 存储库将被淘汰。如果您想继续并行使用 SVN 和 Git,那么是的,您需要在克隆后将 SVN URL 切换为真实 URL。有一些方法可以在不重写所有提交的情况下做到这一点......但这是一个单独的问题:-)。
【解决方案2】:

复活一个非常古老的问题,但我认为答案可能对某人有用。

您可能想试试svn-all-fast-export / svn2git。几年前,我将一个大约 35k 提交的旧 SVN 存储库转换为 Git,同时将其拆分为几个单独的 Git 存储库。我的笔记本电脑上有 SVN 存储库的本地副本,只花了大约 15 分钟(这很棒,因为我必须多次运行转换才能对结果感到相当满意;)。我还使用BFG Repo-Cleaner 对转换后的 Git 存储库进行后处理。

svn-all-fast-export / svn2git 不是最直接的软件,我不得不阅读源代码几次才能真正理解发生了什么。您可能想查看我关于此主题的其他答案以获取一些提示:svn-all-fast-export: Match file names

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 2016-06-14
    • 1970-01-01
    • 1970-01-01
    • 2014-01-10
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多