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

[Bruce Stephens]

Robert White <address@hidden> writes:

[...]

> But if you decompose the way modules really work in CVS and abstract
> that to the manifest system there is a way to do it.  Essentially you
> need to consider that when you checkout a complicated directory tree
> where sub-trees are deferred into other projects (or segments thereof,
> but we really don't need subsegments).
>
> So in the manifest system we need a way to say "don't descend this
> sub-tree" and we orthogonally need a way to tell the system what we
> want in that tree.  So what we really have is a Bad "Directory, No
> Donut" designator in the Manifest.  So we take "file:" and "dir:" and
> we add "module:".

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

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

Or do you get some benefit from putting the information into
manifests?  I guess you might get renaming---I'm not sure whether file
attributes follow renames, though probably they do.

But anyway, the tricky parts are surely deciding whether "mtn diff"
and things recurse into nested branches, how "mtn log" reports such
things, and the more significant ones like what "mtn commit" ought to
do: if it recurses, then suddenly commit (presumably) isn't atomic
because it may commit to multiple branches.

I'm not suggesting I have any good answers to these.  As far as I know
nobody does---they're just tricky choices and whichever choices you
make will be wrong (or confusing) some of the time.  (No problem with
CVS, of course, because when you do anything you're doing it to the
individual files.  Similarly subversion's a bit more straightforward
provided everything's with the same repository.)

[...]