[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: Garrett Rooney <rooneg_at_electricjellyfish.net>
Date: 2003-07-23 18:42:27 CEST

Blair Zajac wrote:

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

I'm not saying that the data that drives the script (or whatever) has to
be stored in a property, you could just as easily have a target in a
makefile to download/update external code references, or a local script
you run to do so, or any number of other things.

We recently shot down a proposal for a svn:tarball feature largely
because it could be done outside of Subversion itself. A large
proportion of externals is the same way, and the parts of externals that
you can't easily support from a script seem to be broken anyway.

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

We deal with edge cases that crop up in our core functionality because
it's just that: core functionality. svn:externals really doesn't feel
like it's core functionality for a version control system.


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:43:17 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.