Масштабируемая система управления версиями (полмиллиона файлов)

Мы используем SVN для нашего контроля версий исходного кода и экспериментируем с его использованием для файлов, не относящихся к исходному коду.

Мы работаем с большим набором (300-500 тыс.) коротких (1-4 кбайт) текстовых файлов, которые будут регулярно обновляться и должны управлять версией. Мы пытались использовать SVN в плоском режиме, и он изо всех сил пытается обработать первую фиксацию (500k файлов, проверенных), занимая около 36 часов.

Ежедневно нам нужно, чтобы система могла обрабатывать 10k измененных файлов за транзакцию за транзакцию за короткое время (< 5 минут).

Мои вопросы:

Является ли SVN правильным решением для моей цели. Начальная скорость кажется слишком медленной для практического использования.
Если да, есть ли какая-то конкретная реализация сервера svn, которая быстрая? (В настоящее время мы используем сервер svn по умолчанию gnu/linux и клиент командной строки.)
Если нет, какие лучшие f/oss/коммерческие альтернативы

Спасибо

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

Обновление 1. Оказывается, основная проблема была связана с проблемой файловой системы, чем проблема SVN. Для SVN передача одного каталога с полмиллионами новых файлов не завершалась даже через 24 часа. Разделение одного и того же на 500 папок, расположенных в дереве 1x5x10x10 с 1000 файлами на папку, привело к времени фиксации 70 минут. Скорость фиксации значительно снижается с течением времени для одной папки с большим количеством файлов. Git кажется намного быстрее. Будет обновляться со временем.

Ответ 1

подходит SVN? Пока вы не проверяете или не обновляете весь репозиторий, тогда да.

Совместимость с SVN довольно велика при использовании большого количества файлов (особенно в Windows), поскольку все эти .svn-каталоги записываются для обновления блокировки при работе в системе. Если у вас небольшое количество каталогов, вы не заметите, но время, которое, кажется, увеличивается экспоненциально.

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

Делая 10 000 файлов - снова, все сразу не будет быстрым, но 1000 файлов десять раз в день будут намного более управляемыми.

Итак, попробуйте, как только у вас есть все файлы, и посмотрите, как это работает. Все это будет исправлено в 1.7, так как механизм рабочей копии изменен для удаления этих .svn-каталогов (так что сохранение блокировок проще и намного быстрее).

Ответ 2

По состоянию на июль 2008 года в реестре Linux git было около 260 000 файлов. (2.6.26)

http://linuxator.wordpress.com/2008/07/22/5-things-you-didnt-know-about-linux-kernel-code-metrics/

В этом количестве файлов разработчики ядра все еще говорят, что git работает очень быстро. Я не понимаю, почему это было бы медленнее на 500 000 файлов. git отслеживает содержимое, а не файлы.

Ответ 3

для таких коротких файлов, я бы проверял использование базы данных вместо файловой системы.

Ответ 4

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

Ответ 5

для svn "режим плоского файла", что означает FSFS, я полагаю:
- убедитесь, что вы используете последнюю версию svn. FSFS добавила в 1.5 1.5RC, что будет ночной/дневной разницей в файлах 500K. Определенная файловая система, которую вы запускаете, также будет иметь огромный эффект. (Даже не думайте об этом в NTFS.)
- Вы будете связаны с IO-протоколом с такими файловыми транзакциями. SVN не очень эффективен с этим, имея файлы stat в .svn/, а также реальные файлы.
git имеет более высокую производительность, чем svn, и вы обязаны сделать это для себя, чтобы хотя бы сравнить

Ответ 6

Я рекомендую Mercurial, поскольку он все еще ведет git в отдел юзабилити (git стал лучше, но, э-э).

bzr также сделал прыжки вперед в юзабилити.

Ответ 7

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

Ответ 8

Есть ли какая-то причина, по которой вам необходимо зафиксировать 10 k измененных файлов на одно коммит? Subversion будет масштабироваться намного лучше, если каждый пользователь сразу проверит его/ее собственный файл. Затем один раз в день вам нужно "публиковать" файлы, вы можете быстро их пометить и запустить опубликованную версию из тега