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

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

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

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

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

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

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

А чем перетаскивал? git svn clone?

И неужели у вас кода там больше, чем во FreeBSD Base?

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

Да.

Скорее всего там стопитсот проектов на репу, поэтому не все так страшно.

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

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

Там прямая зависимость от количества коммитов.

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

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

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

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

subgit пробовал?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

десятки гигов.

Если в репозиториях валяются большие бинарники, то git — не лучший выбор. Говорю как git-фанбой.

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

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

reposurgeon

Сам Eric S. Raymond написал? Значит, стоит посмотреть.

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

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.

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

Вот здесь чуваки ему собирают новую машинку (заодно и рассказывают про то, чем он знаменит): https://www.youtube.com/watch?v=875NbdL39A0

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Читай об этом в «Pro Git»

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

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

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

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

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

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

Задача эта нерешаемая без распила репозитория.

В случае такого большого - да.

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

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

Авторство тоже важно.

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

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

держи, просвещайся https://www.cs.cmu.edu/~rwh/papers/htpt/paper.pdf