Можно ли использовать Git-svn на больших разветвленных репозиториях?

Question

Я пытаюсь использовать Git как интерфейс в хранилище SVN для того, чтобы иметь возможность использовать хорошие возможности Git и как простой разветвленности, припрятать и т.д.

Проблема заключается в том, что репозиторий SVN является довольно большим (8000 оборотов) и содержит множество ветвей и тегов (старых, а также новых).

Это стандартная версия с конфигурацией, содержащей директивы выборки, ветви и теги.

Поскольку самая старая ветка и метка относится к ревизии 10, это означает, что каждый svn fetch считывает всю историю репозитория из ревизии 10 и пересылает ее, что может занять несколько часов при медленном соединении.

Если я только отслеживаю багажник, то это прекрасно, но я все еще хочу, чтобы git знал о новых ветках и тегах.

Обычно я смотрю git log -1 на ветке, на которой я нахожусь, и получает версию SVN из комментария, поэтому я могу сделать git svn fetch -r7915:HEAD или аналогичный. Наверное, это то, что делает git svn fetch --parent. Но зачем мне это нужно?

Я нахожусь в Windows и использую TortoiseGit, который имеет неплохую поддержку для git-svn, но так как TortoiseGit работает только git svn fetch Я как бы застрял.

Я что-то не так? Я ожидаю, что svn fetch будет быстрой операцией при завершении первого svn clone -s.

Answer 1

Вы используете его правильно: первоначальный импорт репозитория Subversion с большим количеством истории будет очень медленным.

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

Начните клон вечером и вернитесь к хорошему git repo на следующее утро!

После того, как вы клонировали, git svn fetch даже предупреждает вас:

This may take a while on large repositories

Subversion просто и глупо, так что мерзавец должен принимать вещи медленно.

Answer 2

Если вам не нужна полная история в репозитории git, я рекомендую вам взглянуть на подход «git + svn», подробно описанный в ссылке ниже, вместо стандартной интеграции git-svn. Ваш первоначальный импорт в git должен быть очень быстрым, поскольку вы не будете импортировать историю.

Обязательно прочитайте раздел «Преимущества, недостатки и извлеченные уроки».

http://www.lostechies.com/blogs/derickbailey/archive/2010/02/03/branch-per-feature-how-i-manage-subversion-with-git-branches.aspx

Answer 3

Спасибо за ответы. Однако они мне не помогли.

Эта команда является лучшим решением до сих пор:

git svn log --all -1 | \ 
    sed -n '2s/r\\([0-9]*\\).*/\\1/p' | \ 
    xargs --replace=from git svn fetch -r from:HEAD

Он использует git svn log --all найти самый высокий номер ревизии SVN принес до сих пор, и извлекает все с этого момента.

Желаю, чтобы git svn fetch имел возможность вести себя следующим образом. Если изменения SVN не изменяются, нет причин, по которым git svn должен получать одни и те же изменения каждый раз.

Answer 4

У вас есть символические ссылки в репозитории SVN? Если нет, то вы пробовали этот параметр:

svn.brokenSymlinkWorkaround

Это отключает потенциально дорогостоящие проверки для обхода сломанной симлинки проверены в SVN пунктирными клиентов. Установите этот параметр в значение «false», если вы отслеживаете репозиторий SVN со многими пустыми блоками, которые не являются символическими ссылками. Эта опция может быть изменена, пока git svn работает и вступает в силу на следующей ревизии. Если unset, git svn предполагает, что этот параметр будет «истинным».