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

Question

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

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

Это макет, близкий к стандартному, с конфигом, содержащим директивы fetch, branch и tags.

Поскольку самая старая ветвь и тег относятся к ревизии 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

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

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

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 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

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

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

Запусти клон вечером и вернись в хороший репозиторий на следующее утро!

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

This may take a while on large repositories

Subversion проста и глупа, поэтому git должен работать медленно.

Answer 4

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

svn.brokenSymlinkWorkaround

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