[Buildbot-devel] Status of hg polling

[Tom Prince]

Georges Racinet <gracinet at anybox.fr> writes:
> After a quick read of GitPoller and its tests, that doesn't seem very 
> hard to adapt to Mercurial. What it relies on is fetching the changes by 
> calling the git executable in a subprocess.

One thing that the current git poller doesn't do well, is handle changed
settings or messed up poller directory. If you are writting an hg
poller, it would be good to make it reslient, i.e. check the state of
the repository, rather than making assumptions about the state, like the
git poller does.

> I don't know if importing mercurial from python could further allow to 
> avoid actually transmitting the changesets, but that would be much 
> harder to maintain anyway, as it's officially not stable (some 
> experience with Mercurial internals, here)

On thing to be carefulof, if you do this, is that any blocking code
needs to be in a thread (using deferToThread).

> A question though : I see that BzrPoller is in contrib while GitPoller 
> is in the main package. What's the reason ? If I were to try and 
> contribute some generic HgPoller (with tests), where should I put it, then ?

I'm not sure if there is any big reason. Perhaps partly because
bzr_buildbot mixes polling code, with commit hook code (the latter
typically lives inside contrib). If you are submitting a new change
source, it probably belongs in the main pacakge.

  Tom