Распределенное управление версиями для ОГРОМНЫХ проектов - возможно ли это?
Абсолютно! Как вы знаете, Linux массивный и использует Git. Mercurial используется также для некоторых крупных проектов , таких как Python, Mozilla, OpenSolaris и Java.
Мы сейчас очень довольны SVN, но урок Джоэла заинтриговал меня. Так что мне было интересно - будет ли это возможно и в нашей ситуации?
Да. И если вы довольны Subversion сейчас, вы, вероятно, не слишком много разветвляетесь и объединяетесь!
Дело в том, что наше хранилище SVN ОГРОМНО. [...] Существует более 68 000 ревизий (наборов изменений), сам источник занимает более 100 МБ
Как отмечали другие, на самом деле это не так уж много по сравнению со многими существующими проектами.
Тогда проблема проста - клону всего хранилища, вероятно, потребовались бы годы, и он занимал бы гораздо больше места на диске, который удаленно исправен.
И Git, и Mercurial очень эффективны в управлении хранилищем, и их репозитории занимают гораздо меньше места, чем эквивалентные репозитории Subversion (в которых конвертировано несколько). И как только у вас есть начальная проверка, вы только толкаете дельты вокруг, что очень быстро . Они оба значительно быстрее в большинстве операций. Первоначальный клон - единовременная стоимость, поэтому не имеет значения, сколько времени это займет (и, держу пари, вы будете удивлены!).
И поскольку суть распределенного контроля версий заключается в том, чтобы иметь столько репозиториев, сколько необходимо, я начинаю сомневаться.
Дисковое пространство дешево. Производительность разработчиков важнее. Так что, если репо занимает 1 ГБ? Если вы можете работать умнее, оно того стоит.
Как Mercurial (или любой другой распределенный контроль версий) справляется с этим? Или они непригодны для таких огромных проектов?
Вероятно, стоит прочитать о том, как проекты, использующие Mercurial , такие как Mozilla, управляли процессом преобразования. Большинство из них имеют несколько репозиториев, каждый из которых содержит основные компоненты. Mercurial и Git также поддерживают вложенные репозитории. И есть инструменты для управления процессом конвертации - Mercurial имеет встроенную поддержку для импорта из большинства других систем .
Добавлено: Для пояснения - все это один монолитный зверь проекта, который компилируется в один .EXE и не может быть разделен.
Это облегчает , так как вам нужен только один репозиторий.
Добавлено 2: Вторая мысль - репозиторий ядра Linux использует git и, вероятно, на порядок или два больше моего. Так как они заставляют это работать?
Git предназначен для сырой скорости. Формат на диске, проводной протокол, алгоритмы в памяти сильно оптимизированы. И они разработали сложные рабочие процессы, в которых патчи передаются от отдельных разработчиков, вплоть до сопровождающих подсистем, вплоть до лейтенантов и, в конечном итоге, до Линуса. Одна из лучших особенностей DVCS заключается в том, что они настолько гибки, что допускают все виды рабочих процессов.
Предлагаю вам прочитать превосходную книгу по Mercurial Брайана О'Салливана, которая поможет вам быстро набрать скорость. Скачайте Mercurial и поработайте с примерами, поиграйте с ним в некоторых репозиториях, чтобы почувствовать его.
Затем запустите команду convert, чтобы импортировать существующий исходный репозиторий. Затем попробуйте внести некоторые локальные изменения, коммиты, ветки, просмотреть журналы, использовать встроенный веб-сервер и так далее. Затем клонируйте его в другую коробку и внесите изменения. Определите время наиболее распространенных операций и посмотрите, как они сравниваются. Вы можете сделать полную оценку бесплатно, но только в свое время.