Ускорение начальной загрузки git-svn

Question

У меня большой репозиторий, более 100 000 ревизий с очень высоким коэффициентом ветвления.Первоначальная загрузка полного репозитория SVN с использованием git-svn выполнялась около 2 месяцев, и только до версии 60 000.Есть ли способ ускорить эту вещь?

Я уже регулярно убиваю и перезапускаю загрузку из-за утечки памяти в git-svn как сита.Передача происходит по локальной сети, поэтому скорость соединения не должна быть проблемой.Репозиторий находится на выделенной машине, поддерживаемой выделенными массивами оптоволоконных каналов, поэтому на сервере должно быть много работы.Единственное, о чем я могу думать, это сделать клон из локальной копии репозитория SVN.

Что другие люди сделали в подобных обстоятельствах?

Answer 1

На работе я использую git-svn против репозитория SVN ~ 170000 ревизий. Я использовал git-svn init + git-svn fetch -r..., чтобы ограничить мою первоначальную выборку разумным количеством ревизий. Вы должны быть осторожны, чтобы выбрать ревизию, которая действительно находится в той ветке, которую вы хотите. Все полностью функционально, даже с усеченной историей , за исключением git-blame, которая, очевидно, приписывает все строки старше, чем ваша начальная версия, первой версии.

Вы можете еще больше ускорить это с помощью путей игнорирования для удаления ненужных поддеревьев.

Вы можете добавить больше ревизий позже, но это будет болезненно. Вам нужно будет сбросить карту оборотов (к сожалению, я даже написал git-svn reset, и я не могу сказать, что она удалила все ревизии, так что это может быть сделано вручную). Затем git-svn fetch больше ревизий и git-filter-branch, чтобы переопределить ваш старый корень для нового дерева. Это перепишет каждый коммит, но не повлияет на сами исходные двоичные объекты. Вы должны сделать аналогичную операцию, когда люди берут большие перегруппировки в SVN-репо.

Если вам на самом деле нужны все ревизий (например, для миграции), тогда вам следует взглянуть на некоторую разновидность svn-fast-export + git-fast-import. Может быть один, который добавляет теги rev для соответствия git-svn, и в этом случае вы можете быстро импортировать, а затем просто перенести в удаленный svn. Даже если в существующих опциях svn-fast-export такой функции нет, вы, вероятно, можете добавить ее до того, как ваш исходный клон завершится!

Answer 2

Видимо, нет хорошего ответа. Некоторая работа выполняется над git-fast-import, но она еще не готова к прайм-тайм. Они все еще пытаются выяснить, как обнаружить и представить действия 'svn cp'. Одним из ярких моментов является то, что кто-то из списка предложил оптимизацию для git-svn, которая, кажется, оказала большое влияние.

http://permalink.gmane.org/gmane.comp.version-control.git/168718

Answer 3

В репозитории с 20k коммитами у меня были похожие проблемы. В моем случае оказалось, что в Subversion было несколько странных тегов, которые вызывали проблемы. Были теги, которые копировали / вместо / trunk. Это приводит к тому, что git svn fetch входит в бесконечный цикл. Я исправил это, преобразовав куски.

git svn fetch -r0:1000
git svn fetch -r0:2000
git svn fetch -r0:3000

Смотрите вывод, и если вы не видите новый r ... время от времени, значит что-то не так. Используйте git log --all, чтобы увидеть, как далеко продвинулась конверсия. Допустим, вы попали в 1565. Затем продолжайте выборку вот так.

git svn fetch -r1567:2000

Это было очень утомительно, но с этим справились.

Answer 4

Если вы можете найти сервер с достаточным объемом оперативной памяти, выполните всю операцию клонирования на виртуальном диске.В системах Linux вы можете использовать / dev / shm, который поддерживается RAM.

> svnadmin hotcopy /path/to/svn/repo /dev/shm/svn-repo

> git svn clone file:///dev/shm/svn-repo /dev/shm/git-repo

