live-mirroring of repository

[Gregory Szorc]

On Tue, May 5, 2015 at 4:50 PM, Dave S <snidely.too at gmail.com> wrote:

> 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?
>

If 2 pushes are to separate heads, there are no race conditions. But in
order for you to know that, you need some cross-talk between the servers at
push time and you are back to solving that problem.

If 2 pushes touch the same set of files on the same head, you'll need a
merge commit to resolve things. Best case that can be done automatically.
Worst case you need human involvement to resolve the merge conflict. The
worst case scenario means your 2 masters are in a diverged state until
conflicts are resolved. That only results in more pain. Again, you want to
detect this scenario at push time, and that requires cross-talk between the
masters.

Multi master is hard. Period.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20150505/d8fa8bb6/attachment-0002.html>