[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:48:48 CEST

Garrett Rooney wrote:
>
> 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.

This sounds like everybody is going to have to write their own scripts
to checkout/update external projects, and there's going to be multiple
ways to do it and get it right. I'd rather keep the functionality
in svn.

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

I agree with the svn:tarball feature because it feeled a little to
hackish, but checking out a Subversion wc inside of another one
doesn't to me. In fact, I wish Subversion would go a step further
and have symbolic links or svn:externals for files.

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

It feels to me enough of svn to keep it in.

Best,

Blair

-- 
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:49:48 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.