Modeling recursive CVS modules in subversion-1.0.x

Hello!

(Apologies if I sent an empty message to the list moments ago via some
keyboard mashing.)

We've been considering what would be needed to move a large CVS
repository to subversion-1.0.x, and I think we've wrapped figured out
the right way to model everything we currently do except for one
important detail: recursively defined modules. Let me illustrate the
issue:

We have a lot of smallish libraries within one repository. There are
dependencies between these libraries in the sense that some higher
level library needs one or more lower-level libraries checked out in
order to build. Right now, we model these dependencies with the CVS
modules file. For example, consider the following libraries (one per
'lib*' directory):

 general/libOne (stands alone)
 general/libTwo (directly depends on libOne)
 general/libThree (directly depends on libOne)
 general/libFour (directly depends on libTwo and libThree)

 app/program1 (directly depends on libOne)
 app/program2 (directly depends on libTwo and libFour)

So the CVS modules file is set up with aliases that are essentially
like this:

 general_libOne -a general/libOne
 general_libTwo -a general/libOne general/libTwo
 general_libThree -a general/libOne general/libThree
 general_libFour -a general/libTwo general/libThree (no libOne)

 app_program1 -a general/libOne app/program1
 app_program2 -a general/libTwo general/libFour app/program2

So, if I check out app_program2, I automatically get its code and all
of its dependencies:

 general/libOne
 general/libTwo
 general/libThre
 general/libFour
 app/program2

There are a large number of these small libraries (think hundreds; we
say "libraries are cheap" in the same way subversion says "copies are
cheap" and we use the same code base for a wide collection of
application domains). The dependencies between them are captured
manually when they are created or changed, but they need to be
automatically followed on checkouts and they need to be versioned on
tags and branches. Ideally, new dependencies would appear on an "svn
update" too, but that's not critical. The working copy needs to be
"unified" so that that I can edit libTwo and program2 as checked out
this way and commit once to save the changes.
 
At first, I thought svn:externals was going to cover this
functionality, but it seems to focus on external relationships. I
really want to capture internal relationships, which is what the CVS
modules file is for, essentially.

So, the best idea I have come up with so far is to make a file in the
repository that essentially has the same list of relationships as the
CVS modules file that I "svn cat" through a script that builds a list
of what to checkout (i.e. what CVS does internally). Then, I can use
the output of that script to check out all the bits I need. But then
that doesn't make a "unified" working copy that I can commit to (in
fact, I'm not convinced this will even build the directory shape I
need).

Essentially, I have a tree in the repository, and I only want to check
out those paths of the tree (in space, not time) that are dependencies
for what I am working on, but then I want to be able to edit them all
together. In other words, I want to go "svn co http://.../trunk" or
"svn co http://.../branches/branch1" except have it pruned to include
only those paths that I specify in a "relative to base-URI" way.

I'm wondering if there's a way (a "subversion way") to capture
these relationships between my code, or if this problem has come up
before and how it was addressed. Thanks!

-- 
----------------------------------------------------------------
Brad Spencer - spencer@jacknife.org - "It's quite nice..."
"S.M.A.K.I.B.B.F.B." - A.J. Rimmer | http://jacknife.org/
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@subversion.tigris.org
For additional commands, e-mail: users-help@subversion.tigris.org