LINUX.ORG.RU

Миграция с svn на git

 ,


2

4

Доброго времени суток всем, задался тут вопросом, а как правильно мигрировать с svn на git в случае большого размера репозитория?

Для теста отзеркалировал FreeBSD Base - размер репозитория 11G, около 290000 коммитов с 1993 года. svndump в формате 2 (почему не 3, см. далее, в формате 3 - 9.8G) занимает 78G.

* git svn clone - работал полторы недели, потом был прибит, тк жрал дохрена памяти и cpu, ну и плюс http://esr.ibiblio.org/?p=6778

* reposurgeon - пытался мигрировать по этой статье. Завёл баг, что создание файла маппинга авторов коммитов svn->git жрёт дохрена (больше 16 гигов) оперативы и прибивается OOM киллером. Чел ответил:

Buy more memory

Что эпично, я считаю.

Даже без маппинга авторов процесс миграции с помощью reposurgeon (хотя он использует git-fast-import) на третий день отожрал 13 гигов оперативы и был прибит. А ещё эта хрень не понимает svndump версии 3, только 2.

Вопрос: как правильно конвертировать большие SVN репозитории в git? Кто чем пользуется? Может имеет смысл написать аналог reposurgeon на си, или крестах и аккуратнее использовать память (сейчас там питон, которого я не знаю)?

☆☆☆☆☆

А зачем и вообще для чего? Подобное — головная боль ведущих разработчиков проекта, а не твоя.

Недавно вроде перенесли GCC на git, вот только не знаю, описан ли где-нибудь опыт этого переноса. Пал ещё один оплот SVN

И Go так же мигрировал на Git, правда с Mercurial.

EXL ★★★★★ ()
Последнее исправление: EXL (всего исправлений: 1 )
Ответ на: комментарий от EXL

головная боль ведущих разработчиков проекта, а не твоя.

Как раз моя. Мне надо придумать нормальный способ миграции клиентов компании, на которую я работаю, с svn на git.

DELIRIUM ☆☆☆☆☆ ()

В девятом году перетаскивал 2Gb репу, отработало за полдня, 25k коммитов. Каких то проблем не было.

anonymous ()
Ответ на: комментарий от anonymous

Ну 2 гига - это не мой случай. Там зависимость явно не прямая (время от размера) вот 11 гигов больше недели работало (git svn clone) и так и не отработало.

DELIRIUM ☆☆☆☆☆ ()
Ответ на: комментарий от anonymous

Да, я уже выдвигал шефу идею, что скорее всего они что-то делают не так. Он обещал запросить детали.

DELIRIUM ☆☆☆☆☆ ()
Ответ на: комментарий от anonymous

Ну вот у тебя 25 тыщ, у фрибсд в 10 раз больше. Всё равно не прямая: полдня * 10 - это пять дней. У меня оно работало полторы недели (то есть 10 дней примерно) и отработало (судя по логу) процентов на 40 (когда я его прибил, оно писало про 120000й коммит примерно). Железо - сервак 8 ядер оптерон, 16 гигов оперативы (это чтобы не кричали «не запускай на калькуляторе»).

DELIRIUM ☆☆☆☆☆ ()
Последнее исправление: DELIRIUM (всего исправлений: 1 )
Ответ на: комментарий от DELIRIUM

Ну там естественно еще какое-то k в этой зависимости)

anonymous ()

мигрировать без истории, а svn сохранить для археологических целей

anonymous ()
Ответ на: комментарий от DELIRIUM

Ну и зачем прибил? Раз оно работало, пускай бы и дальше шуршало.

EXL ★★★★★ ()

Для ускорения процесса можно пожертвовать частью истории. Линус в 2006 вообще одним коммитом ядро имортировал из бикипера :)

annulen ★★★★★ ()

Доброго времени суток всем, задался тут вопросом, а как правильно мигрировать с svn на git в случае большого размера репозитория?

