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

Mads Kiilerich mads at kiilerich.com
Mon Aug 22 21:14:59 EDT 2016


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 ;-)

/Mads


More information about the Mercurial-devel mailing list