Миграция git svn фиксирует с перемещенными и перемещенными коммитами

Question

Мы пытаемся перенести наш основной исходный репозиторий из svn в git. Моя первая попытка была просто сделать клон git svn. После того, как клонирование было завершено, я обнаружил, что первый коммит произошел в ноябре 2012 года. Я точно знаю, что коду уже пару лет. Изучая репозиторий svn, похоже, что первый коммит в основной каталог произошел в ноябре 2012 года, а несколько файлов в репо были переданы за много лет до этого. Так, как файлы в каталоге могут быть переданы перед родительским каталогом..

Я спрашивал вокруг, так как я новичок в компании, и никто не знает наверняка, но в этом репо произошло несколько перемещений svn и svn необычным образом, например, они превратились в филиал, а затем переместили этот филиал как каталог внутри транка, или превращенный в ветку, затем переименованный в эту ветку как транк и так далее.

Я выбрал один из тех старых коммитов, которые произошли до ноября 2012 года и могут быть запрошены с помощью git log, и попытался

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

и получил ошибку:

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

Эта ошибка воспроизводима для всех коммитов до ноября 2012 года, то есть тех, которые могут быть запрошены с помощью журнала SVN, но не могут быть извлечены

Хорошей новостью является то, что я могу сделать что-то вроде:

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

Мой следующий подход - запускать все коммиты с использованием svn diff, создавать патчи и применять их к git с использованием оригинального автора, даты и т. Д.

Есть лучшие идеи, как извлечь такие испорченные коммиты?

У меня нет физического доступа к репо, и я не могу использовать svnadmin

Изменить 1:

Оказалось, что я не запрашивал корневой каталог, а на один уровень ниже по дереву, поэтому я получал такие ошибки. В любом случае я сделал svnrdump и преуспел в создании дампа всего хранилища (> 32K коммитов), также репо содержало поврежденные коммиты, которые мне пришлось пропустить.

В дальнейшем он был импортирован на месте. Это помогло мне понять, что произошло

По сути, репо имел очень хаотическую структуру, что-то вроде

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 и копирования, структура была немного усовершенствована

svn |_mainProject |_trunk |_branches |_tags

Так что теперь у нас есть пути, как

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

и то же самое касается веток / тегов

Другими словами, мне нужно определить в.git/config в fetch и других заголовках метод, чтобы разные каталоги из mainProject следовали разным (множественным) старым путям.

Это возможно?

Answer 1

В ветвях SVN, включая транки, по сути, это просто каталоги в репозитории. Один из способов выяснить, где были ваши файлы до r599, - запустить журнал в корне репозитория SVN в подробном режиме. Т.е. svn log -v http://myrepo/@599 Он покажет вам все коммиты и пути, к которым они обращались до r599 в этом хранилище, включая коммиты для веток, переименования и т. Д. Одним из них будет коммит, который перемещал каталоги. Это поможет вам, где файлы были до этого коммита, и вы можете извлечь предыдущую ревизию из ее старого местоположения.