[Monotone-devel] Re: Thoughts about Modules (request for comments)

[Graydon Hoare]

Bruce Stephens wrote:

> Right, so this is the same idea as nested checkouts, but using the
> manifest rather than some other mechanism?

We've batted around the shape and texture of this for years, but nobody 
ever pushed on it hard enough to implement. It's one of those "broad yet 
shallow" UI shifts that takes a lot of work to accomplish what seems 
like not-a-huge-feature. Even though everyone likes it, or something 
*like* it. Would have been easier if we'd designed it into the first 
pass, but we drew the line of what to implement a bit short of that 
(indeed, even restrictions were a bolt-on, with similarly broad strokes 
touching the entire UI).

> Isn't it cleaner to use attributes, as suggested in
> <http://www.venge.net/mtn-wiki/AttrUseCases> (and probably elsewhere)?

Yeah, I think we already have sufficient machinery for this. Just 
reserve an attr name on a dir. No need to revisit the manifest / roster 
format.

My $0.02: I think it is important to consider this in terms of contrast 
with pivoting roots. If you have a 3rd party library / module that you 
want to have tightly integrated / recursive / shared history with the 
containing project, you can just use pivoted roots. Then the containee 
history moves in lock-step as "part of" the container history.

This is specifically about cases where you want *looser* coupling 
between container and containee than you get with pivoting roots. In 
particular:

 - To keep the containing project's roster size down
 - To keep the containing project's history uncluttered with all the
   details of the evolution of the contained projects
 - To make a simple / obvious scheme for *reusing* contained projects
   between multiple containing projects without having to pivot each
   use in separately.
 - (possible) To make a way of persistently noting external non-monotone
   sources for automatic / scripted re-importing. Less ad-hockery.

I think these will only come up in large aggregating projects such as 
distros, but they're still important enough to cater to a bit. The 
tricky part is this:

 - if you only store a "symbolic link" to the containee, you have to
   make sure the containee history graph (and content!) moves along with
   the container history graph when you netsync. You don't want to get a
   project that cannot be fully checked out!

You could accomplish all but the first goal by using a sort of "history 
restriction" that collapsed or summarized changes that were confined to 
a marked directory. But you'd still have huge rosters. To get the small 
rosters, you need to store symbolic links of some sort.

It is possible that git split the abstraction better here, and hashing 
directory nodes recursively would have worked better. I am unsure: they 
also chose not to manage persistent node identifiers that are stable 
across inter-directory moves. That might get ugly (or require dropping 
down to some sort of GUID) if you want to be able to share content 
subtrees between different container histories.

-graydon