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

[Augie Fackler]

On Mon, Aug 22, 2016 at 9: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.
>
> 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 ;-)

I think the latter is more sensible from a user perspective - the user
doesn't (ideally) know about or care about our locking requirements,
so the visible side effect to them (no phase changes) seems like the
thing to focus on from a UI level.

>
> /Mads