live-mirroring of repository

[Gregory Szorc]

On Thu, May 7, 2015 at 2:58 PM, Pierre-Yves David <
pierre-yves.david at ens-lyon.org> wrote:

>
>
> On 05/06/2015 09:58 AM, Gregory Szorc wrote:
>
>> On Tue, May 5, 2015 at 11:19 PM, Dirk Heinrichs
>> <dirk.heinrichs at recommind.com <mailto:dirk.heinrichs at recommind.com>>
>> wrote:
>>
>>     Am 02.05.2015 um 12:36 schrieb Lasse Kliemann:
>>
>>      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
>>>
>>
>>     I think the better approach would be some kind of transparent proxy,
>>     like gitolite does for git. Admin defines one repo as the master,
>>     while all others are slaves. People can then pull from and push to
>>     their nearest slave. However, the pushes are silently redirected to
>>     the master, which in turn pushes further to all slaves. No race
>>     conditions anymore.
>>
>>     The downside is: I don't know any Mercurial repo management tool
>>     that can do this. Does anybody else?
>>
>>
>> I think this is a feature that should be added to core Mercurial. A few
>> posts back I suggested it could be implemented as an extension to
>> bundle2. It could probably be done on top of the classic protocol. But
>> bundle2 has atomic transfer of push data, making it much better suited
>> for use in a transparent proxy.
>>
>
> Looks like this could be implemented a pretxnclose hooks?
>

If I had to take this approach, yes, I would use the transaction hooks to
ensure only one server won the push race.

But I still think having the server proxy pushes to a canonical master is
the better solution. One thing I've learned about distributed locking is
that it is best avoided if possible. The proxy solution centralizes locking
at the current master. I'll take that any day.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial/attachments/20150507/041892b0/attachment-0002.html>