Есть ли рабочий процесс в Mercurial, который позволяет многим людям работать над слиянием (интеграцией) вместе? - PullRequest
2 голосов
/ 07 ноября 2011

Скажем, у вас есть две «основные» ветви, которые долгое время разрабатывались отдельно, когда вы собираетесь объединить их, вы хотите разделить работу между всеми вашими разработчиками.

Например, вы хотите, чтобы ваш программист на C # сливал C #, а ваш программист на TSQL объединяет хранимые процессы.

Я вымываю всех разработчиков, чтобы увидеть, что еще нужно объединить, имогут ли Mercurial помочь с этим?

[Я предполагаю, что после того, как им сказали, что они должны выполнить слияние, осталось более одного разработчика!]


Как меня спросили в комментариях, я думаю, что мы попали в это состояние ...

Если я правильно понимаю историю отЯ присоеденился.Один крупный клиент пришел и сказал: «Мы заплатим вам много денег, если вы добавите x, y и z к вашему продукту , но мы не хотим рисковать, что вы дадите нам какие-либо изменения.что мы напрямую не извлекаем из этого пользу (они даже пригласили некоторых своих программистов в команду, чтобы убедиться, что они не получают других изменений).

За те несколько лет, что продолжалась работа для этого крупного клиента, другие клиенты заявили, что не купят продукт, если мы не добавим a, b и c ».

Крупный покупатель не желал платить за x, y и z, которые должны быть выполнены каким-либо образом (или чтобы его можно было отключить), который не сломал бы продукт для других клиентов, которые использовали его вПо-разному, и большинство программистов понимали, что система продается крупному клиенту, поэтому не было никакой человеческой силы (до сих пор), чтобы исправить x, y и z, чтобы их можно было передать всем нашим клиентам.

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

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

Надеюсь, история не повторится, но программистам очень трудно сказать НЕТ в городе, где не так много компаний-разработчиков программного обеспечения.Сейчас мы переходим на Mercurial, и я хотел бы знать, как бы мы справились с Mercurial, если бы история повторилась!(Я также начинаю сомневаться в том, что Mercurial - это все, что сделано для сравнения с Perforce)

Ответы [ 3 ]

3 голосов
/ 08 ноября 2011

Да, для этого сценария есть рабочий процесс.

Планируйте заранее, узнайте, прежде чем ветвь, в какую ветвь в последующую ветку, и убедитесь, что вы регулярно в нее включаетесь.Пример: у вас есть ветвь по умолчанию, и вы создаете ветвь объектов, которая в какой-то момент должна вернуться к стандартной.Периодически объединяйте по умолчанию с вашей веткой функций, чтобы убедиться, что она актуальна со всеми изменениями по умолчанию.Это создает меньшие конфликты по пути.В конце вы делаете последнее слияние с вашей веткой объектов, исправляете любые конфликты, а затем объединяете их по умолчанию.

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

1 голос
/ 22 марта 2012

Одним разумным подходом может быть использование hg convert для разбиения репозитория на более мелкие части (часть C #, часть TSQL и т. Д.), Выполнение слияния с этими более мелкими и более детализированными репозиториями и (если важно сохранить исходный репозиторий)просто зафиксируйте результаты обратно в исходное хранилище, как только они будут готовы.

1 голос
/ 08 ноября 2011

Вероятно, самое близкое к тому, чего вы хотите достичь - это объединение одного набора изменений за раз. Это позволяет избежать слияния большого взрыва, выполняя множество маленьких слияний. Если у вас есть четкое разделение между вашими разработчиками C # и TSQL (что звучит так же, как и вы), тогда вы сможете распределить каждый набор изменений в нужной группе.

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

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

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...