Лучшие практики для одного крупного проекта SVN

Question

Я унаследовал один проект в SVN: 30 Гб в более чем 300 000 файлов. Там есть множество бинарных файлов, в основном в папке с изображениями. Операции, такие как обновление всего проекта, могут быть очень медленными.

Команда разработала процесс, позволяющий запускать обновление / переключение только в определенных папках, над которыми они работают, и заканчивать проверку на наличие неработающего кода, поскольку «он работает на моем компьютере». Рабочая копия любого человека может содержать устаревший код, измененный код и забытый, никогда не переданный код. Также имеет место минимальное ветвление.

Мое личное решение - небольшой сценарий проверки / сборки bash в 5 утра каждое утро, однако не у всех есть смелость командной строки даже скопировать мое решение и предпочел бы комфорт черепахи svn и сломанный процесс.

Кто-нибудь пытался настроить такой большой репозиторий и может дать совет? Есть ли какие-либо лучшие практики, которые я могу применить для работы с большими репозиториями, в которых я могу помочь каждому?

P.S. внешние возможности не кажутся хорошей идеей, и оптимизация SVN для обеспечения поддержки больших репозиториев здесь не применима, потому что я имею дело с одним проектом

P.P.S. В настоящее время рассматривается также: http://www.ibm.com/developerworks/java/library/j-svnbins.html

Answer 1

Во-первых, обновитесь до SVN 1.6 как на клиенте, так и на сервере. В примечаниях к последней версии упоминается ускорение работы с большими файлами (r36389).

Во-вторых, это может не подходить для вас, если у вас есть весь проект в рабочей копии, но вы используете разреженные каталоги . Мы делаем это для нашего большого репо, первое, что делает клиент, это извлекает только каталог верхнего уровня, затем, чтобы получить больше данных, использует браузер репо, чтобы перейти к нужному каталогу и «обновить его до этой ревизии». Это прекрасно работает на TortoiseSVN. 1.6 также имеет опцию «уменьшить глубину» для удаления каталогов, с которыми вам больше не нужно работать.

Если это не для вас, вы все равно можете обновить некоторые части рабочей копии. Обновление, как правило, происходит медленнее, чем больше у вас файлов (то есть в Windows NTFS кажется особенно плохой со стратегией блокировки, используемой для обновления. Берт Хуйбен заметил это и предложил исправление - TBA с выпуском 1.7 , но вы могли бы перестроить свой текущий код с помощью его «быстрого исправления».

Альтернативой может быть изменение вашей файловой системы. Если вы можете переформатировать, вы можете попробовать ext2 IFS драйвер , но я уверен, что вы будете осторожны с этим!

Последний вариант - отключить ваш антивирусный сканер для файлов .svn, а также для хранилища на сервере. Если вы запускаете Apache на сервере, убедитесь, что вы включили в течение короткого времени живые сообщения (чтобы предотвратить повторную аутентификацию). Также отключите индексирование в каталогах вашей рабочей копии и теневой копии тоже. (последнее не очень помогает, но вы можете увидеть лучшее улучшение, которое я сделал, отключив AV на сервере, хотя мой ответ SVN увеличился в 10 раз).

Answer 2

У нас есть два репозитория, один для нашего кода (часто изменяется), а другой для наших двоичных данных (очень большой, изменяется не часто). Иногда это больно, но стоит работать быстрее с кодом.

У нас также есть сценарий Ruby, который мы называем «ежедневное обновление», который регистрируется в нашем хранилище и который запускается на всех наших компьютерах для разработки с помощью запланированной задачи Windows, рано утром. Он обновляет обе проверки до последней версии, а затем создает все локально, поэтому мы готовы к работе, как только мы приедем утром.

Есть некоторые ошибки, которые мы еще не прояснили - например, когда наши автоматизированные тесты выполняются, в настоящее время существует задержка между тем, когда они проверяют код и когда они извлекают данные, поэтому, когда мы фиксируем изменения в оба репозитория сервер CI иногда получает старый код и новые данные, что приводит к ошибкам тестирования.

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

Answer 3

Я буду кратким:

• Обновление до последней версии (1.6.x). 1.5.x также имел оптимизацию скорости.
• Убедитесь, что все используют одну и ту же версию TortoiseSVN, которая построена против точной версии сервера. У нас было много проблем с парнями, которые обновляли прихоть, а потом получали странные проблемы.
• Внешние интерфейсы работают между серверами, репозиториями и папками в одном репо. Таким образом, вы можете переместить двоичные файлы на другой репозиторий / сервер и просто связать их внешними ссылками.
• Реструктурируйте папки, чтобы вы могли разрозненно оформить заказ и по-прежнему иметь возможность работать продуктивно. В основном все проверяют папку «топы» + только потомки, а затем выборочно «обновляют до ревизии» папки, которые им необходимо полностью извлечь.
• Создание сценариев, которые экспортируют, строят, а затем фиксируют (или запрашивают принятие). У меня есть такие скрипты для моего использования. Перед фиксацией я запускаю скрипт, он экспортирует мой wc и затем строит. ПРИМЕЧАНИЕ: это скопирует полный туалет! Так что это полезно при редких проверках, когда размер данных невелик (er).
• Рассмотрите возможность удаления бинарных файлов из репозитория (я не рекомендую этого, но это может быть самым разумным решением для повышения производительности снова).
• Помните, что при экспорте не создается туалет, что означает, что вы экономите 50% дискового пространства по сравнению с оформлением заказа. Таким образом, если вы реструктурируете так, что двоичные файлы и редко обновляемые элементы могут быть экспортированы вместо извлечения, это побудит большее количество людей «получить полную информацию», а не пытаться просмотреть некоторые из них.

Answer 4

Чтобы справиться с громоздким размером, я бы рассмотрел возможность разделения двоичных данных на другую ветвь (или даже полное удаление их для хранения в другом месте), отдельно от кода. Это должно как минимум ускорить процесс, особенно если данные меняются не часто.

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

Answer 5

Я был менеджером СКМ в аналогичной ситуации. У нас был проект с более чем 200K файлами (в основном код), у которого были некоторые из тех же проблем. Нашим решением было разделить репозиторий на две версии. Одна версия является версией для разработки, а другая - производственной версией. Мы залили версию для разработки последней и самой известной рабочей копией всего кода. Разработчики начали с этого и внесли изменения, зарегистрировались и вышли и т. Д. Как только они почувствовали, что все стало стабильно, администратор (в нашем случае менеджер сборки) объединил код и выполнил тестовую сборку, чтобы убедиться, что все работает правильно. Если все прошло, это было хорошо. Если этого не произойдет, администратор сборки выследит разработчика и сурово накажет его. В начале у нас были одни и те же проблемы, когда «Это работало на моем компьютере» и т. Д., Но вскоре они были решены благодаря избиениям и поркам .....

В определенные моменты код разработки (ВСЕ РАБОЧИЙ КОД !!!!) был объединен с производственным прогоном и передан заказчику.

Answer 6

Можно ли разбить проект на более мелкие проекты, которые можно подключить через какую-то систему плагинов?