Подтвердить что ты не робот

Ускорение первоначальной выборки git -svn

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

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

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

4b9b3361

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

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

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

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

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

Ответ 3

В репозитории с фиксацией 20 тыс. у меня были подобные проблемы. В моем случае оказалось, что в подрывной деятельности было несколько странных тегов, которые вызвали проблемы. Были теги, которые копировали/вместо/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

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

Ответ 4

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

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

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

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

Ответ 5

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

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

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

Ответ 6

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

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

Ответ 7

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

Ответ 8

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

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

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

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

  • реализация linux и osx намного быстрее, чем cygwin на окнах. Я использовал виртуальную машину linux. Пожалуйста, проверьте fooobar.com/info/153889/...

  • Я скопировал все svn repo на свою машину с помощью svnrdump

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

  1. Я создал локальное svn repo

    svnadmin create svnrepo

    svnadmin load svnrepo < repos.dump

как в fooobar.com/info/118269/...

  1. Я создал и установил диск с основанием

    svnadmin hotcopy svnrepo/ /dev/shm/svnrepo

как указано выше, fooobar.com/info/153886/...

  1. И, наконец, побежал клон

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

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