Насколько хорошо современный VCS имеет дело с тысячами отдельных репозиториев или проектов?

Question

У нас есть своеобразная ситуация, когда у нас есть тысячи (20k +) отдельных небольших html-файлов, которые не связаны друг с другом. Мы делаем изменения, вероятно, от 10 до 100 с каждый день. Мы используем Visual Sourcesafe, который хорошо работает с этой моделью, но теперь мы хотим немного перейти к чему-то более современному. Я просто не знаю, глядя на то, что доступно, что может работать лучше всего, или если что-нибудь будет.

Используя что-то вроде Mercurial, хотим ли мы одного репо с одним проектом для каждого файла и всех проектов в одном репо? Или один репо с одним проектом и всеми файлами в этом проекте? Или это даже сработает? Или я так мало знаю обо всем этом, что мой вопрос даже не имеет смысла (вполне возможно)?

Answer 1

я так мало знаю обо всем этом, что мой вопрос даже не имеет смысла

Да, извините ...

• «Проект» неизвестно Субъект VCS (это объект другой предметной области), VCS имеет дело с «репозиториями» | «файлы в репозиториях»
• Все (возможно, больше всего) современные VCS не имеют строгих ограничений на количество файлов в хранилищах | количество репозиториев, которые один сервер (когда он нужен/не всегда /) может поддерживать - за исключением здравого смысла: 20 000 репозиториев могут быть трудными для управления, 20K файлов в одном репо может привести к ухудшению скорости в некоторых краях

Таким образом, вы можете | иметь на выбор любой модели хранения ваших объектов в хранилище (репозитории), просто

Оценить и взвесить все преимущества, недостатки и последствие использования каждой модели (учитывая экстремальные и промежуточные варианты)

Навскидку:

• Repo в файл означает много хранилищ на серер и рабочих каталоги локально, но ноль «сопутствующего ущерб» в любом рабочем процессе и ошибках
• Один гигантского репо означает, что все ограничения «глобального контекст» для много действий (глобальная ревизия на репо, неспособность к ветвлению | тег одного файла/кроме SVN /)
• Дерево каталогов с деревом (по любому правилу) с файлами в каждом контейнере внутри должно содержать + сохранить «карту местоположения» и принести дополнительные проблемы в случае файловых переименований (только представьте: A/a.html A/a1.html до, B/b.html C/c.html после - перемещен и правильно зарегистрирован в VCS по выбору - не большая головная боль, а «грабли» в лоб "вполне возможно в будущем)