Я использовал в конечном счёте стандартный git svn. Условия примерно такие же, импорт занял чуть меньше месяца + импорт каждого следущего дня занимает десятки минут (в svn реп продолжает активно гадить куча человек).

Мне надо придумать нормальный способ миграции клиентов компании, на которую я работаю, с svn на git.

Вероятно тебе придётся отказаться от этой зати, git не предназначен для работы с большой файловой помойкой. Если даже и осилишь миграцию всей этой кучи дерьма на git за приемлемые сроки, то ускорить типичные операции типа git diff/commit/status... уже не получится.

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

mashina ★★★★★ ()

Клонировал как-то раз SVN репозитарий с помощью git-svn. Порядка 45k коммитов. Работало часа 3. Брат жив.

hateyoufeel ★★★★★ ()
Ответ на: комментарий от dizza

Нет, что это? Оно через git-fast-import работает, или очередная обёртка над git-svn?

DELIRIUM ☆☆☆☆☆ ()
Ответ на: комментарий от mashina

Вероятно тебе придётся отказаться от этой зати, git не предназначен для работы с большой файловой помойкой. Если даже и осилишь миграцию всей этой кучи дерьма на git за приемлемые сроки, то ускорить типичные операции типа git diff/commit/status... уже не получится.

Хуже того, типичные операции даже наверняка замедлятся, потому что применение подхода «большая помойка из проектов в корне и все коммиты колбасой в транк» приводит к регулярным отказам git push, потому что Вася-из-другого-отдела пушнул на две секунды раньше. И не дай бог ещё у центрального репозитория разрешён --force.

ilammy ★★★ ()

Чем вариант купить ОЗУ (хотя бы 32гб, лучше 64гб) или поднять своп на ssd не устроил? Компания нагенерировала кода не меньше чем FreeBSD за 20 с лишним лет, а купить станцию с 64Гб не может. Может тогда и не надо вообще дергаться, если что gitlab'у подавай сервак аж с 1.5Гб, не позволительная роскошь в наше время.

gh0stwizard ★★★★★ ()
Ответ на: комментарий от ilammy

Вот читаю вас и не понимаю, толи прикалываетесь, толи вообще не работали в совместной разработке. Первое, любая CVS должна решать проблему несоответствия того что добавляют, с тем что имеется на текущий момент. Второе, для обхода этого побочного эффекта люди изобрели бранчи (бранч на группу или одного чела). Третье, для того, чтобы не разбирать полёты кто когда и почему закоммитил в транк(мастер) и все рухнуло на проде выбирают лида, который проверяет что именно он комитит. И не поверишь, транк/мастер-ветка всегда готова принять коммит, ибо туда никто 100500 раз в день не комитит.

Но фанатики git'а, не осиляторы концепции выше, почему-то увидели, что комит сразу в мастер это их серебрянная пуля. И якобы git решает проблему конфликтных коммитов автоматом. Емнип, да эту задачу даже на бумаге в виде алгоритма не составили ещё!

gh0stwizard ★★★★★ ()

git svn clone криво написан. Там квадратичный алгоритм по отношению к количеству комиттов в svn.

rupert ★★★★★ ()
Ответ на: комментарий от rupert

Есть такое, поэтому смотрел в сторону reposurgeon. А git svn фиксить врядли будут, там была попытка сделать «новый» git svn с шахматами и поэтессами git-fast-import и git-remote-helper, но не доделали.

DELIRIUM ☆☆☆☆☆ ()
Ответ на: комментарий от gh0stwizard

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

Должно быть ты просто теоретик который читал о «совместной разработке» (tm) только в книжках. Ну тогда у меня для тебя несколько плохих новостей...

... несоответствия того что добавляют, с тем что имеется на текущий момент.

git это непременно длеает в простых случаях создавая не очень нужный merge commit. Потому чтобы такого не было делают pull + merge или rebase + push что будет работать только в репе с небольшим cps. В svn такой проблемы нет.

