[Monotone-devel] Are CVS modules a desired feature?

[Lele Gaifax]

>>>>> "Nathaniel" == Nathaniel Smith <address@hidden> writes:

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

Yes, that's how it works under CVS, that is, when you checkout such a
"virtual view", you actually get a bunch of subdirectories each
effectively containing a CVS working dir pointing to some concrete
tree (and as such, it can be following HEAD or some branch).

Modifiying the extracted virtual view is really the same thing as
doing it on the concrete tree, as far as CVS is concerned.

Almost the same happens with svn's externals: with that, you can
configure the list of concrete directories that make up the virtual
view recording it on a special property (svn:externals) on the root
directory of the view. This allows you to include stuff from an
external repository as well.

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

Well, CVS does not handle renames, so this is a no problem :)
Under subversion, I guess it works ok *only* when both directories
come from the same repos.

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

You can certainly create that virtual view on "stabilization branches"
of the concrete libs and sources.

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

No, I think this would overload the mean of a module system, that
should IMHO just be a facility to arbitrarily "regroup" two or more
"software components" in a way that makes it easier for a developer to
extract a whole working environment and keep going. Ideally this
should not a burden on him.

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

My first desire for such a functionality would be targeting my Plone
development: briefly, Plone is a framework built on top of Zope and
several other products that form the basis of a CMF web site; on that,
I'm building custom applications, adding some customer specific
content, adjusting here and there the upstream components and
eventually contribuiting them back.

The situation is complicated by the fact that the upstream components
come each from a different repository: currently, Zope stable (2.7.x)
still live under CVS at zope.org (HEAD development moved to subversion
few weeks ago), Plone and few other products went from cvs.sf.net to
svn.plone.org, many other are still hosted by sf.net under CVS, zwiki
choose darcs....

As you can imagine, fetching the whole environment requires lots of
links and a funny combination of "{cvs|svn} co" and "darcs get"...

I'm currently (re)writing a tool that I used to keep everything under
svn: this will make it easy to track patches coming from different VC,
the first part of the problem. Once I get a homogeneus repository, I
have another script that given a "configuration" extracts the various
parts assembling them as needed, nesting the subproducts in the Zope's
"Products" directory.

Just to be clear, I'm **not** advocating for CVS modules, just
explaining how I used them, and how I could take benefit from a
similar builtin mechanism.

ciao, lele.
-- 
nickname: Lele Gaifax   | Quando vivrò di quello che ho pensato ieri
real: Emanuele Gaifas   | comincerò ad aver paura di chi mi copia.
email: address@hidden   |               -- Fortunato Depero, 1929.