перенос svn на git: несоответствие контрольной суммы в объединенном файле

Я пытаюсь вручную перенести репозиторий SNV в Git и столкнулся с проблемой:

Я инициализировал свою (нечетную) структуру веток/стволов/тегов с помощью git svn init..., а затем попытался получить файлы, сохраняя при этом историю и журналы. Но git svn fetch терпит неудачу, когда достигает ревизии, включая слияние между ветвями svn, из-за ошибки несоответствия контрольной суммы.

Я уже пробовал разные решения, представленные на SO, но большинство из них связаны с существующим репозиторием Git, которого у меня нет (пока), поэтому, например. git svn log не будет работать, потому что версия HEAD еще не получена. Ничего не получилось...

Я предполагаю, что файл был объединен и изменен с помощью одной фиксации. Есть ли способ обойти проверку контрольной суммы? Или другое решение?


person ThePMO    schedule 02.08.2017    source источник


Ответы (1)


Изменение файлов во время слияния — довольно обычный вариант использования, так как вам нужно объединить две разные кодовые базы, что может потребовать некоторых вещей, сделанных по-разному, поэтому я не думаю, что это проблема сама по себе.

Но в любом случае для однократной миграции git-svn не является подходящим инструментом для преобразования репозиториев или частей репозиториев. Это отличный инструмент, если вы хотите использовать Git в качестве внешнего интерфейса для существующего сервера SVN, но для разовых преобразований вы должны не использовать git-svn, а svn2git, который гораздо больше подходит для этого варианта использования. .

Существует множество инструментов под названием svn2git, вероятно, лучший из них — это KDE с https://github.com/svn-all-fast-export/svn2git. Я настоятельно рекомендую использовать этот инструмент svn2git. Это лучшее из того, что я знаю, и оно очень гибкое в том, что вы можете делать с его файлами правил.

Вы сможете легко настроить файл правил svn2gits для получения желаемого результата из вашего текущего макета SVN, включая любые сложные истории, которые могут существовать, и включая создание нескольких репозиториев Git из одного репозитория SVN или объединение разных репозиториев SVN в одно репозиторий Git. .

Если вы не на 100 % знаете историю своего репозитория, svneverever с http://blog.hartwork.org/?p=763 — отличный инструмент для изучения истории репозитория SVN при его переносе в Git.


Несмотря на то, что с git-svn проще начать, вот еще несколько причин, по которым использование KDE svn2git вместо git-svn лучше, помимо его гибкости:

  • история перестраивается намного лучше и чище по svn2git (если используется правильный), особенно это касается более сложных историй с ответвлениями и слияниями и т.д.
  • теги являются реальными тегами, а не ветвями в Git
  • с git-svn теги содержат дополнительную пустую фиксацию, которая также делает их не частью ветвей, поэтому обычный fetch не получит их, пока вы не дадите --tags команде, поскольку по умолчанию также извлекаются только теги, указывающие на извлеченные ветки. С правильными тегами svn2git они там, где им место
  • если вы изменили макет в SVN, вы можете легко настроить это с помощью svn2git, с git-svn вы в конечном итоге потеряете историю
  • с помощью svn2git вы также можете легко разделить один репозиторий SVN на несколько репозиториев Git.
  • или легко объединить несколько репозиториев SVN в одном корне SVN в один репозиторий Git
  • преобразование в миллион раз быстрее с правильным svn2git, чем с git-svn

Видите ли, есть много причин, по которым git-svn хуже, а KDE svn2git лучше. :-)

person Vampire    schedule 02.08.2017