2016-08-31 2 views
0

Я работаю над конвертированием довольно приличного SVN репо. Это ~ 50 проектов, которые составляют ~ 5 различных поставляемых продуктов (некоторые проекты разделяются между всеми продуктами, другие проекты разделяются только с несколькими продуктами и многими проектами, которые уникальны для конкретного продукта). Здесь около 15 лет истории кода (~ 16K svn ревизий).Как преобразовать svn: externals в теги git

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

product1_root 
    -> shared_project 
    -> project_1 
    -> project_2 
    -> project_3 
product2_root 
    -> shared_project 
    -> project_4 
    -> project_5 

Структура в SVN заключается в следующем (б/т/тр) = стандартные ответвления/метки/ствол SUBDIRS:

product1_root (b/t/tr) 
shared_project (b/t/tr) 
project_1 (b/t/tr) 
project_2 (b/t/tr) 
project_3 (b/t/tr) 
product2_root (b/t/tr) 
project_4 (b/t/tr) 
project_5 (b/t/tr) 

При использовании внешних ресурсов внешние объекты были настроены на проекты product1_root и product2_root для связи в shared/project2/3 и shared/project4/5 соответственно, чтобы они создавали указанную выше структуру на диске. В результате при выпуске выпусков принимаются только те продукты product1/2_root (внешние внешние элементы SVN автоматически вытаскивают соответствующие версии подпроектов).

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

Есть ли способ распространять теги из product1_root в project_1, project_2, project_3 и shared_project во время миграции, чтобы они соответствовали остальной части истории в новом git-репо.

Или я должен искать попытку решить эту проблему как задание до или после миграции?

Я рассмотрел множество различных инструментов, и все они, кажется, либо полностью игнорируют svn: externals, либо пытаются преобразовать их в подмодули.

+0

yay! случайные несанкционированные downvotes (почему SE даже разрешает это?). Не стесняйтесь объяснять причину. Благодарю. – kinar

ответ

0

Я, наконец, понял это. Имейте в виду, что мои svn: externals настроены так, чтобы указывать на конкретную привязку в репо (не голова), чтобы это не сработало, если вы не в одной лодке.

Кроме того, ваша миграция из SVN в git должна быть хронологической с точки зрения истории изменений в SVN, должна обрабатываться по порядку. Следующие две команды будут делать это (source):

git svn init [SVN repo url] --stdlayout --prefix=svn/ 
git svn fetch 

Это предполагает, что вы имеете стандартную раскладку репо SVN (ответвления/метки/багажник). Если вы отличаетесь, вам нужно будет изменить указанную выше команду. Вышеупомянутая команда также префикрует все с помощью svn/just, чтобы указать, что они были импортированы из svn вместо собственного git-контента (для справки в будущем, если вам это нужно).

Как только это заканчивается (требуется около 90 минут, чтобы вытащить один проект из моего SVN-репо 16K).После этого вы можете поиск даты, что ваш SVN: внешние теги были созданы в репо SVN и выяснить соответствующий мерзавец коммит, который соотносит для вашего проекта с помощью следующей команды:

git log --before='CCYY-MM-DD' -1 

Выхода будет в следующем формате :

commit a22182ca563928b4de2143ff98dd0362f9eca36d 
Author: <author> 
Date: Wed Oct 31 21:58:01 2012 +0000 

<Commit comment> 

Наконец, занимают первые несколько символов коммита хэш и создать свой тег в мерзавца:

git tag -a v6.1.1.3 a22182 -m "manually creating git tag for svn:externals based tag" 

Проверьте тег является то же самое в вашем мерзавцем репо и ваше SVN-репо, а затем продолжить с остальной частью вашего преобразования.

Смежные вопросы