live-mirroring of repository

[Gregory Szorc]

On Sat, May 2, 2015 at 3:36 AM, Lasse Kliemann <lasse at lassekliemann.de>
wrote:

> There are repos A and B on different servers. When changesets come into
> A, they should immediately be pushed to B. And vice versa: if changesets
> come into B, they should immediately be pushed into A. This way a user
> can use A or B, whatever has the better connectivity or whatever, and
> will always see the latest state.
>
> My solution so far was as follows. In A, there is a hook configured:
>
> changegroup = hg-hook-push URL-OF-B
>
> And in B, we have:
>
> changegroup = hg-hook-push URL-OF-A
>

First, merely having a "changegroup" hook won't mirror everything.
Bookmarks and phases are transferred via a "pushkey" API. You'll also want
a "pushkey" hook to initiate a mirroring operation as well to ensure these
changes are propagated.

Second, and more importantly, I wouldn't put too much faith in a simple
dual-master setup like this. A proper solution requires complicated and
coordinated locking between masters.

The "changegroup" hook fires *after* the local repository has committed the
push transaction to storage. Unless there is locking to prevent
simultaneous pushes, there will always be a race condition between 2 pushes
to the different masters. If they each manage to locally commit the
transaction, you now have 2 repos that think they are correct and there is
no way to reconcile the changes without rewriting repository history
(assuming pushes to the same head). And one of the pushers will likely get
angry if you do that.

To do this properly, you need a distributed lock to ensure only 1 push is
allowed at a time. There are hooks that could be utilized to devise such a
system. But the solution would be complicated. I would rather see
investment into a bundle2-based protocol extension that supported "proxied
push" to enable pushing to a local/fast mirror that proxies writes to a
central master. This solves your requirements, but without technically
introducing a dual master problem. This /might/ be possible with a
server-side extension in a bundle1 world. But don't quote me on that.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20150504/1b3bd964/attachment-0002.html>