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 <mad...@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>". _______________________________________________ Mercurial-devel mailing list Mercurial-devel@mercurial-scm.org https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel