Currently the Mercurial plugin's method of changelog calculation just involves
pulling whatever it can into the workspace, and reporting what it pulled. If
there are slaves involved and the job is not tied to a slave, this is wrong. E.g.

(project init)
(commit 0)
(commit 1)
(commit 2)
#1 [slave-1] clone revs 0, 1, 2 -> empty changelog
(commit 3)
#2 [slave-2] clone revs 0, 1, 2, 3 -> empty changelog
(commit 4)
#3 [slave-1] pull revs 3, 4 -> changelog 3, 4
(commit 5)
#4 [slave-2] pull revs 4, 5 -> changelog 4, 5

So many of the changesets will appear in the changelog for the same job multiple
times (asymptotically once per slave).

SubversionChangeLogBuilder uses a special file $build/revision.txt to track the
last revision used by the job, so it only logs starting after that. MercurialSCM
should do something similar. 'hg in' supports no --prune option, but 'hg log'
does, so probably the solution is to pull first (can in fact dispense with the
bundle file), then

hg log --template ... --prune $tipOfPreviousBuild

This would not be correct for a repo using local branches which might have been
pulled. More precise would be:

hg heads --template '

\n' > revisions.txt
...
hg log --template ... $(for n in $(cat revisions.txt); do echo --prune $n; done)

Logging with --prune does seem to be slower on a big repo than 'hg in
$aFewNewChangesets.hg' - very CPU intensive. On my laptop, logging with a prune
of all but a handful of new changesets from the NB main repo using Hg 1.1.2
takes almost two minutes of pure CPU. Probably this could be optimized in Hg if
it were profiled and reported.