Репозитории Mercurial Branch с SUBREPOS

Я пытаюсь определить, как люди используют "репозитории веток", а также используют subrepos.

Скажем, у меня есть репо Main, содержащий файл решения (.NET) и заполненный субреподами A, B, C:

/Main
    - A
    - B
    - C
    MainSolution.sln

A, B и C, будучи разделяемыми между другими "Основными" репозиториями, очень тесно интегрированы в Основной проект. Таким образом, основная функция Main repo потребует изменений в subrepos (т.е. Они являются совместно используемыми библиотеками, но очень активно развиваются).

Теперь пришло время добавить функцию. Эта функция слишком велика для того, чтобы один человек мог справиться, и, таким образом, код нужно будет нажать на центральное репо, чтобы другие могли помочь. Нам также нужно будет вернуться к последнему "стабильному" коду до начала разработки функции в случае необходимости исправления. На мой взгляд, у меня есть два варианта: (1) создать именованную ветвь в Main repo или (2) создать новый клон Main. Поскольку есть subrepos, оба этих параметра имеют типичные последствия.

Вариант 1) Создание именованной ветки, я полагаю, допускает модификацию подпопоста, которое должно быть зафиксировано/нажато, но будут затронуты только другие люди, которые также обновили эту ветвь в своем клоне Main, поскольку .hgsubstate файл отслеживается. Тем не менее, subrepos получит новую главу, и, таким образом, возможно (возможно) экспериментальная функция попадет в центральное репо. Я правильно понимаю это?

Вариант 2) Существует множество сторонников "не использовать названные ветки, использовать" реестры веток ", которые являются буквально клонами основного репо, но называются по-разному и существующими на центральном сервере. Это немного привлекает меня, поскольку, похоже, что-то разделяет (и, таким образом, отстраняется от катастрофы, как коллеги - и я!) Все еще изучают Mercurial). Но этот рабочий процесс кажется полностью разрушенным, когда задействованы субрепозитории, так как создание клона Main repo не создает новые, разделенные клоны подпозиции. Это новый клон, но он все еще указывает на тот же subrepos, и, таким образом, изменения, внесенные в них, вернутся обратно в subrepos! Я понимаю, что это по дизайну, и это одна из самых классных вещей (для меня) о Mercurial. Но как люди используют этот рабочий процесс репозитория ветки с субрепозиториями? Совершенно невообразимо, что для каждой функции/эксперимента/версии/независимо, я собираюсь создать новый клон (на центральном сервере) Main repo, и создать клоны (на центральном сервере) subrepos, AND измените все пути .hgrc/.hgsub, чтобы указать на соответствующие центральные репозитории.

В этот момент я просто пытаюсь понять, КАК люди работают над сложным проектом и используют subrepos с репозиториями веток. Любые мысли?

Ответ 1

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

Вы также должны знать, что субрепозитории не должны быть разделены между несколькими основными репозиториями в том, как вы описываете. Фактически вы можете иметь субрепозитории, хранящиеся в основном репозитории (в отличие от того, чтобы они были на том же уровне, что и основные репозитории, или хранились в каком-либо другом месте), что сделало бы их уникальными для каждого основного репозитория, за исключением того, что вы можете вытащите из подрепозиции в другие основные репозитории, когда вы хотите поделиться этими изменениями. Так я обычно это делаю.

К сожалению, многое из этого трудно объяснить без доски, поэтому, пожалуйста, дайте мне знать, если это не ясно.

Ответ 2

Я предпочитаю названные ветки для функций, которые, скорее всего, в конечном итоге будут объединены в ветвь по умолчанию. Гораздо проще переключаться между ветвями, чем коммутатор-репозиторий.

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