Этот вопрос касается прозрачной репликации, и я подозреваю, что ответов пока нет, потому что люди могут зацикливаться на прозрачности. Я позволю себе на время выделить прозрачность, чтобы сосредоточиться на репликации. Я буду иметь дело с (или тонкой) прозрачностью позже, и на самом деле я не думаю, что это так важно в DVCS.
Во-первых, позвольте мне остановиться на нескольких ключевых моментах о том, как работают репозитории в DVCS. (Я лучше всего знаком с Mercurial, так что именно это я и буду использовать для примеров, но я верю, что все, что я говорю, верно и для git.)
О. В DVCS любой клон содержит те же файлы и историю, что и оригинал.
Если вы правильно синхронизируете репозитории, это означает, что вы можете использовать обычные операции распространения изменений DVCS (клонирование, push, pull) и обычные репозитории для построения системы репликации.
Б. Новые изменения не должны распространяться туда, откуда они пришли.
В частности, если я должен был получить изменения из определенного репо и добавить некоторые свои собственные изменения, мои изменения не должны возвращаться к этому конкретному репо. Они могут пойти в другое место. Полезность этого станет понятна из примеров, которые я покажу ниже.
C. Изменения могут распространяться с помощью push или pull.
В централизованной системе новые изменения в значительной степени (я думаю) могут быть внесены только в репо. В DVCS можно настроить различные топологии распространения изменений, некоторые из которых включают только вытягивание. Это обеспечивает большую гибкость в настройке.
Примеры
Для обсуждения давайте предположим, что ваши распределенные команды используют системы в доменах duke.de, duke.us, duke.cn и duke.mx, и, кроме того, именно в duke.de мы хотим получить «благословенное» репо. Учитывая эти предположения, позвольте мне привести ряд примеров различных топологий, которые вы можете настроить, имея в виду три ключевых пункта DVCS выше.
0. Централизованная Модель Push
Сделайте единый репозиторий на hg.duke.de, и пусть разработчики во всех местах клонируют и вытаскивают отсюда и вносят изменения здесь. Это может работать для людей в Германии, но это, вероятно, будет проблемой для людей в остальном мире. Все операции клонирования, извлечения и передачи будут проходить по медленным сетевым соединениям на большие расстояния. Это использует DVCS как централизованную систему. Это проблема, которую вы пытаетесь решить.
1. Централизованная передача с репликацией
Получите благословенное репо на hg.duke.de и получите копии на hg.duke.cn, hg.duke.mx и hg.duke.us. Разработчики клонируют из своей локальной реплики и помещают изменения в hg.duke.de. Всякий раз, когда в hg.duke.de появляются новые изменения, запускается ловушка, которая распространяет их на реплики. В противном случае реплики доступны только для чтения, поэтому слияний и конфликтов никогда не будет.
Например, если я разработчик в Мексике, я буду клонировать с hg.duke.mx, но внесу изменения в hg.duke.de. Если другие изменения будут помещены в hg.duke.de до того, как я смогу передать свои изменения, мой push будет заблокирован. Другие изменения будут реплицированы в hg.duke.mx, поэтому я извлеку эти изменения локально, объединю их, а затем снова попытаюсь переместить в hg.duke.de.
Это должно обеспечить некоторые преимущества, поскольку все операции большого клона выполняются локально. Выдвижение к центральному репо в другом месте может быть не таким уж плохим, так как изменения проталкиваются относительно редко, инкрементные изменения обычно довольно малы. (В частности, Mercurial, по сути, отправляет сжатые разности, а не целые файлы и их истории.)
В Mercurial вы можете настроить локальное хранилище для извлечения из одного местоположения и переноса в другое, добавив в .hg/hgrcфайл что-то вроде следующего :
[paths]
default = ssh://hg.duke.mx
default-push = ssh://hg.duke.de
2. Простая модель тяги
Продолжая использовать hg.duke.de в качестве благословенного репо, а остальные - в качестве реплик, мы можем распространять изменения с помощью pull вместо push. Разработчики клонируют и извлекают из своей локальной реплики как обычно. Когда изменение готово, разработчик отправляет запрос на извлечение в какую-либо центральную службу, которая извлекает данные из репозитория разработчика в hg.duke.de. Политика должна быть создана для слияний. Например, если есть конфликты слияния, запрос может быть отклонен, требуя от разработчика извлечения (из локальной реплики), слияния и повторной отправки запроса извлечения.
Преимущество этого подхода состоит в том, что он не заставляет разработчика ждать пока распространяются изменения. Конечно, разработчик все еще должен ждать ответа на запрос, но, по крайней мере, он или она может работать над дополнительными изменениями в течение этого времени.
вариации
Есть множество вариантов, которые могут быть применены.
Подача запроса на извлечение является идеальным временем для проверки кода. Изменения публикуются в том смысле, что они доступны всем, но они еще не были интегрированы в благословенное репо.
Запросы на извлечение могут выполняться вручную или с помощью некоторой автоматизированной системы. Обработка запроса на извлечение может не слить изменения непосредственно в благословенное хранилище, а вместо этого во временную промежуточную область, где выполняется цикл сборки и тестирования. Только после прохождения всех тестов набор изменений будет интегрирован в благословенный репозиторий.
Те, кто более доволен моделью push, могут захотеть установить локальное промежуточное репо в каждом месте, рядом с репликой, например, hg-stage.duke.mx, hg-stage.duke.cn и т. Д. Это требует немного больше работы, тем не менее, поскольку разработчики должны не только объединяться с другими локальными изменениями, но и кто-то должен нести ответственность за объединение изменений из промежуточных репозиториев в благословенное репо. Это может работать при правильных обстоятельствах и может быть автоматизировано.
«Прозрачность»
Теперь к вопросу прозрачной репликации.
Учитывая вышеописанные сценарии, я не вижу необходимости в прозрачной репликации. Все репозитории видны всем, и существуют соглашения для извлечения / клонирования из локальной реплики и переноса в благословенный репо или локальную область подготовки.
Если вы хотите прозрачности, вы можете настроить поиск доменов DNS в соответствии с их местоположением. Локальная реплика и промежуточные репозитории будут просто называться «hg» и «hg-stage», а настройка DNS разрешит их в hg.duke.cn и hg-stage.duke.cn для разработчиков в Китае и, соответственно, для разработчики в других местах. Но это немного волшебства и может сбить с толку, и я действительно не думаю, что это добавляет много.
Надеюсь, это ответит на ваш вопрос. Я взял на себя смелость ответа, но мне кажется, что ваша ситуация может быть исправлена с помощью методов, которые я описал выше.