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

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

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

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

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 и copy структура была немного улучшена.

svn |_mainProject |_trunk |_branches |_tags

Итак, теперь у нас есть такие пути, как

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

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

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

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