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

Question

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

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

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

Мои вопросы:

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

Спасибо

---

Редактировать 1 : мне нужен контроль версий, потому что несколько человек будут одновременно модифицировать одни и те же файлы и будут вручную выполнять конфликты diff / merge / resolf точно так же, как программисты редактируют исходный код. Поэтому мне нужен центральный репозиторий, в который люди могут проверить свою работу и проверить работу других. Рабочий процесс практически идентичен рабочему процессу программирования, за исключением того, что пользователи не являются программистами, а содержимое файла не является исходным кодом.

---

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

Answer 1

По состоянию на июль 2008 года в git repo ядра Linux было около 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 отслеживает содержимое, а не файлы.

Answer 2

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

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

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

Передача 10000 файлов - опять же, все сразу не будет быстрым, но 1000 файлов десять раз в день будет намного более управляемым.

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

Answer 3

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

Answer 4

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

BZR также сделал скачок вперед в удобстве использования.

Answer 5

1. для svn "плоский файл", что означает FSFS, я полагаю:

   • убедитесь, что вы используете последнюю версию SVN. В FSFS добавлен шардинг в ~ 1.5 IIRC, что будет разницей ночь / день при файлах 500k. Конкретная файловая система, которую вы запускаете, также будет иметь огромный эффект. (Даже не думайте об этом в NTFS.)
   • Вы будете связаны IO с таким количеством файловых транзакций. SVN не очень эффективно справляется с этим, так как ему нужно регистрировать файлы в формате .svn /, а также реальные файлы.

2. git имеет лучшую производительность, чем svn, и вы обязаны по крайней мере сравнить

Answer 6

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

Answer 7

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

Answer 8

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