Replacing the forest extension with core functionality

[Bryan O'Sullivan]

Hi, John -

Thanks for your comments.  Please add anything you think is worth
remembering to the wiki page, or I can fairly certainly guarantee not
remembering it.

> sometime later, I run
> 
>     cd my-modules-clone
>     hg pull -Mu
> 
> to pull and update the repo and all modules.  Where do the foo/bar and
> quux repos pull from?  The wiki description indicates they would pull
> from hg.example.com directly.

I changed it to follow the implementation in the RFC patch, which is to
try cloning from a location relative to wherever the parent repo was
cloned from.

> hg status and recursing into modules:  hg status -M should list the
> status of modules, not just list the modules.  We use the forest
> extension here, and hg fstatus is invaluable.

fstatus does some kind of mangling of paths within the nested repos,
right?  I don't like that aspect of it.

Now.  Since you actually use forest, maybe you can answer another
question or two for me.  What other commands actually need to be able to
traverse module/forest/whatever boundaries?

> On the "optional = " config item:  one person's required repo is very
> often another's unneeded baggage, so I would treat all modules as
> optional (which makes the config item unnecessary).  Use case:  I just
> want to look at the history for two specific repos out of the ten
> listed; I don't want to download all the related stuff that might be
> considered "required" to do a build.

I'm not sure a plain "optional" specification cuts it anyway, since it
doesn't capture anything but the most pedestrian of needs.  Probably
more useful would be a "configuration" notion, as in "get me everything
I need to work with the 'server' configuration", then allow a module to
be selectable by any of zero or more configurations.

> Relatedly, I'd like to see a convenient way to select a subset of
> modules to operate on.

The usual -X/-I machinery can be coopted to this end.

	<b