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

Re: let's kill svn:externals

From: Blair Zajac <blair_at_orcaware.com>
Date: 2003-07-23 18:33:36 CEST

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?

I'm -0.5 for removing it, or +0.5 for keeping it.

> 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.

How would the script work? What would it do? It seems natural
to keep the functionality in svn since the svn:externals are in
the wc itself. Otherwise we're going to end up with scripts that
look for svn:external and do the same thing.

> does anyone feel that strongly about keeping it? why?

I like the flexibility of it and what it provides.

> is it just
> because 'cvs has modules, and this is our equivalent'?

No, I never liked this feature because of CVS. I liked it because
it offers additional functionality in creating projects that depend
on other projects.

> 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.

Well, we've been dealing with edge cases in svn for a long time now.
Maybe we're getting tired of them :)


Blair Zajac <blair@orcaware.com>
Plots of your system's performance - http://www.orcaware.com/orca/
To unsubscribe, e-mail: dev-unsubscribe@subversion.tigris.org
For additional commands, e-mail: dev-help@subversion.tigris.org
Received on Wed Jul 23 18:34:31 2003

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

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.