Це запитання стосується прозорої реплікації, і я підозрюю, що відповіді ще немає, тому що люди можуть завісити про прозорість. Я візьму на себе можливість відкласти прозорість на даний момент, щоб зосередитись на реплікації. Пізніше я розберусь із прозорістю (чи точністю), і насправді я не думаю, що це все так важливо для DVCS.
По-перше, дозвольте мені зазначити декілька ключових моментів щодо роботи репозиторіїв у DVCS. (Я найбільше знайомий з Mercurial, тому саме це я буду використовувати для прикладів, але я вважаю, що все, що я скажу, також стосується git.)
A. У DVCS будь-який клон містить той самий вміст файлу та історію, що й оригінал.
Якщо ви правильно зберігаєте репост синхронізовано, це означає, що ви можете використовувати звичайні операції з поширення зміни DVCS (клонування, натискання, витягування) та звичайні репозиції для побудови системи реплікації.
B. Нові зміни не потрібно розповсюджувати туди, звідки вони прийшли.
Зокрема, якщо я маю отримати зміни від конкретного репо-версії та додати деякі власні зміни, мої зміни не повинні повертатися до цього конкретного репо. Вони можуть піти в інше місце. Корисність цього має стати зрозумілою на прикладах, які я покажу нижче.
C. Зміни можна розповсюджувати за допомогою натискання або витягування.
У централізованій системі нових змін (я думаю) можна значною мірою підштовхнути до репо. У 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, перш ніж я можу внести зміни, мій натискання буде заблоковано. Інші зміни будуть реплікуватись на 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-етап", а налаштування DNS вирішить їх hg.duke.cn та hg-stage.duke.cn для розробників в Китаї, і відповідно для розробники в інших місцях. Але це трохи магії і може бентежити, і я дійсно не думаю, що це додає багато чого.
Я сподіваюся, що це відповість на ваше запитання. Я взяв ряд свобод із відповіддю, але мені здається, що вашу ситуацію можна було б виправити за допомогою методів, які я описав вище.