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

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

7 голосов
/ 15 августа 2011

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

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

1 Ответ

6 голосов
/ 15 августа 2011

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

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

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

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

ProductA/
         ProjectA/
         ProjectB/
         ThirdParty/
                    ThirdPartyC/

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

...