On 31 Jul 2001 18:46:45 +0100, peter.westlake@arm.com wrote:
>
>
>
> On 2001-07-30 16:58:19 kfogel wrote:
> ...
> >What you describe is roughly what we have been thinking about for
> >module support, actually...
> >
> >This has been discussed informally a bit, iirc, but we haven't got
> >concrete implementation plans yet, mainly because there's so much else
> >to work on and modules seem like something to be done over a mature
> >repository design, rather than early on.
>
> Interesting: I can't imagine using a system without them. At the moment
> we have that functionality in our product's build system, which complicates
> things no end. It isn't possible to query the structure, either.
>
> >I'm looking forward to stealing^H^H^H^H^H^H^H learning from Mark
> >Chu-Carroll's modules experience when we get to that point.
>
> I've started reading the Synedra papers. The terminology is oddly familiar.
> At my last job we had a rather nice home-grown system that ran on top of
> RCS.
> It had modules like the ones I've described, and they were called
> "compounds".
> It had "soft locks", too. I wonder if Synedra/Coven was an influence?
As much as I'd love to take some credit here, I very much doubt that
it was our influence. Synedra is a relatively recent project. Soft
locks and compounds are both bits of database terminology that were
appropriated by the SCM community. I can definitively date soft locks
in SCM systems back at least 15 years... And compounds, AKA
configurations,
at least 10 years. Synedra handles both of them differently from
a lot of conventional systems.
I'll try to put together a doc on how we handle subprojects,
and get it posted on our webpage, right after I finish with
this messy change I'm working on. Maybe that can give you
some good ideas of how to approach it.
<MC>
--
Mark Craig Chu-Carroll, IBM T.J. Watson Research Center
<mcc@watson.ibm.com>
*** The Synedra project:
http://domino.research.ibm.com/synedra/synedra.nsf
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Sat Oct 21 14:36:34 2006