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

Re: Sparse Externals

From: Johan Corveleyn <jcorvel_at_gmail.com>
Date: Fri, 19 Oct 2012 02:26:03 +0200

On Thu, Oct 18, 2012 at 11:30 PM, Ben Reser <ben_at_reser.org> wrote:
> Regarding this issue: http://subversion.tigris.org/issues/show_bug.cgi?id=3311
>
> We don't support using --depth options other than infinity with
> externals. Bert mentions that wc-ng should make it easier to
> implement this.
>
> However, given the way svn:externals can be defined I think that it's
> really hard to implement this without a performance hit or without
> having users frustrated by the way it works. In particular you can
> define svn:externals at a different level than where you're putting
> them. If we wanted this to work the way most people I think would
> expect them to work you'd end up needing to walk all the way up to the
> repo root looking for externals on every checkout/update. Which
> stinks.
>
> We could punt on that but I'm not sure I like the idea of just
> continuing to apply hacks upon a poor design. So I'm wondering if it
> wouldn't be better to just replace externals with something that
> resolves a lot of other issues and gives us a more consistent
> behavior. While leaving the existing externals implementation alone.
>
> What does everyone else think? Anyone have put any thought into
> replacing externals?

I laid out some (more or less random) thoughts about externals in this
post a while back:

http://svn.haxx.se/dev/archive-2011-11/0243.shtml

Those thoughts are all pretty hand-wavy, I don't know enough of the
details to work them out any better right now (and don't have the time
to dig deeper at the moment).

Anyway, I certainly applaud efforts to improve (the design of) externals.

-- 
Johan
Received on 2012-10-19 02:26:55 CEST

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.