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

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

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

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

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

Ответ 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 должен получать одни и те же изменения каждый раз.

Ответ 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

Ответ 3

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

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

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

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

This may take a while on large repositories

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

Ответ 4

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

svn.brokenSymlinkWorkaround

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