Мы с радостью используем SVN для SCM на работе. В настоящее время у меня есть наши двоичные активы в том же репозитории SVN, что и наш код. SVN поддерживает очень большие файлы (он передает их «в потоке», чтобы сохранить разумное использование памяти), но делает все SLOOWWWWW. Я нормально отношусь к медленным версиям ресурсов, но медленные текстовые операции на самом деле неприемлемы.
Сейчас активы находятся в / trunk / release (рядом с дюжиной / trunk / projects). Стоит ли хранить их в отдельном репозитории? Какие еще оптимизации мы можем сделать? У нас около 1 ГБ активов, и они растут.
Вы не сказали, какие оптимизации вы уже используете. Если вы используете bsdfs, посмотрите, повысит ли производительность переход на fsfs. Если у вас много ревизий, переключитесь на более новую версию на сервере и преобразуйте репозиторий в формат 1.5.
IMNSHO, лучше держать каждый проект в собственном репозитории, хотя бы для того, чтобы номера ревизий были разделены между ними. Если проект foo не менялся в течение шести месяцев, но панель проекта находится в активной разработке, почему текущий номер ревизии foo должен постоянно меняться. Исключение, возможно, если они тесно связаны (например, у них общая библиотека), но даже в этом случае, возможно, библиотека также должна быть отдельным проектом.
Меняются ли бинарные активы когда-либо или они статичны? Если они статичны, возможно, вы вообще не хотите, чтобы они были в репозиториях (просто оставьте там небольшой заполнитель).
вероятно, лучший ответ, который вы получите, - это поместить ваши двоичные файлы в отдельный каталог и использовать функции Spare Directory для управления ими, то есть не извлекать файлы, пока они вам не понадобятся. Тогда все операции будут происходить с исходными файлами, а не с двоичными файлами.
В качестве альтернативы вы можете использовать тот же механизм для фиксации или обновления - вместо обновления вашей Рабочей копии вы можете использовать `` обновить до ревизии '' и указать HEAD и уменьшенную глубину, чтобы двоичный каталог не обновлялся (пока вам не понадобится к).
Вы также можете упаковать свои репозитории с помощью svnadmin, что повысит производительность на стороне сервера.
Revnum SVN не зависит от проекта, а от репозитория. Ошибочно думать, что foo получает новый revnum - если в foo ничего не изменилось, он не получит новый revnum! Текущее значение revnum для foo - это либо HEAD, либо последний номер revnum, в котором проект foo был изменен.