Второе, для обхода этого побочного эффекта люди изобрели бранчи (бранч на группу или одного чела).

Да неужели? Ну вот и расскажи это людям которые всю жизнь работали с svn. Надо понимать, что чукча не читатель и топик совсем не читал.

Третье, для того, чтобы не разбирать полёты кто когда и почему закоммитил в транк(мастер) и все рухнуло на проде выбирают лида, который проверяет что именно он комитит.

Такое имеет место быть в основном только в СПО c пул реквестами и практически никогда не бывает в коммерческой разработке где кадры проходят отбор и каждый задницей отвечает за то что творит. Понимаешь ли, никакого лида не хватит чтобы разбирать чужую работу, ну быть может только для кодеров на испытательном сроке в несколько недель.

закоммитил в транк(мастер) и все рухнуло на проде

Прямо так и пишут в книжках о процессе подготовки релизных сборок? Какие-то неправильные книжки вы читаете.

И не поверишь, транк/мастер-ветка всегда готова принять коммит, ибо туда никто 100500 раз в день не комитит.

С транком так происходит всегда, т.е. срут 100500 коммитов на каждый чих и без всяких веток. Удивительно ведть что в VCS с убогими бранчами и мержем пользователи других стратегий не практикуют, да?

Но фанатики git'а, не осиляторы концепции выше, почему-то увидели, что комит сразу в мастер это их серебрянная пуля.

Ну вот скажи честно, для тебя git это загадочный buzzword и ты таже не знаешь это это такое.

mashina ★★★★★ ()
Ответ на: комментарий от mashina

Не-не, вы правы. У всех свои методологии. И кодревью (если вообще делаете) вы делаете после коммита в мастер, когда билд не собрался видети ли и т.д. и т.п. А потом, надо будет каким-то макаром делать revert. Не-не, я не спорю, что искать приключения и решать их своим способом куда веселее, чем брать чьи-то непонятные концепции, какие-то бранчи-уянчи... нафиг все этого, мастера хватит всем.

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

gh0stwizard ★★★★★ ()
Ответ на: комментарий от gh0stwizard

Не-не, вы правы.

Это само собой, но речь же не об этом...

Без обид. Спорить не стану... просто просто высказал мнение

И это правильно, ибо ты же вообще не понял о чём идёт речь в треде, но тем не менее «мнение имеешь».

mashina ★★★★★ ()
Ответ на: комментарий от KennyMinigun

Я в курсе, доступа к репам у меня нету, но вот, например в репе фряхи бинарников нету, тем не менее 11 гигов.

DELIRIUM ☆☆☆☆☆ ()
Ответ на: комментарий от KennyMinigun

Те, кто ложат (и ложат) в репозитории бинарники, должны страдать.

rupert ★★★★★ ()
Ответ на: комментарий от rupert

А чем так знаменит? Разработчик, который мне в ответ на баг пишет:

Yeah, that's never going to work. You don't have anywhere nea r enough space in 16GB to rewad in the repo metadata. Buy more memory.

I had to buy 32GB more more for my development machine for this exact reason. The working set is about 45GB.

Как-то не очень вызывает уважение.

DELIRIUM ☆☆☆☆☆ ()
Ответ на: комментарий от anonymous

25k коммитов. Каких то проблем не было.

Как говорится почувствуйте разницу:

около 290000 коммитов с 1993 года
290K

Разница более чем в один порядок.

andreyu ★★★★★ ()
Ответ на: комментарий от gh0stwizard

git распределен, поэтому бранч фактически определяется парой имя-репозитория/имя-бранча. Вася Пупкин может в свой мастер хоть 100500 коммитов/пушей сделать, поэтом это уйдет в центральный репо одним pull-реквестом/ревью-реквестом.

Преимущество гита в том, что в нем действительно удобно работать с ветками. В svn это сделано настолько криво, что все всегда всё льют в транк.