Как только это будет сделано, вы можете вместо этого указать git-репо на свое реальное svn-репо, как описано здесь: https://git.wiki.kernel.org/index.php/GitSvnSwitch

• Изменить URL-адрес svn-remote в .git / config так, чтобы он указывал на новое доменное имя
• Запустить git svn fetch - для этого нужно выбрать как минимум одну новуюревизия из svn!
• Измените URL-адрес svn-remote на исходный URL-адрес
• Запустите git svn rebase -l, чтобы выполнить локальную перебазировку (с изменениями, внесенными в результате последней операции выборки)
• Изменить URL-адрес svn-remote обратно на новый URL-адрес
• Запустить git svn rebase теперь должно работать снова!

Это будет работать, только если git svn fetchшаг на самом деле выбирает что-нибудь!(Мне потребовалось некоторое время, чтобы обнаружить, что ... Мне пришлось добавить фиктивную ревизию в наш svn-репозиторий, чтобы это произошло!)

Я только что сделал это и смог клонировать 4.7G12000 ревизий svn репо в git примерно за 3 часа.

Answer 5

У меня есть репо с 8k + обзоров и около 240 тегов.Я попытался запустить и оценил, что мой первый клон git svn на windows занял бы месяцы, просто выполнив

git svn clone --stdlayout --no-metadata --authors-file=users.txt https://link.to.repo

Клону потребовалось 5 секунд, чтобы импортировать в среднем 1 ревизию.Обратите внимание, что при обнаружении тега клон перезапускается с версии 1, поэтому потенциально можно выполнить 8k * 240 операций = 111 дней

Сводка всех моих шагов, предпринятых для ускорения процесса:

1. Реализация Linux и OSX намного быстрее, чем Cygwin на Windows.Я использовал виртуальную машину Linux.Пожалуйста, проверьте https://stackoverflow.com/a/21599759/1448276

2. Я скопировал весь репозиторий SVN на свою машину с помощью svnrdump

svnrdump dump https://link.to.repo > repos.dump

Я создал локальное SVN-репо

svnadmin create svnrepo

svnadmin load svnrepo < repos.dump

как в https://stackoverflow.com/a/10407464/1448276

Я создал и смонтировал диск на базе оперативной памяти

svnadmin hotcopy svnrepo/ /dev/shm/svnrepo

, как указано выше, https://stackoverflow.com/a/39030862/1448276

И, наконец, запустил клон

git svn clone --stdlayout --no-metadata --prefix=origin/ --authors-file=users.txt file:///dev/shm/svnrepo

Здесь клон обрабатывает в среднем 12,5 ревизий в секунду, поэтому я ожидаю, что это займетменее 2 днейЯ опубликую обновление, как только клон будет завершен.

Answer 6

Я уже загружал SVN-репозиторий, близкий к 100 000, с помощью git-svn. Это заняло около 48 часов и было не по локальной сети. Правда, вы сказали, что в вашем хранилище высокий коэффициент ветвления, а в загруженном мной хранилище нет (хотя в нем было несколько десятков веток)

Я бы посоветовал разобраться, где находится узкое место. Git-svn и его подпроцессы используют 100% CPU? Индикаторы диска на клиенте или на сервере SVN постоянно горят? Какая пропускная способность используется? Как только вы узнаете, что является ограничивающим фактором, вы сможете разобраться, как это исправить.

Answer 7

Я думаю, что вы на правильном пути

Локальный доступ к файлам может привести к ускорению на 1 - 2 порядка.

Не уверен, что запуск git svn с bdb или svn на основе файлов будетбудь быстрее.

Answer 8

2017 звонит. Я переношу репозиторий с 45-тысячной редакцией и обнаружу, что git-svn в Linux работает примерно в 10 раз быстрее, чем git-svn на моем компьютере с Windows.Vm равен на том же HyperV, что и мой репозиторий SVN, так что это может быть так.