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

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

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

/Main
    - A
    - B
    - C
    MainSolution.sln

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

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

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

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

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


person Andrew    schedule 12.07.2010    source источник


Ответы (2)


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

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

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

person Bryn Keller    schedule 06.05.2012

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

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

person Mark Borgerding    schedule 16.07.2010
comment
Две вещи. Когда вы говорите, что именованная ветка не будет получена, если разработчик не попросит об этом, вы имеете в виду, что рабочая копия разработчика не будет изменена, пока эта ветка не будет извлечена, или вы имеете в виду что-то еще? Насколько я понимаю, все ветки выталкиваются / вытягиваются автоматически. Кроме того, основной вопрос заключается не в том, следует ли использовать именованные ветки или репозитории веток, а в том, как использовать репозитории веток, когда также используются подрепозитории. Но спасибо за ответ! - person Andrew; 18.07.2010
comment
Именованные ветки будут извлечены с помощью команды hg pull, но рабочие каталоги разработчиков не будут обновлены до другой ветки без их явного обновления, например. hg up -r ‹branchname›. Мне кажется, что лучший путь - это тот, который сложнее всего испортить разработчику. Проблема джинна из бутылки, которая возникает, когда отдельные репозитории веток случайно сжимаются вместе, заставляет меня думать, что именованные ветки в одном репо предпочтительнее. YMMV. По общему признанию, я, вероятно, упустил некоторые дополнительные сложности, связанные с подрепо. Удачи! - person Mark Borgerding; 19.07.2010
comment
Может ли кто-нибудь пролить свет на сценарий «джин из бутылки», который описывает здесь @MarkB? - person Giscard Biamby; 09.10.2012