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

Question

Вскоре после обновления нашего хранилища до 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.

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

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

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

Answer 1

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

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

Answer 2

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

Answer 3

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

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

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

Answer 4

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