Как обработать нестандартный импорт Subversion в Git

Question

У нас есть нестандартный репозиторий subversion, который мы хотели бы преобразовать в Git. Проблема в том, что я не знаю, с чего начать, чтобы убедиться, что мы храним полную историю, но не заканчиваем полным беспорядком.

Наш репозиторий имеет последние 6 лет истории для набора продуктов наших компаний и прошел многочисленные реструктуризации. Во всех случаях у нас есть базовая кодовая база платформы, а затем несколько проектов / плагинов, которые по-разному объединяются поверх базовой платформы.

Первые пару лет были структурированы как:

-- plugin1
   - trunk
   - branches
   - tags
-- pluginX
   - trunk
   - branches
   - tags
-- trunk   (core platform)
   - <various sub dirs)
-- branches  (various feature branches of the entire repository)
   - refactoring1
   - refactoringX
-- tags (various tags of customer releases of full respository)
   - customerX_1.x  
-- vendor  (vendor drops and tracking of 3rd party source deps)
   - 3rd_party_code_A
   - 3rd_party_code_X

Со временем мы добавили еще пару каталогов в корень, включая:

-- releases (replaced tags; branches for released stable versions of repos)
-- sandbox  (area for misc projects of interest; should have been new repo)

Затем мы убрали это и получили:

-- trunk
  - platform
  - plugin1
  - pluginX
-- stable  (stable release branches of trunk)
  - 1.1
  - 1.2
-- tags    (release points; marks a point on a stable branch)
  - 1.1.1
  - 1.1.2
-- vendor
-- sandbox
-- releases (copies of old releases of interest)

Так что это наша история. То, что мы хотим закончить, мы надеемся, намного чище. Прямо сейчас мы думаем о том, как выглядит база репозитория git (в основном, копия предыдущего каталога trunk).

- platform
- plugin1
- pluginX 

Branches:
  - stable/1.1
  - stable/1.2
Tags:
  - rel/1.1.1
  - rel/1.1.2

Мы хотели бы поместить песочницу и поставщика в свои собственные репозитории. (не уверен, как это сделать, но, возможно, есть способ импортировать только подмножество хранилища svn)

Что касается ветвей и тегов, мы бы хотели, чтобы код из 'stable' заканчивался как ветви, а код из 'tags' - как теги в стабильный.

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

В настоящее время мы обсуждаем, как поступить и как все правильно реструктурировать и импортировать. По крайней мере, нам нужен способ иметь полную историю платформы и кода плагина в обеих предыдущих реструктуризациях репозитория. Если возможно, мы также хотели бы получить стабильную информацию и теги из самой последней структуры хранилища.

У кого-нибудь есть рекомендации, как сделать этот импорт?

Например:

• Можно ли сохранить полную историю реструктуризации?
• Должны ли мы как-то переписать хранилище Subversion, чтобы очистить его перед импортом, и если да, то как?
• Должны ли мы импортировать полную историю, а затем реструктурировать ее в Git и как?
• Есть идеи, как сделать этот импорт чистым?

Answer 1

В зависимости от вашей ситуации, git-svn (с опцией --follow-parent по умолчанию) может сделать все как есть. Первое, что вы должны сделать, это попробовать несколько запусков git-svn, тщательно прописав опции -T, -b и -t, чтобы помочь ему со структурой каталогов.

Однако вы можете столкнуться с проблемами из-за сложной истории структуры каталогов.

Недавно я был в очень похожей ситуации, перенося код Subversion моей компании в git, где история SVN прошла реструктуризацию, очень похожую на ту, которую вы описываете. В моем случае я хотел также отделить проекты от одного хранилища Subversion до нескольких хранилищ Git (по одному на проект).

Я смог выбрать более легкий путь, решив, что не нужно критиковать миграцию более чем нескольких месяцев истории, поэтому для каждого проекта я определил, какой самый ранний пересмотр должен был выполнить git-svn, и затем только загружал историю, начинающуюся оттуда (используя git-svn -r). Обрабатывая предыдущие миграции VCS (VSS в SVN, 2005), я по своему опыту знал, что долгая история почти никогда не упоминается. В любом случае старый сервер Subversion легко оставить работающим (в режиме только для чтения), чтобы его можно было при необходимости искать.

Я не знаю ни одного простого способа очистить историю Subversion , кроме использования svndumpfilter для исключения определенных его частей. Однако, если вам повезет, git-svn волшебным образом поступит правильно, и история в git log будет выглядеть чище, чем когда-либо в svn log (из-за разницы в том, как git смотрит на ветви и теги) .

В целом, чистота и полнота истории - две конфликтующие цели при выполнении миграции такого рода. К счастью, они оба переоценены - они оба обращаются к нашему чувству эстетики больше, чем к прагматическим потребностям.

РЕДАКТИРОВАТЬ: боковой совет для чистоты: используйте параметр --prefix на git-svn, чтобы присвоить импортированным ветвям уникальный префикс, поскольку вполне вероятно, что у вас будут разные соглашения о ветвлении в git, и это упрощает просмотрите историю SVN позже.