Mercurial: как синхронизировать нескольких людей с намерением вытащить / объединить / протолкнуть из / с / в центральный репозиторий?

Question

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

Допустим, команда A и команда B находятся в состоянии и намерены вытащить / объединить / перенести в централизованный репозиторий.

A pulls.
B pulls.
A merges
B merges.
B pushes. => A has to pull and merge again before pushing!

Есть ли (возможно, технический) способ избежать этого конфликта? Может быть, какой-то замок? Или с этим нужно жить?:-)

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

Answer 1

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

В вашем примере, если вы измените B merges в B rebases, тогда А все равно придется снова тянуть и сливаться, но будет меньше безымянных ветвей, чтобы попытаться следовать.

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

Но еще раз хочу подчеркнуть, что этот "проблемный" сценарий проблематичен только из-за неудобств для разработчика. Это на самом деле рабочий процесс DVCS, как Mercurial, предназначены для обработки. "Стандартный" рабочий процесс всегда заключался в том, чтобы "вытягивать и объединять / перебазировать" перед нажатием - отсюда и предупреждение Mercurial о создании новых головок, если вы пытаетесь протолкнуть без слияния.

Answer 2

Обычно вы можете жить с этим, ИМХО это здравый смысл работать таким образом.

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

• A и b создают ветки, оставляя нетронутыми tip/default/master.
• Оба могут зафиксировать и отправить свои изменения, но это создаст ветви в центральном хранилище.
  • Это может привести к серьезным конфликтам, если присвоение имен совпадает, может помочь соглашение об именах.
• Кто-то, в основном инженер по сборке или системный архитектор, должен объединить изменения из разных веток.

Если оба работают над разными функциями на одном и том же компоненте, это может быть хорошим способом сделать это.

Я бы порекомендовал вам прочитать эту главу http://hgbook.red-bean.com/read/managing-releases-and-branchy-development.html.