VersionControl для огромной кодовой базы

Кодовая база нашего проекта превышает 9 ГБ. В основном файлы Cobol, Pro * Cobol и Java вместе с другими файлами конфигурации. В настоящее время мы используем SVN для управления им, и во время интегрированных проверок и сборок производительность SVN плохая. Например, для проверки полных источников требуется более 4 часов, а если мы зафиксируем, скажем, 12 или более файлов, потребуется около 30 минут. Оцените предложения о том, как настроить SVN или любой альтернативный элемент управления версиями с открытым исходным кодом для обработки такого объема кодовой базы. Спасибо

-РамВенкат


svn
person RamVenkat    schedule 09.08.2010    source источник
comment
Пожалуйста, добавьте дополнительную информацию о среде, в которой вы используете SVN на платформе, типе svn-сервера, подключении .... Кроме того, этот вопрос может быть лучше на serverfault.com. Голосование за миграцию туда.   -  person Pekka    schedule 09.08.2010
comment
Также см. stackoverflow.com/questions/610734 /   -  person Pekka    schedule 09.08.2010
comment
Кто голосует за то, чтобы закрыть это? Смешной.   -  person Dave Markle    schedule 09.08.2010
comment
Насколько велика ваша рабочая копия после оформления заказа? Это больше похоже на проблему с вашей установкой и т. Д. Вы действительно проверяете только транк, тег или конкретную ветку ..   -  person khmarbaise    schedule 09.08.2010
comment
@ Дэйв: Похоже, сейчас голосуют за переход.   -  person Brian Gideon    schedule 09.08.2010
comment
@ Брайан: Все еще хромой. Это актуальный вопрос для разработчиков.   -  person Dave Markle    schedule 09.08.2010
comment
@ Дэйв: Согласен. Вот почему я поддержал ваш комментарий.   -  person Brian Gideon    schedule 09.08.2010
comment
Насколько велики ваши отдельные файлы, которые вы фиксируете или извлекаете?   -  person Konrad    schedule 09.08.2010

Ответы (2)


arrow_upward
2
arrow_downward

Возможно, ваша сеть или сервер не так хороши, как вы думаете. У меня есть репозиторий на 300 000 ревизий, который составляет 12 Гб (когда я смотрел в последний раз) (на самом деле, я не знаю, сколько это получилось, если проверять локально!), Работающее на недостаточно мощной виртуальной машине. Я бы не ожидал, что какой-либо SCM, распределенный или централизованный, получит новую копию всего этого за пару минут.

С другой стороны, 4 часа просто нарушены, а 30 минут проверок - что-то еще плохо для вас. Вам нужно сначала найти это, иначе переход на git все равно не будет работать. Посмотрите на использование процессора и памяти на сервере, посмотрите на производительность сети.

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

person gbjbaanb    schedule 05.02.2011

arrow_upward
1
arrow_downward

Короткий ответ, на самом деле всего одно слово: git. Или, если быть не таким прямолинейным: «Почему бы тебе не попробовать и не оценить git?» см. http://git-scm.com/

Существуют инструменты для перехода с svn на git, которые должны упростить вам начало тестирования. посмотрите: http://www.jonmaddox.com/2008/03/05/cleanly-migrate-your-subversion-repository-to-a-git-repository/

person Daniel Wedlund    schedule 09.08.2010