Forest

[Mark Williamson]

Actually, replying to my own comment first...

Another advantage of explicitly specifying the subrepos that should be tracked 
is that disabling the automatic recursive walk would make it much easier to 
have forests of (various kinds of) nested repositories.  For instance, 
forests of forests, forests of MQ repositories, etc would be closer to 
working.

Crazy as this initially sounds from a workflow point of view, I think it does 
make sense e.g. a forest of interdependent repositories which are each 
managed using mq.

A forest of forests might happen if, for some reason you dependended on a 
particular version of the JDK forest (or at least, had only tested with a 
particular version) and wanted to version *that* together with your own code.

So although nesting like this is probably not suitable for a central repo, it 
can still be useful to individual developers, I think.

> > I'd go further and suggest by default only caring about subrepositories
> > that have been explicitly added.  e.g. have a (revision controlled)
> > subrepos file, which records what subrepos we care about.
>
> This makes a lot of sense.  In cases where there are relationships
> between the subrepositories, they would likely always have to have the
> same relative pathnames in order for automated builds to work: i.e. if
> I'm subrepo "open", then I either build with subrepo "../closed" if it's
> there, or do something else if it's not.

Having the subrepos at a specific well-known path within the forest makes a 
lot of sense to me (or rather, not doing that does not make sense to me).

I guess one could record a "move" in order to specify that one had relocated 
but I have doubts whether this would be particularly useful in practice.

Cheers,
Mark

-- 
Push Me Pull You - Distributed SCM tool (http://www.cl.cam.ac.uk/~maw48/pmpu/)