Запросы на svn revision внезапно кажутся медленными (возможно, начиная с svn 1.5?)

Вскоре после обновления нашего хранилища до Subversion 1.5 моя команда переключилась на написание нового приложения на несколько месяцев, а затем внезапно вернулась к нашей исходной базе кода. Наши разработчики используют TortoiseSVN 1.5.9 и Subversion Client 1.6 (только для svnversion -n) и Subversion 1.5 на нашем сервере. Наши клиенты подключаются через svn + ssh.

Наша оригинальная кодовая база интегрирует номер редакции SVN в код, который используется svnversion -nдля запроса текущей версии WC. Внезапно, однако, эта операция перешла к тому, что, как я помню, заняла короткую секунду или две до целых 10 секунд (и я видел еще хуже в средах разработки виртуальных машин и т. Д.) Мы также испытывали аналогичные задержки, возвращаясь и экспериментируя с SubWCRev и клиентом Subversion от Tortoise 1.5.

Это не серьезная проблема, но, безусловно, раздражает, так как эта проверка выполняется как шаг перед компиляцией перед каждой операцией сборки. Таким образом, я хотел бы получить железо в те несколько секунд из нашего цикла обратной связи!

Итак, мой вопрос: просто я слишком долго отсутствовал в своей старой кодовой базе или кто-то еще заметил задержку для этой операции?

Если эта задержка является новым явлением, кто-нибудь исправил это. Если так, то как?

8.05.2009 19:36:39
Трудно сказать, в чем заключается ваша конкретная проблема, но я обнаружил, что репозиторий SVN значительно замедляется со временем, особенно если вы ищете ревизии, отличные от HEAD. Я сомневаюсь, что замедление происходит с клиентом, поскольку именно на сервере происходит реальная работа по вычислению всех этих различий.
Kekoa 8.05.2009 19:45:37
Что такое "Subversion -n"? В моей среде нет исполняемого файла "subversion", и исполняемый файл "svn" не поддерживает параметр "-n".
Wim Coenen 9.05.2009 11:29:35
Упс: исправлено что svnversion -n.
antik 11.05.2009 13:07:02
@wcoenen Он имел в виду (и впоследствии отредактировал, чтобы сказать) "svnversion -n", а не "subversion -n".
Zach Burlingame 11.05.2009 13:07:46
4 ОТВЕТА
РЕШЕНИЕ

В чрезвычайно рекомендуемой книге SVN Red-Bean говорится, что большие коммиты (много файлов за один коммит) могут сильно повлиять на производительность. Вы недавно зарегистрировали большое количество файлов, скажем, за последние 100 проверок?

2
9.05.2009 04:27:17
Может ли на нас повлиять большая фиксация количества файлов в хранилище в каталоге, который не находится под нашим путем извлечения? Обычно мы работаем в repo-root / proj1 / ... и недавно (фактически, совпав с моими наблюдениями за медленным ответом), один из наших разработчиков передал ОГРОМНЫЙ список файлов в repo-root / proj2 / ..
antik 11.05.2009 13:06:50
Запуск svnversion -n на локальной рабочей копии не приводит к трафику на сервер Subversion. Я полагаю, что он использует информацию о свойствах, хранящуюся в папках .svn / _svn, которая содержит такие вещи, как текущая ревизия, последняя ревизия фиксации, а также, была ли она изменена или нет для определения результата. Если большая фиксация не была выполнена в пределах рабочей копии, будет ли это работать svnversion -nлокально и если да, то почему?
Zach Burlingame 11.05.2009 13:13:13
Это случилось с нами, кто-то решил поместить исходный код ядра Linux в один из стволов нашего проекта для тестирования производительности. После того, как они «удалили» его, мы увидели очень долгое время ожидания получения журнала svn, так что я закончил тем, что взял дамп хранилища, отфильтровав путь, к которому они пришли, и загрузил его обратно.
tim harrison 21.06.2011 19:26:02

Я согласен с Джоном Уэлдоном. Если вы используете Apache (http (s)), тогда есть возможность замедлить вашу команду svn log. Это происходит при фиксации с большим количеством измененных / добавленных путей к файлам. Одним из решений является удаление авторизации на основе пути или удаление конкретной ревизии. Смотрите для более подробной информации здесь :

Вся эта проверка пути иногда может быть довольно дорогой, особенно в случае svn log. При получении списка ревизий сервер просматривает каждый измененный путь в каждой ревизии и проверяет его на удобочитаемость. [...] Само собой разумеется, это может занять много времени на ревизиях, которые затрагивают большое количество файлов . Это цена безопасности: даже если вы вообще не настроили такой модуль, как mod_authz_svn, модуль mod_dav_svn по-прежнему запрашивает у Apache httpd проверку авторизации на каждом пути.

4
9.05.2009 08:49:52
Я ошибаюсь, полагая, что эта проблема не повлияет на репозиторий, работающий на svn + ssh? Если нет, то этот ответ не относится к моей конфигурации: мы не используем https.
antik 11.05.2009 13:14:01
Вы правы - спасибо за ответ, который высветил этот недостаток в вопросе.
antik 14.05.2009 12:57:23

Я только что решил проблему на своем сервере. Что вы используете для аутентификации? Операция checkout, commit или log - это серия из нескольких HTTP-запросов. В случае отображения журнала, это сотни. Если у вас есть слой авторизации, он будет аутентифицироваться при каждом запросе. Если вы работаете против медленного бэк-энда, это замедлит вас. В моем случае мы выполняли аутентификацию на нашем сервере IMAP (пользовательский mod_auth_imap). После того, как я добавил кеширование в слой auth (держите пары хеш-пользователь / пароль в течение шестидесяти секунд), он резко ускорился: извлечение раньше занимало 1,5 минуты, а теперь - три секунды.

1
11.06.2009 21:33:09

В (правильно настроенном) zsh вы можете попробовать это в корневой папке svn:

sed -ns "4 p" **/.svn/entries | sort | uniq

Это даст ревизию вашего последнего обновления или список ревизий, если ваш репозиторий смешанный. Это не так полно, как то, что делает «svnversion», и, возможно, не совместимо со всеми версиями svn (у меня это 1.6.16), но в некоторых случаях оно выполняет свою работу и невероятно быстро (1 с против 3 мин в моем случае). !)

1
19.04.2011 23:45:10
Спасибо за подсказку, у меня есть репо около 125K файлов, и эта команда занимает 31 миллисекунду против svnversion, что занимает 2 минуты!
RishiD 5.05.2011 12:27:42