Производительность наложения файлов TortoiseSVN - есть ли способы ее улучшения?

Я использую TortoiseSVN на моей машине разработки (под управлением Windows Server 2003) и VisualSVN Server на стороне сервера. Оба являются последними версиями (против Subversion 1.6.5).

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

Ответ на вопрос может быть нереальным, учитывая количество переменных (например, другое установленное программное обеспечение), но есть ли какие-либо известные приемы для ускорения обновления этих оверлеев?

Ответ 1

К большому увеличению производительности, которое я получил, нужно было настроить клиентские значки Overlays, чтобы не обрабатывать весь жесткий диск, только в тех местах, где живут мои SVN файлы.

Чтобы сделать это, откройте настройки (щелкните правой кнопкой мыши в Explorer- > TortoiseSVN- > Настройки), выберите Значки Overlays, затем в Исключить пути: введите c:\*

В Включение путей: введите пути к каталогам рабочей копии Subversion (для меня все находятся под c:\subversion\* и c:\workspaces\*)

Используйте новую строку для разделения записей (см. снимок экрана)

Это заставило клиента казаться в тысячу раз быстрее.

В этом скриншоте показано, как исключить c: и d: диски, включая только соответствующие каталоги:

Вы можете получить дополнительные советы по производительности от TortoiseSVN docs.

Ответ 2

Вы можете полностью отключить TSVNCache.exe. Я решил, что готов жить без обновленных значков, если это означает, что я мог быстрее и быстрее открывать и закрывать Visual Studio.

Вы также можете снизить приоритет TSVNCache, что и сделал мой босс с успехом. Основная проблема, с которой мы столкнулись, - это время запуска и выключения Visual Studio, поэтому он написал командный файл, который понизил приоритет процесса, а затем начал VS.