Автономная синхронизация локально-центральных хранилищ Mercurial

Question

У нас есть две разные команды, каждая в своем местоположении, работающая с Mercurial, у каждого местоположения есть эталонный репозиторий. Каждое местоположение имеет доступ к корпоративной сети, но две сети не могут быть напрямую связаны (поверьте, мы спросили): мы можем только обмениваться файлами. Мы хотели бы иметь возможность регулярно синхронизировать эти два местоположения, чтобы можно было делиться работой через соответствующие справочные репозитории.

Требования:

• Обмен должен быть разрешен в любом направлении.
• Нам необходимо иметь возможность работать над некоторыми ветвями одновременно с обеих сторон или, по крайней мере, восстанавливаться в случаях, когда это произошло, даже если мы ожидаем, что большую часть времени будем работать над отдельными ветвями. Это подразумевает, что для обработки расходящихся работ может потребоваться шаг интеграции.
• Большая часть отслеживания должна выполняться автоматически, так что ручное вмешательство и риск манипулирования ошибками из-за этого сводятся к минимуму (не то, что они будут фатальными, но лучше всего избегать указания пальцем: доверие ограничено). У нас есть много ветвей, обработка которых одна за другой - не стартер.
• Эталонными репозиториями можно манипулировать только с помощью удаленного push / pull и, при необходимости, легких административных операций, поскольку они находятся под контролем IT и потому, что мы хотим, чтобы они всегда были согласованными, то есть сначала выполнялась интеграция, а только потом изменения с другой стороны, опубликованные вместе с интеграцией в локальном репозитории.
• Мы не можем отправлять весь репозиторий (даже tar-gzipped) каждый раз: он не только немного велик сам по себе, но и все последовательно отправленные пакеты хранятся в записях, поскольку это является частью договорных обязательств и имеет N копий хранилище там быстро станет неустойчивым.
• Вся необходимая информация должна храниться в локальном центральном месте (те же ограничения, что и у репозиториев ссылок), чтобы любой разработчик мог выполнять этапы синхронизации, не завися от информации, хранящейся в локальном репозитории (ях) конкретного разработчика. .

Non-требования:

• Обработка более двух отключенных сайтов. Два уже будут достаточно сложными.
• Ночная обработка. Обмены будут запускаться и обрабатываться вручную.
• Ограниченное количество или сложность команд. Если необходимо много сложных команд, пусть так и будет, мы всегда можем скрыть эту сложность в скрипте.
• Пересечение автономных синхронизаций. Это всегда означает проблемы, как с потоками. Таким образом, мы можем предположить, что операции автономной синхронизации полностью упорядочены, независимо от их направления, и при необходимости по очереди.
• Детали управления филиалами и т. Д. Это наш внутренний бизнес.
• Поддержка Mercurial закладок. Мы ненадолго поэкспериментировали с ними, прежде чем оставить их.

Answer 1

Mercurial делает это легко с его связками; Отслеживание лучше всего выполнять при наличии клона репозитория, который находится в последнем известном состоянии удаленного репозитория и хранится в $SITE_B_IMAGE_URL. Пусть наше местоположение будет называться site-a, а удаленное местоположение будет называться site-b.

• Создание пакета для отправки в удаленное местоположение:

  1. ~/work$> hg clone $LOCAL_REF_URL bundler
  2. ~/work$> cd bundler
  3. ~/work/bundler$> hg bundle ../bundle-site-a-$(date +%Y-%m-%d) $SITE_B_IMAGE_URL

  Рабочий репозиторий может быть удален.

• Обновление удаленного хранилища отслеживания, когда удаленное местоположение подтвердило, что ему удалось отделить содержимое отправленного им пакета:

  1. ~/work$> hg clone $SITE_B_IMAGE_URL remote-tracking
  2. ~/work$> cd remote-tracking
  3. ~/work/remote-tracking$> hg push -R ../bundle-site-a

  Удаленное отслеживание рабочего хранилища теперь может быть удалено.

• Интеграция пакета из удаленного местоположения:

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

  1. ~/work$> hg clone $LOCAL_REF_URL bundle-integration
  2. ~/work$> cd bundle-integration
  3. ~/work/bundle-integration$> hg unbundle ../bundle-site-b
  4. В этот момент hg heads расскажет головы, включая случаи, когда для данной ветви имеется более одной головки, и, следовательно, где требуется работа, чтобы сократить до одной головки на ветку, поэтому вставьте здесь работу, необходимую для объединить посторонние ветви головок.
  5. Если hg push полностью завершится успешно, вернитесь; мы сделали
  6. ~/work/bundle-integration$> hg pull
  7. Примите во внимание работу, выполненную на вашем месте, которая произошла, когда вы были заняты выполнением предыдущих шагов
  8. Перейти к 5

  Теперь можно отказаться от рабочего репозитория с интеграцией пакетов.

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