我的问题看起来与其他人相似（特别是Cloning a Non-Standard Svn Repository with Git-Svn），但我还有一个问题。我也知道http://john.albin.net/git/git-svn-migrate。
在svn存储库中创建的一些分支遗漏了主干中的顶级目录。所以在分支中，所有文件看起来都与主干中的文件不同，仅仅因为它们位于不同的位置。
示例：在其中一个分支中，目录trunk/top/src对应branches/foo/bar/src而不是更常见的branches/foo/bar/top/src。但也有分支使用第二种形式。
现在，当在这个svn存储库上运行git svn clone时，它将重新跟踪这些分支的完整历史记录并将所有提交加倍。在中继上，提交将用于文件top/src/file，在分支上将用于src/file。因为git svn fetch操作显然不够聪明，无法检测到此重定位，所以它将在创建分支之前返回完整的历史记录，并为新位置创建新的提交，一直返回到开头时间，只是为了它可以创建进入分支的文件。
由于有很多分支，而后者有很多历史，这是令人讨厌的情况，因为每次提交都加倍或三倍（虽然从粗略检查看来，每个文件的“备用”位置是为某些但不是所有分支的历史记录共享的，它将在以后发生。）它确实增加了转换时间。
现在我一直在考虑解决的问题如下。如果有可能在git svn fetch（它是一个Perl脚本）的代码中插入一些钩子，它会在从svn获取文件之后编辑所涉及文件的路径，但在将它们提交给git之前。如果文件的路径名不包含top目录，它将插入它，否则它将保留名称。这样我就可以有效地重写历史。
现在想到以下问题：
除此之外，我将从一个非空的目标存储库开始并跳过svn历史的第一部分。这是因为开始是从cvs转换而来的，那时它的标签是以一种相当奇怪和无用的方式转换的，我已经创建了一个脚本来从头开始重新执行该部分。
（仍在寻找答案......）