2009-06-04 2 views
58

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

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

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

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

+1

чувак это не нормально, даже не близко к тому, что нормальная скорость SVN являются , Вы должны допросить, кто управляет вашим сервером/репозиториями svn и каким чертом этот сервер работает. Имеет ли он 1 гигабайт или что-то серповидное? Нет подсказки, почему в ответе говорится, что то, что вы подробно описали нами, является нормальным, потому что это не так. Причина заключается в том, что разработчики плохо работают или не поддерживают ваш svn-репо. Это неприемлемо. – PositiveGuy

+0

Какой формат репозитория вы используете на сервере? FS? BDB? Вы могли бы попробовать другой? –

+0

Если это помогает s.o. в поисках симулятивной проблемы: моя настройка тоже была очень болезненной: win7, eclipse, visualsvn. После смены JavaHL на встроенную Win-реализацию это была скоростная ракета. –

ответ

54

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

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

+1

Я не понимаю. Я работал с Tortoise SVN для 3-4 компаний и никогда не видел, чтобы это было медленным, и у нас были проекты, которые составляли 1 Гб! Я шокирован тем, что теперь вижу такие темы, как сейчас, когда я нахожусь в новой компании, и я беру часы, чтобы загрузить проект на 300mb .NET. – PositiveGuy

+1

Еще одна компания, где она медленная ... wtf v1.6, но я видел, что v1.6 будет намного быстрее, чем это в других компаниях. – PositiveGuy

+1

Четыре года спустя от последнего комментария и догадайтесь, что? SVN все еще болезненно медленный. Я работаю с большим проектом около 2-3 ГБ и многими, многими каталогами.Я просто смирился с тем, что не могу выполнить «фиксацию» или «обновление» всего проекта. Это должно быть сделано в кусках - примерно я должен разделить примерно на 10 подпапок. Обновление. Иногда мне удается уйти, потому что я думаю, что он не захватывает так много замков. –

1

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

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

+1

попробовал очистить - также это происходит для других пользователей. – Dan

+0

Все ли пользователи используют машину? Или это происходит на рабочей станции каждого пользователя? – Avi

0

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

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

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

Вы можете попробовать предложения в another post on Stack Overflow about slow SVN. Это также может быть связано с using a BDB database.

+2

Он не может иметь ничего общего с базой данных базы данных, потому что возврат файла является локальной операцией. SVN не проверяет файлы по одному, а работает на деревьях файлов. –

6

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

+1

Черепаха - только Windows ... –

+4

@ChrisKL: И Windows поддерживает NFS. –

20

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

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

+2

У меня была одна и та же проблема несколько раз, и по моему опыту это был Корзинка, которая была виновницей. –

+1

Резервуар не может влиять на производительность проверки, хотя –

+0

Я нахожусь на TortoiseSVN 1.7.6 и возвращаюсь, остается болезненно медленным, но мой мусорный ящик медленный - я всегда использую shift-delete для удаления без утилизации. Я просто изменил Tortoise для деактивации: Диалоговое окно настроек -> Диалоги 1 -> «Использовать корзину при возврате». Готов поспорить, это поможет! Спасибо! – AnneTheAgile

9

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

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

+2

Такая же проблема в моем случае, удаление папки «auth» действительно помогает. –

+2

Это действительно спасло мой день. –

+3

Для меня в окнах 10 это было в C: \ Users \ UserName \ AppData \ Roaming \ Subversion \ auth –

1

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

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

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

1

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

1

У меня также было значительное замедление после перехода на TortoiseSVN 1.7.3.

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

1

У нас есть аналогичная проблема, проблема была 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