Мерзавец-svn может использоваться на больших, разветвленных репозиториях?
Я пытаюсь использовать Мерзавца в качестве frontend к репозиторию SVN, чтобы смочь использовать хорошие функции Мерзавца как простое ветвление, пряча и т.д.
Проблема состоит в том, что репозиторий SVN является довольно большим (8 000 версий) и содержит много ответвлений и тегов (старый, а также новый).
Это - почти стандартное расположение, с конфигурацией, содержащей выборку, ответвления, и отмечает директивы.
Начиная с самого старого ответвления и тега относится к пересмотру 10, это означает что каждый svn fetch читает всю историю репозитория из пересмотра 10 и вперед, который может занимать часы на медленном соединении.
Если я только отслеживаю соединительную линию, то она прекрасна, но я все еще хочу сделать мерзавца, знающего о новых ответвлениях и тегах.
Я обычно смотрю на 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 завершено.
4 ответа
Вы используете его правильно: первоначальный импорт репозитория Subversion с большим количеством истории будет очень медленным.
Плохое новости состоит в том, что ветки и теги Subversion - это только каталоги, GIT-SVN вынуждены взять на себя пессимистический путь к чтению каждой ветви от головы до первой ревизии. Да, если вы дисциплинировали в своем использовании Subversion, это приведет к тому, что это приведет к многим выборам одинаковых данных, но узоры реального мира делают это вряд ли.
Начните клону вечером и вернитесь к хорошему Git Repo на следующее утро!
После того, как вы клонировали, Git SVN Fetch даже предупреждает вас:
This may take a while on large repositories
Subversion проста и глупо, поэтому Git должен медленно взять вещи.
Если вам не нужна полная история в репозитории git, я рекомендую вам взглянуть на подход "git + svn", подробно описанный в ссылку ниже, вместо стандартной интеграции git-svn. Ваш первоначальный импорт в git должен быть очень быстрым, поскольку вы не будете импортировать историю.
Обязательно прочтите раздел «Преимущества, недостатки и извлеченные уроки».
Спасибо за ответы. Однако они мне не очень помогли.
Эта команда - лучшее решение на данный момент:
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 должен каждый раз получать одни и те же ревизии снова и снова.
Есть ли у вас симлинки в SVN-репо? Если нет, пробовали ли вы использовать эту настройку:
svn.brokenSymlinkWorkaround
Это отключает потенциально дорогие проверки для обхода сломанных симлинков, проверенных в SVN неработающими клиентами. Установите этот параметр в значение "false", если вы отслеживаете репозиторий SVN с большим количеством пустых блобов, которые не являются симлинками. Этот параметр может быть изменен во время работы git svn и вступать в силу при следующей полученной ревизии. Если параметр не установлен, git svn принимает эту опцию за "true".