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

[Yuya Nishihara]

On Tue, 23 Aug 2016 03:14:59 +0200, Mads Kiilerich 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.

Just an idea. Locking issue could be addressed at vfs layer, using something
like a readonly localrepo, which would be instantiated by "-R readonly:<path>".