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

[Pierre-Yves David]

Various opinion/idea on this matters.

- Another way to solve Mads usecase is to allow for pushing multiple 
patch at the same time, an easy way to define this would be to allow to 
define a path as an alias for multiple other (call "combined path"?). 
Given than we have path attributes already this should not be too hard 
to implement

- If we go for a magic config, I think the use-case is rare enough that 
a path attribute is enough. I don't see the point of getting an extra 
command line flag for it,

- If we get such config/flag I don't think we should make it specific to 
phases. bundle2's pushback requires locking (eg: pushrebase) and we'll 
keep adding usecase.

- I really like the yuya idea to have a specific syntaxt to access a 
repository read only ("-R readonly:<path>"). This is a slight extension 
of existing syntax/concept, consequence are very clear to the user, 
implementation will be very solid as plug very cleanly at low level.

- Another solution for mads is to have 'hg pull' support revset. We 
already have ways to hgweb to support revset without too much fear for 
DOS, we can probably extend that to pull.

Cheers


On 08/24/2016 02:20 AM, Mads Kiilerich wrote:
> 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
>
>
>
> _______________________________________________
> Mercurial-devel mailing list
> Mercurial-devel at mercurial-scm.org
> https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
>

-- 
Pierre-Yves David