[PATCH 2 of 2] push: introduce --readonly to make push behave more like pull
Gregory Szorc
gregory.szorc at gmail.com
Tue Aug 23 17:02:58 UTC 2016
On Mon, Aug 22, 2016 at 6:14 PM, Mads Kiilerich <mads at kiilerich.com> wrote:
> On 08/22/2016 04:25 PM, Augie Fackler wrote:
>
>> On Sun, Aug 21, 2016 at 01:33:14AM +0200, Mads Kiilerich wrote:
>>
>>> # HG changeset patch
>>> # User Mads Kiilerich <madski at unity3d.com>
>>> # Date 1471735620 -7200
>>> # Sun Aug 21 01:27:00 2016 +0200
>>> # Branch stable
>>> # Node ID 48f4ae36a49929c2389bfb75064f96d16159b2d0
>>> # Parent 7880f56ca7495a2d0365a8280935eccd1e63f0c8
>>> push: introduce --readonly to make push behave more like pull
>>>
>> Hm, interesting. To clarify the use case, you've got two local
>> repositories, and you want to move some draft changes between them,
>> but because (for example) push allows a revset, it's easier to push
>> than to pull?
>>
>> So the goal here is to "push without publishing", and if the
>> destination supports drafts, you want to push the draft changes as
>> drafts, otherwise fail? Is that right?
>>
>
> My primary use case is to have a push hook that will push to other
> repositories - some of them local, some of them remote.
>
> Push has some advantages:
> * I can use revsets to control what is pushed.
> * Pushing is "the right model" for propagating changes - polling/pulling
> is bad.
> * For a master server with "slaves" it also has some advantages that the
> master will call out to the slaves instead of allowing them to connect.
> * It's so weird to creating a ssh connection to a remote server and pass
> the result of some local revset query, just to let it connect back and make
> a pull.
>
And I think a pull based model is more robust for replication. And I think
a pull based model where clients consume a log of "pull requests" that is
asynchronous to the push operation is even more robust.
Mozilla's first approach at replication was to have the master ssh into the
mirrors and effectively instruct them to perform a `hg pull`. Our current
solution has the master writing replication events into Kafka and daemons
on the mirrors reacting to said events. This is described in detail at
https://mozilla-version-control-tools.readthedocs.io/en/latest/hgmo/replication.html.
The solution works pretty well, especially if a mirror goes down or
connectivity drops. The biggest problem is inconsistency windows on
mirrors. And we have a mitigation for that
https://mozilla-version-control-tools.readthedocs.io/en/latest/hgmo/notifications.html
.
>
> But the problems are:
> * The primary problem is the write lock that prevents multiple
> simultaneous pushes. Sudoing to another user is a odd workaround.
> * When I'm pushing I'm in charge. Then it is "wrong" that it is hardcoded
> that the remote server decides how the push modifies state on my server.
>
> These problems can be addressed with this flag.
>
> I wonder if we should have --[no-]publish flags on push, wherein the
>> --no-publish form would make it easy to "push these draft changes but
>> only if it doesn't publish them" and the --publish form would make it
>> easier to "push and publish these, but don't make them public unless
>> the push succeeds." Thoughts?
>>
>
> Perhaps ... but that is also the opposite of what I'm asking for and would
> not solve my use case, right? I want to push as if the receiving repo was
> non-publishing. Also, I want it to not lock.
>
> I don't know if this feature I'm asking for most correctly is described as
> non-locking and thus readonly and not modifying state or publishing, or if
> it non-publishing and thus readonly and with no need for locking. It could
> be described either way - I just want one of them ;-)
>
> /Mads
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mercurial-scm.org/pipermail/mercurial-devel/attachments/20160823/02384c1a/attachment-0002.html>
More information about the Mercurial-devel
mailing list