live-mirroring of repository

[Dave S]

On Mon, May 4, 2015 at 10:25 PM, Gregory Szorc <gregory.szorc at gmail.com>
wrote:

> 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.
>
>
Do you see this as a problem with any 2 pushes to the same head, or only
pushes where there are merge conflicts?

If a single client pushes the same file to both repos at the same time
("insurance, you know"), would that result
in a conflict or an automagically resolved merge?

/dps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20150505/045a4266/attachment-0002.html>