[PATCH 2 of 2] push: introduce --readonly to make push behave more like pull

[Mads Kiilerich]

On 08/23/2016 07:02 PM, Gregory Szorc wrote:
> On Mon, Aug 22, 2016 at 6:14 PM, Mads Kiilerich <mads at kiilerich.com 
> <mailto:mads at kiilerich.com>> wrote:
>
>
>     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.

Right now, I would agree. Pull is more stable than push because of the 
hardcoded policy that pull is read only so there can be multiple 
parallel pulls from a repo, but only one locking push at a time from a 
repo. I want to fix that.

(Btw: AFAIK, that "scalability regression" came when phases were 
introduced. I want to give an option for working around that.)

If you are running async out of a queue anyway and have this read-only 
push, then I doubt there will be much significant difference in 
robustness between initiating the "exchange" from the master and from 
the remove server. So sure, if you want more logic than just the plain 
hgweb on the remote servers and already have a reliable distributed 
secure message queue, then pulling is just as fine as pushing (except 
for the missing revsets).

No single size fits all, and even though our setups are similar, they 
also have differences. I would love to look more into your solution. But 
now, I just need this missing piece to make the next step / improvement 
in our setup.

/Mads

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.mercurial-scm.org/pipermail/mercurial-devel/attachments/20160824/86cb789d/attachment.html>