Mercurial: Granular Repositories против больших репозиториев и общих сторонних инструментов в управлении версиями

Question

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

Большая часть команды использует различные сторонние инструменты и библиотеки для dev и для выпуска (наиболее распространенными являются XUnit для dev и 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/ и ряд статей, но я все еще не уверен, как организовать.

Answer 1

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

  products/ProductA/
           ProductB/
           ProductC/   
  projects/ProjectA/
           ProjectB/
           ProjectC/   
thirdparty/ThirdPartyA/
           ThirdPartyB/
           ThirdPartyC/

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

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

ProductA/
         ProjectA/
         ProjectB/
         ThirdParty/
                    ThirdPartyC/

Это выглядит иначе, чем на центральном сервере, потому что там у вас нет рабочих деревьев, только указатели на подпункты.