>Cool idea.  I think this might prove very useful in the [src] reorganization.
>Can you provide an example?  I.e. checkout something stored as foo/bar/grill
>as grill/bar/foo.

The way I do it is set up a dir structure like this (shallow):

$CVSROOT/
	proj1/
	lib1/
	lib2/

And then in the modules file I can do things like

project1 &proj1 &lib1 &lib2

That simulates a directory structure like this (deep):

$CVSROOT/
	project1/
		proj1/
		lib1/
		lib2/

If you had selected a structure like this, you can simulate the
shallow structure with a modules file like so:

proj1 project1/proj1
lib1 project1/lib1
lib2 project1/lib2

Both "simulations" could also be done with symlinks (simulating
shallow with deep and symlinks is a bit easier), but that's
evil and may be a bit dangerous.

>I'd probably want to limit use of this to transition periods only.  I don't
>want to rely on an overly complicated modules file as a matter of course.

Well, when using a shallow structure, I tend to think of the modules file
as a piece of documentation as much as anything, showing how the pieces
are related.

One of the problems with "deep" is that when you want to use "lib1"
in another project, "project2", it is no longer possible to decompose
project1 and project2 hierarchically since they share a component.
So you either have to break the tree structure with symlinks, or
with the modules file.  The lazy approach would be to have something
like this:

$CVSROOT/
	project1/
		proj1/
		lib1/
		lib2/
	project2/
		proj2/
		lib3/

# modules file, not exactly sure if this construct will work
project2 project2 &project1/lib1

Anyway, now the directory structure is a bit misleading, but
it's "fixed" in the modules file.  The better way is to promote
lib1 up to the same level as project[12]:

$CVSROOT/
	project1/
		proj1/
		lib2/
	lib1/
	project2/
		proj2/
		lib3/

# modules file
# not exactly sure if this will work as-is
# there might be a simpler way to achieve the same effects
# backwards compat for ppl who checked out this subcomponent b4 promotion:
project1/lib1 lib1
# project[12] use lib1:
project1 project1 &lib1
project2 project2 &lib1

If you think really hard about how you intend to "promote" lib1 in this
case, only one method makes sense; a simple "mv" command.  Everything
else will screw up checking out old versions of project1.  That's because
you aren't moving the files in the "virtual" namespace that CVS
peers into; the whole point was to keep this restructuring transparent.

On the other hand, if you had a shallow structure, re-using
lib1 in project2 would look like this:

$CVSROOT/
	proj1/
	lib1/
	lib2/
	lib3/
	proj2/

# modules
project1 &proj1 &lib1 &lib2
project2 &proj2 &lib1 &lib3

Now suppose you want to group project[12] together into a "tools"
category.  It's straightforward again, you simply add this to modules:
tools &project1 &project2
To do it solely with the repository structure, you have to demote
project1 and project2 to a tools directory.

I think that this example shows that the modules file is more flexible
than using directories.  I think it also is required if you want to make
relatively natural changes to the repository without:
	1) breaking working dirs (...project1/lib1/CVS/Repository)
	2) using symlinks in the repository
Given that, it makes sense to me to embrace its flexibility for
maintaining the CVS namespace early rather than only as a band-aid.