SVN / TortoiseSVN мучительно медленный


Я испытываю болезненно медленные операции с одним из наших репозиториев/проектов SVN.

например, требуется 5-10 минут, чтобы вернуть изменения в один небольшой файл (10 КБ). Или около 40-60 минут, чтобы проверить проект 100 МБ.

есть около 30 других проектов на том же сервере, некоторые значительно больше, чем этот, и ни один из них не преформы, как это.

следует отметить, что этот проект является Magento. Он не очень большой с точки зрения дискового пространства, но у меня есть 23k файлов и 11K папок, и я плохо читал преформы SVN, когда есть много маленьких файлов; это правда? И есть ли что я могу сделать, чтобы ускорить?

10 58

10 ответов:

рабочая копия Subversion работает довольно плохо, когда есть огромное количество каталогов, как в вашем случае. Для операций записи (даже только локально) в рабочую копию рабочая копия должна быть заблокирована, что означает, что файл блокировки создается в каждом каталоге (это файл 11K создает), затем действие выполняется, и эти файлы 11k снова удаляются.

Subversion 1.7 переходит в другой формат рабочей копии, что должно решить эти проблемы. До тех пор есть несколько трюков, которые вы можете попытаться ускорить, например, исключить рабочую копию из вашего антивирусного сканера, отключить файловые мониторы в каталоге (например, TortoiseSvnCache) и попытаться уменьшить общее количество каталогов. (Возможно, проверив несколько отдельных рабочих копий)

существует известная проблема с использованием корзины с revert, которая вызывает медленное возвращение. Опустошение корзины и установка TortoiseSVN не использовать его во время операций возврата Как ускорить эту операцию (см. http://www.nabble.com/Revert-is-too-slow-td18222196.html).

Это определенно ускорило мои операции возврата.

Я испытал крайнюю медлительность с Subversion на Windows после изменения пароля. Мне пришлось удалить все каталоги и файлы из %APPDATA%\Subversion\auth.

теперь SVN быстр как заяц. Моя медлительность произошла как через TortoiseSVN, так и через командную строку.

SVN работает медленно, если вы используете NFS ( Сетевая Файловая Система) для рабочей копии. Это может быть ваша проблема.

попробуйте временно отключить ваш антивирус.

возврат изменений в SVN-это локальная операция, которая вообще не должна идти на сервер. Это звучит так, как будто проблема в вашей рабочей копии проекта.

попробуйте запустить "SVN cleanup" в рабочей копии; вы также можете проверить, есть ли у вас проблемы с жестким диском или файловой системой.

наш SVN бежал мучительно медленно через TortoiseSVN,затмение и командную строку. Фиксация и экспорт были медленными. Наши Zend Framework - проекты PHP на основе займет возраст, чтобы обновить и выскочить в небольшой фиксации около трех файлов займет 5-10 минут.

наша виртуальная машина SVN (CentOS) было только 700 МБ оперативной памяти, которая казалась разумной для Linux CLI, работающего только с Subversion через Apache и работает штраф около одного года. У нас всего около 20 проектов, и только три разработчика.

я увеличил его до 1,5 ГБ оперативной памяти, и теперь все работает намного быстрее, возвращаясь к нашим старым скоростям.

Я также сильно замедлился после обновления до TortoiseSVN 1.7.3.

затем я обнаружил, что у меня была отдельная установка SVN 1.6.5. Я удалил оба и переустановил TortoiseSVN, и теперь все намного лучше. Первое обновление дня в TortoiseSVN по-прежнему медленно (1-2 минуты), но быстро после этого.

мы столкнулись с подобной проблемой, проблема была TortoiseSvn (версия 1.9.7). Например,repo browser потребовалось около 10 минут, чтобы начать.

мы свернули на Show Locks функции и все исправлено!

щелкните правой кнопкой мыши на папке и выберите Tortoise\Settings затем General\Dialog 3 затем снимитеShow Locks

также некоторые хорошие подсказки можно найти на http://tigris-scm.10930.n7.nabble.com/Workaround-for-slow-RepositoryBrowser-on-large-repositories-td92324.html

У меня есть несколько проектов, которые используют Eclipse IDE. Если вы захватите каталоги проекта Eclipse, вы получите сотни и сотни крошечных файлов, которые имеют тот же эффект для моего проекта, что и для вашего.

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

внесение изменений в один файл не должен быть медленным.

вы можете попробовать предложения в еще один пост о переполнении стека о медленном SVN. Это также может быть связано с использование базы данных BDB.