迁移带有移动和重定位提交的 git svn 提交答案

【问题标题】：Migrating git svn commits with moved and relocated commits迁移带有移动和重定位提交的 git svn 提交
【发布时间】：2014-04-29 20:30:49
【问题描述】：

我们正在尝试将我们的主要源代码库从 svn 迁移到 git 我的第一次尝试是简单地做一个 git svn clone。克隆完成后，我发现第一次提交是在 2012 年 11 月。我知道代码已经有几年历史了检查 svn 存储库，看起来对主目录的第一次提交发生在 2012 年 11 月，而存储库中的几个文件在此之前已经提交了几年。那么如何在父目录之前提交目录中的文件..

由于我是公司的新人，我四处询问，没有人确切知道，但是这个 repo 经历了几次 svn relocate 和 svn move 以一种不寻常的方式，例如他们发展成一个分支然后移动那个分支作为主干内的目录，或者发展成一个分支，然后将该分支重命名为主干等等。

我选择了一个 2012 年 11 月之前发生的旧提交，可以使用 git log 查询并尝试

svn up -r 599 http://myrepo/trunk

并收到错误：

svn: E195012: Unable to find repository location for 'http://myrepo/trunk' in revision 559

此错误对于 2012 年 11 月之前的所有提交都是可重现的，即可以使用 svn log 查询但无法签出的提交

好消息是我能够做到：

svn diff -r 599 http://myrepo/trunk

我的下一个方法是使用 svn diff 遍历所有提交，创建补丁并使用原始作者、日期等将它们应用到 git...

有更好的方法来提取这些损坏的提交吗？

我没有对 repo 的物理访问权限，也无法使用 svnadmin

编辑 1：

原来我不是在查询根目录，而是在树的下一层，这就是我收到此类错误的原因。无论如何，我做了一个 svnrdump 并成功转储了整个存储库（> 32K 提交），而且该存储库包含我不得不跳过的损坏提交。

此外，它已在本地导入。这有助于我进一步了解发生了什么

基本上，repo 曾经有一个非常混乱的结构，类似于

svn 
   |_Project1 
         |_subproject1 
               |_branches 
                      |_branch1 
                      |_branch2 
               |_trunk 
               |_tags 
                      |_tagv1 
   |_Non-JavaProject 
         |_subproject 
   |_Project2 
          |_AnotherSubproject 
               |_SubSubproject 
          |_Subproject2 
               |_branches 
               |_tags 
          |_Subproject3 
               |_trunk 
          |_Subproject4 
               |_Subsubproject 
                       |_branches 
                       |_tags 
                       |_trunk

后来发生的事情是，使用svn mv和copy的混合，结构被细化了一点

svn |_main项目 |_主干 |_分支机构 |_标签

所以现在我们有了类似的路径

mainProject/trunk/_Project1
mainProject/trunk/_Project1/subproject1
mainProject/trunk/Project2/AnotherSubproject/SubSubproject

分支/标签也是如此

换句话说，我需要在 .git/config 的 fetch 和其他头文件中定义一个方法，以便 mainProject 中的不同目录将遵循不同的（多个）旧路径

这可能吗？

【问题讨论】：

听起来你正试图用一只手绑在背后来诊断这个问题。如果您无法访问 actual Subversion 存储库，请查看是否可以获得它的副本以在本地使用。至少，svnadmin dump 输出的副本可能会有所帮助。但是，如果源存储库以某种方式损坏，那么转储也会损坏。
svn up http://myrepo/trunk@599 适合您吗？有关 PEG 修订的详细信息，请参阅 durak.org/sean/pubs/software/…，这可能会有所帮助。
我不相信 svn up 接受 URL。您只能在工作目录上使用它。
感谢您的快速 cmets。我现在在本地尝试 svnsync，然后执行 svndump。希望我可以通过 svndump 解决问题和/或手动修复它，然后再将转储作为 repo 再次导入并尝试另一个 git svn clone
我现在有整个存储库在我的磁盘上，并试图以 git 知道 svn move/copy 的方式将其克隆到 git 中

标签： git svn git-svn

【解决方案1】：

在 SVN 分支中，包括主干本质上只是存储库中的目录。找出文件在 r599 之前的位置的一种方法是在详细模式下在 SVN 存储库的根目录上运行 log。 IE。 svn log -v http://myrepo/@599 它将向您显示所有提交和 他们在 r599 之前在该存储库中触及的路径，包括提交到分支、重命名等。其中之一就是提交移动目录。这将帮助您了解提交之前文件的位置，并且您可以从旧位置签出以前的修订版。

【讨论】：