Ртутные филиалы с SUBREPOS

Question

Я пытаюсь определить, как люди используют «хранилища веток», в то же время используя подпункты.

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

/Main
    - A
    - B
    - C
    MainSolution.sln

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

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

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

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

На данный момент я просто пытаюсь понять, КАК люди работают над сложным проектом и используют вложенные репозитории с репозиториями веток.Есть мысли?

Answer 1

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

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

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

Answer 2

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

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