Branko =?ISO-8859-2?Q?=C8ibej?= <brane@xbc.nu> writes:
> > I think what you're talking about (CVS modules-like functionality) is
> > already planned via "union directories"; if you haven't seen JimB's
> > description of those, let me know and I can dig it up for you. It's
> > in the archives somewhere.
>
> Haven't seen that, but I'm interested.
Jim's post on the subject was pretty minimal, here's what he said:
Modules in Subversion are simply subdirectories of the filesystem.
To get some of the more sophisticated behavior of CVS's modules
file, we're going to provide new kinds of directories, whose
contents are computed from other directories.
But Jim described his idea verbally to me some months ago, in greater
detail. Here's the trail it left in my brain:
A CVS module is simply a name for a particular package of goods,
right? A module M includes this directory A, that directory B, that
other directory C over there, these files x, y, and z, etc.
In Subversion, equivalent functionality is achieved (elegantly, IMHO)
by having M be a directory. M's contents can be any collection of
versioned entities -- it's all just pointers in a repository anyway.
In particular, M's contents can even be the *union* of some set of
other directories (with certain precedence rules to resolve name
conflicts). This is one way "contents are computed", as JimB put it.
You could do intersections too, though that's probably less useful.
(Union directories with similar semantics were proposed for Linux's
ext2fs filesystem a few years ago, though I don't know that it was
ever implemented.)
Having modules be just another kind of directory moves the issue from
"What is a module?" to "What syntax do we use to specify a module?", a
problem that has already been solved (to some degree) in CVS and other
systems.
-Karl
Received on Sat Oct 21 14:36:16 2006