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 <m...@kiilerich.com
<mailto:m...@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@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
--
Pierre-Yves David
_______________________________________________
Mercurial-devel mailing list
Mercurial-devel@mercurial-scm.org
https://www.mercurial-scm.org/mailman/listinfo/mercurial-devel
