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

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

Большая часть команды использует различные сторонние инструменты и библиотеки для разработки и для выпуска (обычно два - 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). Все элементы party должны находиться в папке ThirdParty, чтобы разработчикам не приходилось иметь несколько копий этих библиотек для каждого проекта.

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

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

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


branch code-organization mercurial
person Preet Sangha    schedule 14.08.2011    source источник
comment
просто спросил об этом при переполнении стека. Закрываю это   -  person Preet Sangha    schedule 15.08.2011
comment
Зачем спрашивать на ТАК? Это вроде не по теме там   -  person TheLQ    schedule 15.08.2011
comment
Что ж, это конкретный вопрос, но он тоже встречается во мнениях. Так что я как бы застрял   -  person Preet Sangha    schedule 15.08.2011
comment
@TheLQ - Это действительно вопрос SO, проверьте FAQ по P.SX: Если ваш вопрос касается инструментов программирования, задавайте вместо них Stack Overflow.   -  person Mark Booth    schedule 15.08.2011
comment
@Mark: Спасибо за это. Обязательно отвечу на вопросы в будущем.   -  person Preet Sangha    schedule 16.08.2011

Ответы (1)


arrow_upward
6
arrow_downward

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

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

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

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

ProductA/
         ProjectA/
         ProjectB/
         ThirdParty/
                    ThirdPartyC/

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

person Karl Bielefeldt    schedule 15.08.2011
comment
Спасибо, как вы предлагаете организовать продукт - person Preet Sangha; 15.08.2011
comment
Отлично. Если можно, просто уточнить. Скажем, я исправляю в Projects / ProjectA. Теперь я хочу нажать на productB, допустят ли подрепозитории слияние набора изменений? Есть ли особый синтаксис? - person Preet Sangha; 16.08.2011
comment
Вы должны помнить о некоторых особенностях синтаксиса. Слишком много, чтобы охватить здесь, поэтому вам действительно нужно прочитать документацию . Короче говоря, вы должны уделять дополнительное внимание загрузкам, потому что один продукт может быть еще не готов к обновлению до последней версии проекта, поэтому hg не выполняет это автоматически, пока не будет запрошено. - person Karl Bielefeldt; 16.08.2011
comment
@Preet - в основном ProductA управляет тем, как он использует вспомогательное репо ProjectA, поэтому, если ProductB обновляет ProjectA исправлением ошибки, ProductA получает его только тогда, когда вы специально обновляете ProductAs ProjectA - это позволяет вам управлять регрессионным тестированием для каждого продукта. Также обратите внимание, что нет необходимости в слиянии, просто обновите суб-репо и зафиксируйте новое состояние продукта. - person Mark Booth; 16.08.2011
comment
Это похоже на то, что мне нужно. @mark в дополнение к ссылкам Карла, не могли бы вы предложить дальнейшее чтение, пожалуйста? - person Preet Sangha; 17.08.2011
comment
Карл, не стесняйтесь редактировать эти комментарии в своем ответе. Таким образом, мы сможем убрать комментарии позже. - person Mark Booth; 17.08.2011
comment
@Preet - очевидным является Mercurial: The Definitive Guide Брайана О'Салливана, но это все еще не так » Кажется, есть раздел подрепо. Я бы также порекомендовал Mercurial Mailing Lists, особенно общий список рассылки и подрепо тег здесь, в StackOverflow. - person Mark Booth; 17.08.2011