Большой 66GiB унаследованный репозиторий CVS - это хорошая идея перейти на GIT или Mercurial?

В Git вы можете использовать команду git subtree для «вырезания» подкаталогов, которые вы можете передать своим субподрядчикам, а затем легко реинтегрировать их изменения в свою основную ветку. Вы также можете периодически предоставлять им обновления, если вам нужно. Команда git subtree была изначально надстройкой, но была перенесена в каталог contrib официального дистрибутива Git.

Можно ограничить объем истории, которую вы включаете в репозиторий, который вы передаете внешнему пользователю.

Однако я ожидаю, что вас больше всего беспокоит переход на DVCS с таким большим начальным репо. Git сжимает ваше репо, так что после завершения его вряд ли будет 66 ГБ, но он все равно будет довольно громоздким (вероятно, порядка 10 ГБ, в зависимости от того, что вы там сохранили). Если вы не считаете это проблемой, дерзайте.

_{Я ограничился ответами на Git, потому что я больше знаком с Git, чем с Mercurial.}

66 ГБ - это много. Однако известно, что CVS не очень эффективно хранит данные. Git, безусловно, подойдет вам, но вам придется разделить свой проект на несколько меньших репозиториев git. Для большинства проектов не очень сложно разделить функциональность на несколько автономных подпроектов (часто это подкаталоги). Обычно вы хотите ограничить размер любого репозитория git в среднем менее 1-2 ГБ и, конечно, не должен превышать 5-10 ГБ. Однако имейте в виду, что git исключительно хорош в сжатии своих метаданных (если вы время от времени запускаете git gc).

Теперь, когда вы разделили свой проект на несколько подпроектов («несколько» - относительный термин - в Android их более 300), вам нужно придумать способ, как снова «склеить» их вместе в согласованную структуру каталогов.

Для этого есть 2 распространенных подхода:

1. Использование инструмента repo, разработанного проектом Android. Он включает в себя создание небольшого репозитория git, содержащего только один XML-файл (называемый манифестом), который отслеживает, где ваши подпроекты извлекаются и как они склеиваются. Это действительно хорошо работает в Linux и Mac, но, к сожалению, не поддерживает Windows (repo требует поддержки символических ссылок ОС).
2. Используя git submodule's. Создайте один репозиторий git без каких-либо реальных файлов и добавьте все свои исходные подпроекты в этот репозиторий как подмодули. В некотором смысле репозиторий super git играет, по сути, ту же роль, что и манифест репозитория Android. Преимущество такого подхода в том, что он поддерживается любой ОС, в том числе Windows.

Теперь, если вы хотите поделиться только небольшими частями своего гигантского проекта, вы можете сделать это, поделившись любым подмодулем / подпроектом напрямую с вашими партнерами в качестве стандартного репозитория git.

На самом деле, чтобы было удобнее, я настоятельно рекомендую установить Gerrit - реализацию сервера git в Java, который также является чрезвычайно мощным механизмом проверки кода (также используется в проекте Android). Функция обзора кода Gerrit является полностью необязательной (вам не обязательно использовать ее, если вы этого не хотите), но вам наверняка понравится унифицированная аутентификация пользователя Gerrit, управление ключами ssh и возможность контролировать права доступа для каждого репозитория git. Это делает его очень удобным для передачи третьим сторонам - вы просто предоставляете им доступ к небольшим частям с помощью Gerrit, и все готово.

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

У нас есть очень крупное унаследованное репо CVS (66 ГБ) за последние десять лет, и оно продолжает расти. Теперь у нас есть несколько субподрядных компаний, которым нужно работать над некоторыми модулями и филиалами.

Нам нужно создать для них несколько веток и отправить им эти ветки. Также нам нужно время от времени объединять их изменения в наши основные ветки.

Похоже, вы хотите перейти только для субподрядчиков, а не для всех остальных. Я настоятельно рекомендую вам этого не делать. Либо обращайте всех, либо никого. Запуск смешанной системы - огромная боль, особенно когда дело доходит до получения изменений от людей в DVCS.

Наша забота:

• мы не можем отдать им репо полностью, в основном речь идет о безопасности.

У вас есть несколько модулей в вашем репозитории CVS, но вы не можете предоставить им все модули, или вы хотите ограничить историю, к которой они имеют доступ?

DVCS работают намного лучше, когда модули хранятся как отдельные репозитории, а не как несколько модулей в одном репозитории *. Для этого есть много причин, но в основном это так, чтобы изменения в разных модулях не вызывали ненужных слияний.

(* как и CVCS, но обычно создавать новый модуль так сложно, что люди делают это только один раз. Я подозреваю, что у вас не было бы 66 ГБ, если бы он был разделен.)

Итак, если вы все же конвертируете, вы хотите разделить модули. Это позволит вам совместно использовать одни модули, а другие нет. Я знаю, что Mercurial может создать репо из пути, установленного в многомодульном репо во время преобразования. Я ожидаю, что Git имеет аналогичные возможности.

• нам нужно отправить им некоторую информацию из истории, а не только версию кода HEAD.

Это почти диктует DVCS. Это определяющий атрибут.

• мы все еще занимаемся разработкой, поэтому время от времени нам нужно присылать им набор изменений.

... и поэтому вы должны использовать тот же инструмент VC, что и они. В противном случае вы потратите все свое время на преобразование ревизий между системами.

GIT и Mercurial - хороший выбор для перехода с CVS? Может ли GIT / Mercurial удовлетворить наши потребности?

Да и Да, но это не кнопочный переход. Это требует планирования, приверженности и образования.

РЕДАКТИРОВАТЬ: Я думаю, что нам действительно нужен централизованный контроль версий с функцией нескольких сайтов, с возможностью создания внешнего репо на основе части центрального репо. И можно легко объединить сайты.

Централизованная, но распределенная система контроля версий. Вас понял!

Наконец, не путайте централизованную / распределенную практику разработки с централизованными / распределенными инструментами. Совершенно разумно работать в централизованной модели разработки с распределенной VCS.

Я позволю другим авторам ответить на вопросы о поддереве и подистории, потому что я не так хорошо знаком с этим. Однако я могу сказать вам кое-что о размере репо. Во-первых, ваше репозиторий git, скорее всего, будет намного меньше, чем ваша CVS (я предполагаю, что это будет между десятой и половиной текущих 66 ГБ).

Во-вторых, да, если вы поместите все репозиторий CVS в один репозиторий git, тогда ваши внутренние разработчики будут иметь копию всего репозитория на своих индивидуальных компьютерах. Репозиторий git, с которым я работаю ежедневно, составляет 12 ГБ и не вызывает никаких реальных проблем. Предполагая, что ваше репо велико, потому что ваша рабочая копия велика, на самом деле это значительно экономит время, когда вы хотите перемещаться между ветвями, потому что вы не загружаете так много файлов по сети. Для нас репозиторий git размером 12 ГБ не так уж и важен, потому что моя текущая рабочая копия (с объектами сборки для большинства целей) - это дополнительные 37 ГБ поверх самого репозитория git. В репозитории такого размера команды git работают намного быстрее, чем у Subversion.

Так что обязательно прочтите, что все говорят о поддеревьях, модулях и т. Д., Но будьте уверены, что вы, вероятно, можете просто импортировать все это, если вам нужно.