Синхронизировать 2 ртутных репозитория - PullRequest
2 голосов
/ 12 октября 2011

Скажем, у нас есть следующие настройки разработки:

  • Команда 1 в локации A с центральным ртутным репо, где вся работа этой команды выталкивается
  • Команда 2 в локации B (на полпути по всему миру из команды 1 и со слабым интернет-соединением) со своим собственным центральным ртутным репо, где вся работа этих команд продвигается

Как я могу безопасно синхронизировать центральные репозитории из команд 1 и 2без проблем со слияниями / несколькими головками и т. д .?

Я бы предположил, что запланированный push / pull из одного из хранилищ (например, в расположении A) в / из другого справится с этим, но какмне разрешить ситуации, когда задействовано несколько голов?

Например: команда 1 выдвигает коммит, в то же время команда 2 также проталкивает.Теперь, когда репо в локации A вытягивает изменения, он получает несколько голов.Что мне теперь делать?Будет ли решение в данном случае позволить разработчику из группы 1 (в местоположении A) объединить головы и отодвинуть их обратно к своему центральному репо, чтобы следующий запланированный перенос в местоположение B вызвал объединение?Это может привести к проблемам, если команда 2 уже внесла другие изменения в свой центральный репозиторий, верно?

Есть ли какое-либо иное решение для такого рода проблем?

Чего я хочу избежать, так это того, что команда 2 должна дождаться стабилизации своего интернет-соединения, чтобы вернуть свои изменения команде 1 ...

Я был бы рад любому видупомогите здесь; -)

Ответы [ 3 ]

2 голосов
/ 12 октября 2011

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

* 1003 т.е. *

  • SyncMaster из Team2 создает собственное репо с двумя URL-адресами в разделе [paths] hgrc: RepoTeam1 и RepoTeam2
  • Он тянет из обоих репо, объединяет головы (R2 с R1) из всех существующих ветвей (если они существуют)
  • результаты принудительного слияния с R1 и R2

Разделение на уровне филиала между репозиториями может помочь слияниям упростить его работу

1 голос
/ 12 октября 2011

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

0 голосов
/ 12 октября 2011

Ну, основное правило: никогда не вставляйте новые головы в удаленный репозиторий. Потому что, если вы сделаете это, вы будете создавать головы, которые внезапно появятся в хранилище другой команды, что они должны объединиться, и это сбивает с толку. Mercurial будет жаловаться на это, если вы попытаетесь это сделать, если вы не укажете параметр --force.

Но кроме этого это довольно стандартный тариф; Вы назначаете одного или нескольких лиц, ответственных за слияние двух репозиториев (ежедневно или около того), затем извлекаете все изменения из обеих веток, объединяете две головы, а затем отправляете результат обратно в оба репозитория, как это должен делать любой член команды. , Если что-то выдвигается во время слияния, вам нужно выполнить еще одно слияние (надеюсь, без конфликтов), прежде чем нажать.

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

...