Re: [Monotone-devel] somewhat incoherent debate over CVS limitations, with a feature request buried inside

[Nathaniel Smith]

On Mon, Jun 21, 2004 at 10:56:07AM +0200, Lele Gaifax wrote:
> >>>>> "Nathaniel" == Nathaniel Smith <address@hidden> writes:
> 
>     Nathaniel> Is anyone aware of any document describing what modules
>     Nathaniel> are and why anyone cares?  What they do and what the
>     Nathaniel> use case(s) they're trying to solve are?  I've never
>     Nathaniel> understood this.
> 
> CVS modules basically let's you configure a virtual tree out of
> concrete versioned subtrees of a repository.  This makes it easier to
> handle cases where you want an easy way to extract a subset of the
> repository focused on some product (say, its sources in './src' and
> all the libs it needs under './lib').  From this point of view, they
> brings the same as symlinks, if you imagine they coming from a central
> versioned script.

What's the desired behavior with regard to write operations?  A
virtual "view" on some other trees makes sense, but should one be able
to edit this view and have the changes propagate back to the separate
original projects?

What should happen if someone tries to rename a file between say
lib/foo and lib/bar?

I assume that the combined tree always tracks the original trees
exactly -- it's not a snapshot; if one of the original trees changes,
the combined tree changes automatically, and you lose the earlier
version.  Is that a good feature, a bad feature, or does it matter?
(I'm thinking it might be bad in some situations -- like when you test
that one particular cominbation of library versions work well together
before making a release, and you don't want them to then change
underfoot without warning -- but I don't understand all the desired
use cases, so...)

Related to all of the above, should the combined tree be able to
diverge from the original trees?  I'm thinking of a project like
monotone, that embeds a number of third-party libraries in its source
tree -- presumably one would have a sqlite branch, that contained
the unmodified upstream source, and then the 'monotone' module would
include both source for monotone itself, plus the sqlite branch by
reference.  However, monotone makes local changes to the upstream
sqlite sources, and it would be good to be able to keep those separate
from the upstream source, manage merging them against new upstream
releases, etc.  Is this the sort of problem that a module system
should solve?

(The answers may well depend on the use case in question; maybe that
will help us figure out what the desired use cases for this sort of
functionality are?)

-- Nathaniel

-- 
Details are all that matters; God dwells there, and you never get to
see Him if you don't struggle to get them right. -- Stephen Jay Gould