Reset ★★★★★ ()

а не проще ли было бы наколенить скрипт который превращает коммит-сообщение с дифом из свн в что-то гит-понимаемое и гитом-коммиченное?

anonymous ()
Ответ на: комментарий от Reset

Единственная проблема это люди. Вот написал километровый PR, а кто его принимает? На веру как выше? Или человеком? Не будем продолжать в этом контексте, я просто поставлю перед фактом: человеческий фактор.

В svn это сделано настолько криво, что все всегда всё льют в транк.

Был в одной компании, где сделали как не всегда. Младшие разрабы (некоторые) были не довольны только тем, что merge делался не быстро (лиды ещё и кодили сами много). Зато проблем гонки коммитов не было. Не было частых разборов полётов, если вдруг в билде находили серьёзный баг и вообще не строился. А до этого были и вырезания (!) коммитов из дерева, навсегда.

Весь мой посыл состоит в том, что есть возможность делать не как у всех, не как проще. И модель управления эффективна также вне зависимости от CVS. Как был у вас конфликт коммитов в svn, так он у вас остался в git. Будет новая CVS xgit, будет тоже самое, т.к. фундаментальные вопросы остались не решенными.

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

gh0stwizard ★★★★★ ()
Ответ на: комментарий от gh0stwizard

На веру как выше?

Почему на веру? На PR запускаются тесты. Тесты прошли, значит дальше можно глядеть код.

Reset ★★★★★ ()
Ответ на: комментарий от Reset

Какие тесты? Задам даже более серьёзный вопрос: тесты развертывают тестовое окружение, строят билды? А результат тестов проверяется? Сравнивается с предыдущим? Учитываются регрессии?

И нет, мне даже не интересно слушать ваши ответы. Ваша компания — ваши правила. Только не надо быть евангелистом «как всегда», это просто противно. Живите дальше в своём безальтернативном мире.

gh0stwizard ★★★★★ ()
Последнее исправление: gh0stwizard (всего исправлений: 1 )
Ответ на: комментарий от gh0stwizard

тесты развертывают тестовое окружение, строят билды? А результат тестов проверяется? Сравнивается с предыдущим? Учитываются регрессии?

Ты удивишься, но ответы да.

И нет, мне даже не интересно слушать ваши ответы.

Зачем тогда задаешь?

Живите дальше в своём безальтернативном мире.

Какую альтернативу ты предлагаешь? svn с кучей костылей-скриптов чтобы хоть как-то на нем можно было реализовать _удобную_ работу с ветками?

Reset ★★★★★ ()

Я бы сделал первый коммит чистый. От него вторым коммитом текущее состояние репозитория и начал работать с ним. Параллельно запустил бы перенос коммит за коммитом из svn-а в отдельную ветку не торопясь. Когда этот перенос закончится (пусть хоть год идёт, куда торопиться) — сделал бы rebase сделанных за это время изменений и всё.

Legioner ★★★★★ ()
Ответ на: комментарий от Legioner

Зачем для этого нужны какие-то тулзы, я вообще не понимаю, честно говоря. Сделал checkout очередного коммита в SVN-е, закоммитил в GIT-е с тем же текстом и датой. На баше можно за пару часов скрипт нарисовать. Усложняете всё по-моему на ровном месте.

Legioner ★★★★★ ()
Последнее исправление: Legioner (всего исправлений: 1 )
Ответ на: комментарий от Legioner

Сделал checkout очередного коммита в SVN-е, закоммитил в GIT-е с тем же текстом и датой. На баше можно за пару часов скрипт нарисовать.

Большинство инструментов импорта из svn примерно так и работает. Но тут есть некоторое кол-во особенностей, например что в svn можно создавать директории, а в git нет и тулзы вынужденны как-то костылить такие разницы. Но самая основная проблема что это работает очень медленно.

mashina ★★★★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.