Replacing the forest extension with core functionality

[John Coomes]

Bryan O'Sullivan (bos at serpentine.com) wrote:
> I've written up a sketch on the wiki:
> http://www.selenic.com/mercurial/wiki/index.cgi/NestedRepositories
> 
> It's frankly more a collection of questions than of answers, but we need
> to kick this thing off.  I propose a discussion period of one week.
> After that, the coding shall begin.

I like the idea of listing the modules explicitly.  I'm concerned that
keeping details like the pull location (url) and revision in a
versioned file would limit flexibility.  But let's make sure I read
the proposal correctly first.

Say I have a repo, my-modules, with the .hgmodules file in the example
on the wiki page:

	[foo/bar]
	url = http://hg.example.com/bar
	branch = default
	rev = tip

	[quux]
	url = http://hg.example.com/quux
	rev = 9117c6561b0b
	optional = true

And assume it's a complete clone, with a copy of all the modules.  Then I
run

     hg clone -M my-modules my-modules-clone

(Here I'm assuming that -M gets me a complete clone.)  And then 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.  If so, I think that would limit the
flexibility, but I'll make sure it's the case before I go on and on
about it.

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.  I think a separate
command should be used to list modules (e.g., "hg modules list").

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.

Relatedly, I'd like to see a convenient way to select a subset of
modules to operate on.  Expensive operations like hg status could
benefit greatly from this.  Say I have eight modules (m1, m2, ...,
m8), but only actively develop in two of them.  I'd like to be able to
run

	hg status -M --modules-list "m3 m4"

to get status on the root repo plus modules m3 and m4, but not the
others.  (No, I don't like --modules-list as an option name, it's just
an example.)

Finally, you mentioned that the term module was chosen arbitrarily.  I
think it's worth trying to find a term that's more suggestive of the
nature of these things.  Two obvious possibilities are nested
repositories (possible abbreviations: nrep or nest) and sub-repositories
(abbreviations: sub-repo or sub).  I'm sure there are other
possibilities.  I like sub-repo; has a nice parallel with sub-directory.
But one downside is that sub-repositories said quickly is suggestive of
medication taken in an unpleasant manner :-).

-John