Масштабируемый (полумиллион файлов) система управления версиями
Мы используем SVN для нашего управления версиями исходного кода и экспериментируем с помощью него для файлов неисходного кода.
Мы работаем с большим набором (300-500k) из коротких (1-4kB) текстовых файлов, которые будут обновлены регулярно и потребность к управлению версиями он. Мы пытались использовать SVN в режиме плоского файла, и он изо всех сил пытается обработать первую фиксацию (500k файлы, в которых зарегистрировались) взятие приблизительно 36 часов.
Ежедневно, нам нужна система, чтобы смочь обработать измененные файлы 10k на транзакцию фиксации в скором времени (<5 минут).
Мои вопросы:
- SVN правильное решение для моей цели. Начальная скорость кажется слишком медленной для практического применения.
- Если Да, там конкретная svn реализация сервера, которая быстра? (Мы в настоящее время используем значение по умолчанию гну/Linux svn клиент командной строки и сервер.)
- Если нет, каковы лучшие f/oss/commercial альтернативы
Спасибо
Редактирование 1: Мне нужно управление версиями, потому что несколько человек будут одновременно изменять те же файлы и будут делать руководство diff/merge/resolve-conflicts тем же самым способом, как программисты редактируют исходный код. Таким образом мне нужен центральный репозиторий, к которому люди могут зарегистрироваться в своей работе и проверить работу других. Рабочий процесс фактически идентичен рабочему процессу программирования за исключением того, что пользователи не являются программистами, и содержание файла не является исходным кодом.
Обновление 1: Оказывается, что основной проблемой было больше проблемы файловой системы, чем проблема SVN. Для SVN, фиксируя единственный каталог с полумиллионом новых файлов не закончился даже после 24 часов. При разделении того же через 500 папок, расположенных в 1x5x10x10, дерево с 1 000 файлов на папку закончилось во время фиксации 70 минут. Скорость фиксации отбрасывает значительно со временем для единственной папки с большим количеством файлов. Мерзавец кажется намного быстрее. Обновит с временами.
8 ответов
Подходит ли SVN? Пока вы не проверяете и не обновляете весь репозиторий, тогда да.
SVN плохо справляется с фиксацией очень большого количества файлов (особенно в Windows), поскольку все эти каталоги .svn записываются для обновления блокировки при работе с системой. Если у вас небольшое количество каталогов, вы этого не заметите, но затраченное время, кажется, увеличивается в геометрической прогрессии.
Однако после фиксации (по частям, возможно, каталог за каталогом) все становится намного быстрее. Обновления не занимают так много времени, и вы можете использовать функцию разреженной проверки (очень рекомендуется) для работы с разделами репозитория. Предполагая, что вам не нужно изменять тысячи файлов, вы обнаружите, что это работает достаточно хорошо.
Фиксация 10 000 файлов - опять же, все сразу не будет быстрым, но 1000 файлов десять раз в день будет намного более управляемым.
Так что попробуйте, как только у вас будут все файлы, и посмотрите, как это работает. Все это будет исправлено в версии 1.7, поскольку механизм рабочей копии изменен для удаления этих каталогов .svn (так что сохранять блокировки проще и намного быстрее).
git - лучший вариант. Вы можете зарегистрировать всю операционную систему (два гигабайта кода в нескольких сотнях тысяч файлов), и ее можно будет использовать, хотя начальная проверка займет довольно много времени, например, около 40 минут.
для таких коротких файлов я бы проверил использование базы данных вместо файловой системы.
для svn "режим плоского файла", означающий FSFS, я полагаю:
- убедитесь, что вы используете последнюю версию svn. В FSFS был добавлен шардинг в ~ 1.5 IIRC, который будет разницей между днем и ночью для файлов 500k. Определенная файловая система, которую вы запускаете, также будет иметь огромное влияние. (Даже не думайте об этом в NTFS.)
- Вы будете связаны операциями ввода-вывода с таким количеством файловых транзакций. SVN не очень эффективен с этим, так как файлы должны быть помещены в .svn / так же, как и реальные файлы.
git имеет намного лучшую производительность, чем svn, и вы должны хотя бы сравнить
Действительно ли вам нужна файловая система с дешевыми моментальными снимками, как ZFS? Вы можете настроить ее на сохранение состояния файловой системы каждые 5 минут, чтобы воспользоваться некоторым уровнем истории изменений.
Есть ли причина, по которой вам нужно фиксировать 10 тыс. Измененных файлов за одну фиксацию? Subversion будет масштабироваться намного лучше, если каждый пользователь сразу же вернет свой файл. Затем один раз в день вам нужно «публиковать» файлы, вы можете очень быстро пометить их и запустить опубликованную версию с помощью тега
По состоянию на июль 2008 года git-репозиторий ядра 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 отслеживает содержимое, а не файлы.
Я рекомендую Mercurial, поскольку он по-прежнему возглавляет git в отделе удобства использования (git был становится лучше, но, а).
BZR также сделал большой шаг вперед в удобстве использования.