Replacing the forest extension with core functionality

[Jesse Glick]

Bryan O'Sullivan wrote:
> http://www.selenic.com/mercurial/wiki/index.cgi/NestedRepositories

The usage of 'tip' here looks confusing. My understanding is that 
normally in Hg, the pseudotag 'tip' always refers to the last-committed 
(or -pulled) changeset, on whichever branch. Your example shows

branch = default
rev = tip

which by that definition seems (potentially) contradictory, in case 
someone commits to a different named branch in that repo. Anyway you say 
of 'rev' "if omitted, the tip of the given branch is used", so couldn't 
the second line simply have been deleted?


"If an optional module is present locally, it will be affected by 
commands that operate in modules." is unclear. Are you saying that 
nonoptional modules will *not* be affected by such commands? Or just 
that if an optional module is not present, there is no error?


I would expect pull -u (or fetch) with --modules to first update the 
parent, then inspect its updated .hgmodules to see what modules might be 
there that also need to be updated.


Can a module itself have a .hgmodules files, recursively interpreted?


I'm not sure what bundle --modules should do, actually. The current 
format can only bundle changesets from one repo.


commit --modules would be nice (for a forest of loosely synchronized 
repositories) but not essential.