Оптимизация SVN для обеспечения поддержки больших репозиториев

Question

Мы с удовольствием используем SVN для SCM на работе. В настоящее время мои бинарные активы находятся в том же SVN-хранилище, что и наш код. SVN поддерживает очень большие файлы (он передает их «потоково», чтобы сохранить использование памяти в разумных пределах), но он делает все SLOOWWWWW. Я в порядке с медленным версионированием ресурсов, но медленные текстовые операции не совсем приемлемы.

Сейчас активы находятся в / trunk / release (рядом с дюжиной / trunk / projects). Должны ли мы хранить их в отдельном хранилище? Какие еще оптимизации мы можем сделать? У нас около ГБ активов и растет.

Answer 1

Вы не сказали, какие оптимизации вы уже используете. Если вы используете bsdfs, посмотрите, повышает ли производительность переключение на fsfs. Если у вас большое количество ревизий, переключитесь на более новую версию на сервере и преобразуйте репозиторий в формат 1.5.

Answer 2

ИМНШО, лучше хранить каждый проект в своем собственном репозитории, хотя бы просто для того, чтобы номера ревизий были разделены между ними. Если foo проекта не менялась в течение шести месяцев, но панель проекта находится в активной разработке, почему текущий номер версии foo должен меняться. Возможно, исключение, если они тесно связаны (например, у них общая библиотека), но даже тогда, возможно, библиотека должна быть и собственным проектом.

Бинарные активы вообще когда-либо меняются или они статичны? Если они статичны, возможно, вы вообще не хотите, чтобы они были в репозиториях (просто оставьте там небольшой заполнитель).

Answer 3

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

Кроме того, вы можете использовать тот же механизм для фиксации или обновления - вместо обновления рабочей копии вы можете использовать «обновление до ревизии» и указать HEAD и уменьшенную глубину, чтобы двоичный каталог не обновлялся ( пока не надо).

Вы также можете 'svnadmin pack' в своих репозиториях, что повысит производительность на стороне сервера.