我有一个大型的活动SVN存储库（超过40GB，超过35,000个修订版）。它具有非标准布局，有数千个分支，并定期积累新的分支。
我有一个辅助git存储库，我试图与SVN存储库保持同步。 git存储库仅用于维护来自SVN的修订历史记录的真实副本。 git存储库永远不会交互使用，也不会累积从SVN存储库中保存的内容。
很明显，反复调用“ git svn fetch”将最终完成我想要的操作。但是-尽管“ git svn fetch”不会从SVN重新创建任何东西-git已经存在-在内部，“ git svn fetch”需要很长的时间才能确定已完成的工作和退出的地方。
我一直在观看.git / svn / .metadata-我看到“ git svn fetch”在SVN修订的整个历史中都可以正常工作，以便弄清它的终止位置。对于像我这样的大型存储库，“ git svn fetch”要花很多小时才能返回到停止获取的位置-之后，它将恢复将内容从SVN引入git repo的过程。
当我尝试找出更快的方法来用SVN中的新内容更新git repo时-有时我会看到一些引用，建议使用“ git svn rebase”。但是-如果“ git svn rebase”做了我想我需要的操作-“ git svn fetch”命令将是多余的（也许在选择了初始SVN修订版之后？）。使用“ rebase”也似乎是在git工作状态的上下文中。
对于“ git svn fetch”和“ git svn rebase”的相对功能，我必须在某些重要方面犯了错误。这些操作有何不同？
答案 0 :(得分：1)
我仍然不知道提取与重新设置有何不同。但是-促使我前进的是，需要在合理的时间内将SVN逐步更新为git（无需重新访问历史上的所有SVN修订版-直到git repo中尚未提供的版本）。
似乎可以使用“ git svn fetch”完成此操作-但您需要添加“ --revision START：END”。其中START是添加到git repo中的最新SVN版本，而END是SVN中的最新版本。在我看来，这很好奇-因为“ git svn fetch”的文档没有报告“ --revision”作为选项。
据报道也很重要-使用“ --log-window = N”。其中N是大约10000或20000的值。
性能仍然令人失望-但似乎更有希望。