I see svn:externals as a means to create functional meta-modules - which is a
problem I run into every day with CM systems and I assume most people do to.
You always have the case where a certain module is composed of a set of
files and a number of other modules.
The library case is a practical example. If you have a svn module for a
library X and you have 3 programs (A, B and C). The library has its own
development and release cycle and each one of the programs has their
independent development and release cycle. Now the problem is how do you
maintain these relationships. It's pretty easy to wave it off and say, "just
write a script".
Another example is if you have 3 book projects and a common glossary project
which you'd like to share across them. The development areas of the books
should point to the fluid glossary (i.e. the trunk) but when each book gets
stamped into an edition for publishing that glossary must be set in stone for
the book.
I know svn:externals doesn't come close to solving these situations, but it
is certainly a huge step forward from scripts having to scramble to get
together information which IMHO rightfully belongs in svn. Before
svn:externals fully solves this, you'd have to be able to create rules as to
what happens to the component modules when you copy/rename/remove the
meta-modules (e.g. possibly using a regexp substitution to determine how to
copy/rename each component). The fact that people have have problems with
svn:externals is because they are trying to stretch it to get the most out of
what it currently offers (myself included).
csd
On Wednesday 23 July 2003 09:19, Garrett Rooney wrote:
> ok, that's it, i've seen yet another post by someone with a problem with
> externals, and i've had it. i've been thinking about this for a while,
> and i'm tired of keeping quiet about it.
>
> can we just get rid of the svn:externals feature?
>
> it doesn't work that well, smacks of 'creeping featuritis', and can
> easily be replicated by a script of some sort for those who need this
> kind of functionality.
>
> does anyone feel that strongly about keeping it? why? is it just
> because 'cvs has modules, and this is our equivalent'? if so, that
> seems like a poor justification to me, especially if it isn't going to
> be a feature that works very well, which is what it looks like to me
> since every time we turn around there's another edge case that doesn't
> work well with them, and i seriously doubt we're going to catch them all
> before 1.0.
>
> -garrett
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
> For additional commands, e-mail: dev-help@subversion.tigris.org
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 23 19:23:10 2003