If you have a build which needs to access multiple Hg repos at once, the normal
way to set this up is to use the Forest extension. OpenJDK uses this to group
together the different major components of the JDK, and NetBeans will probably
use this to specify a preferred location for contrib modules to be overlaid on
top of the main repository.

Hudson however supports only a single repository. If you wanted to set up such a
build with Hudson, you would only be able to configure the topmost repository
from the forest in Hudson. While you could include steps in the build script to
pull changes from nested repositories (cloning them if not already present),
these changes would not appear in the changelog, making it far harder to
diagnose build failures, and changes in a subtree would not trigger a build when
using polling.

Hudson should rather permit you to click a checkbox to use the Forest extension
(which would need to be installed and enabled in the local copy of Hg). In this
mode, fclone and fpull would replace clone and pull. The changelog creation
would need to call ftrees to get a list of trees (or search for them directly in
Java) and then log each one separately, and polling would need to check all the
trees separately.

While there could be more elaborate configuration options to retrieve only
specified trees from particular locations into specific subdirectories, I am
guessing that just enabling forest operations - where all the subtrees are
automatically detected in a fixed configuration from the same server - would
suffice for most sites, and add very little weight to the configuration GUI.