Mercurial: отдельные репозитории против больших репозиториев и совместно используемых сторонних инструментов в системе контроля версий

Этот вопрос был перенесен из Software Engineering Stack Exchange, потому что на него можно ответить в Stack Overflow. Мигрировал 8 лет назад .

Сценарий: Различные продукты составляли комбинации из более мелких проектов. Несколько разных версий каждого продукта в разработке, выпуске и обслуживании (ошибки / исправления / второстепенные выпуски).

Большая часть команды использует различные сторонние инструменты и библиотеки для разработки и для выпуска (обычно два - XUnit для разработчиков и AutoMapper в продукте). Они фанаты версий, управляющих этими инструментами / библиотеками, где это имеет смысл.

Кажется, я не могу понять, как лучше всего организовать структуру в Mercurial. В центральном стиле SVN я бы организовал, имея сторонние инструменты в качестве их собственных проектов, а затем создавая небольшие сборки для проектов, которые будут захватывать выходные данные других проектов, а затем проект выпуска, который будет построен из построенные проекты. Все будет в иерархии,

(ветвь разработчика)

Root/dev/ProjectX/
Root/dev/ProjectY/
Root/dev/ThirdParty/XXX -- could be a 3rd party lib
Root/dev/ThirdParty/YYY -- could be a 3rd party lib

(ветка 1)

Root/release1/ProjectX/
Root/release1/ProjectY/
Root/release1/ThirdParty/XXX 
Root/release1/ThirdParty/YYY

(ветка 2)

Root/release2/ProjectX/
Root/release3/ProjectY/
Root/release2/ThirdParty/XXX 
Root/release2/ThirdParty/YYY

и т. Д.

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

У меня такой вопрос:

Если они реализуют mercurial, должны реализовать аналогичную стратегию (большое репо) и клонировать / ветвление здесь, или они должны разбить репозиторий, скажем, на уровне проекта и клонировать / ветвить их. В последнем случае будет ли у них ветка продукта / версии / репо? Я знаю, что они предпочли бы распределенную модель, если она будет работать лучше в долгосрочной перспективе, даже если поначалу сложно изучить новый рабочий процесс.

Я прочитал http://nvie.com/posts/a-successful-git-branching-model/ и ряд статей, но все еще не уверен, как это организовать.

задан Preet Sangha 14 August 2011 в 21:56

0 ответов

Другие вопросы по тегам:

mercurial code-organization branch

Mercurial: отдельные репозитории против больших репозиториев и совместно используемых сторонних инструментов в системе контроля версий

0 ответов

Похожие вопросы: