waiting for changes (as part of or before hg pull)

Matt Mackall mpm at selenic.com
Fri Nov 26 12:31:10 CST 2010


On Fri, 2010-11-26 at 14:57 +0000, Frank Kingswood wrote:
> Hi!
> 
> It would be great if instead of polling it would be possible to wait for 
> incoming changes from a remote repository.
> 
> Perhaps this would work by the client openening a connection to the remote 
> repo and call read(), and this read() would return data only when the remote 
> repo had new changes.
> 
> The remote end could use notify if it is available, but even without notify 
> at least this way it would not be necessary to make repeated network connections.

Probably not a great idea. Having people poll often is not bad, it takes
less than 100 milliseconds for hg serve to service an empty pull search.
So it can easily handle several hundred users doing polls every minute.
This is obviously highly excessive for the average user.

Now imagine these same several hundred users are doing your
notification-socket thing. When one user pushes they:

a) all get woken up at once and trample the server under a classic
thundering herd of pull requests

or

b) the server single-threads notifications and whoever happens to be
last in the queue gets notified last, potentially many polling intervals
later

If this last user happens to be your highest priority user (ie your
build server), you lose.

Compare this to your build server polling once a minute and the rest of
your users polling a few times a day,

Then there's the non-zero overhead of keeping sockets open and DoS
potential to consider. As well as the cost of adding a new interface
that's not particularly well-suited to how either our SSH or HTTP
protocols work.

This could be implemented in a hook pretty easily. Even easier to have a
hook kick a particular set of clients without open sockets though which
is a good match for the build server case.

-- 
Mathematics is the supreme nostalgia of our time.




More information about the Mercurial-devel mailing list