我正在尝试将SVN repo转换为多个git repos。到目前为止，我一直在为SVN中的每个项目使用git svn clone svn_repo_project_path。我注意到git似乎没有遵循svn复制操作，因此生成的历史比我预期的要简单得多。假设我的SVN回购看起来像这样：
根
项目b和c最近在parent-proj下复制，作为重组工作的一部分，目的是最终将其从根目录下的旧位置删除。当我执行git svn clone http://svnhost/parent-proj时，生成的git repo会丢失在移动之前来自/b和/c的所有历史记录。
这是git-svn的限制还是有某种方法让这个历史记录显示在我的回购中？从我有限的研究看来，使用Getting complete history of an SVN repo that's been renamed using git-svn中描述的filter-branch命令似乎可行，尽管在我的情况下有多个父母可能使事情复杂化。可以首先克隆整个仓库，然后从中拆分新的仓库（使用filter-branch？）是一种更好的方法吗？
答案 0 :(得分：0)
如果b，您将无法获得c或git svn clone http://svnhost/parent-proj的预复制到父级项目历史记录。 git svn将您提供的基本路径解释为您对提取SVN提交感兴趣的最浅点，使Git提交相同的提交。由于b和c下的历史提交不在此路径中，git svn无法反映它们，因此您无法获得该历史记录。
查看git svn init --no-minimize-url选项的文档：
当跟踪多个目录（使用--stdlayout， - blank或--tags选项）时，git svn将尝试连接到Subversion存储库的根目录（或允许的最高级别）。如果整个项目在存储库中移动，则此默认设置允许更好地跟踪历史记录，但可能会导致读取访问限制到位的存储库出现问题。传递--no-minimize-url将允许git svn按原样接受URL，而不尝试连接到更高级别的目录。默认情况下，当只跟踪一个URL /分支时，此选项处于关闭状态（这样做不太好）。
由于您的clone命令未指定多个分支（可能是因为您有复杂的多项目或非标准布局），git svn只是克隆涉及该路径和向下的提交。注释中的Shadow Creeper使用了-s或--stdlayout选项，这可以解释为什么会为它们保留一些历史记录。
如果这是一次性转换（从SVN到Git的单向转换），那么你应该克隆整个存储库，然后你有很好的选择在Git中移动东西看你想要它们的方式，包括建立历史分支和标签。如果运行filter-branch的动机是保存存储库空间，请确保这实际上可以为您节省一些东西，并且值得一试。 Git在存储方面非常高效。
关于Git克隆中历史搜索的最后一个警告。使用git log -C --follow <file-path>在文件上查找历史记录，Git通常会很好地定位并为您提供包含重命名和副本的历史记录。不要期望目录相同，例如parent-proj/b。 Git跟踪blob（文件），树（blob），提交和父提交，但不像SVN一样处理目录或目录副本。