[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

Re: Intro and questions

From: <kfogel_at_collab.net>
Date: 2001-07-30 17:58:19 CEST

<peter.westlake@arm.com> writes:
> - the main problem area of CVS that Subversion does not (yet) appear to
> improve upon is modules. CVS modules are badly broken, in that you have to
> hack around in the internal files of the repository to set them up, and the
> module structure is not versioned. So if I make a module include another,
> and check out the parent module from a date before I did that, I get the
> included module. What scope is there for putting a fully versioned module
> mechanism into Subversion? I get the impression that it ought not to be
> that difficult if approached in the right way. Such an implementation would
> have to support recursive operations, e.g. branching a module and all its
> sub-modules. Of course, this isn't always what you want, so there would
> have to be two ways to define a sub-module: one where the sub-module would
> be thought of as "part of" the parent module, and branched with it, and one
> where it would be thought of as "referenced by" or "linked to" the parent,
> so it would not be branched. Instead, both branches of the parent module
> would point to the same sub-module. There is also the orthogonal
> distinction of static vs dynamic sub-modules, which corresponds roughly to
> using a tag or a branch. If a module contains a static link to another,
> then any checkout of the parent module will get the same revision of the
> sub-module. With a dynamic link, it gets the tip. If the parent module is
> checked out from some time in the past, it would get the revision of the
> dynamic module current at that time.
> Have I explained all this in a way that makes sense? If so, do you think
> that the design of Subversion would permit these functions to be added
> cleanly?

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.

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 doubt we'll be tackling this anytime in the next few months. That
could change if someone gets an inspired design and volunteers to do
it, though. :-)


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:33 2006

This is an archived mail posted to the Subversion Dev mailing list.