Re: Monitoring a repository for changes

From: Stefan Beller <sbeller@google.com>
Date: Jun 21, 2017, 19:55 UTC
Message-ID: <CAGZ79kau0cxRw6_bFKw6-wc2J9fBPPjRfpRhSxD+BGi2usvNpg@mail.gmail.com>
In-Reply-To: <20170621194425.vcu6qdmoddwpi3ht@sigill.intra.peff.net>

On Wed, Jun 21, 2017 at 12:44 PM, Jeff King <peff@peff.net> wrote:

Show 7 quoted lines

>
> Yeah. The naive way to implement this would be to have the client
> connect and receive the ref advertisement. And then when it's a noop
> (nothing to fetch), instead of saying "I want these objects", say
> "Please pause until one or more refs change". But I don't think we'd
> want to leave actual upload-pack processes sitting paused on the server.
> Their memory usage is too high.

https://git.eclipse.org/r/#/c/6587/

JGit has had its experiments with some standing connection and then having some sort of Pub/Sub system. AFAICT it did not go anywhere because of the number of connections (even if you optimize for the serverside, such that each connection is just the cost of a java thread and a file descriptor).

>
> The sticking point on both is that the client needs to speak before the
> ref advertisement begins, which is why we have to deal with the protocol
> v2 headache.

I would not call it headache, but large project that is not to be tackled by one person alone. ;)