[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: Hyrum K Wright <hyrum_at_hyrumwright.org>
Date: Thu, 18 Oct 2012 18:07:05 -0400

On Thu, Oct 18, 2012 at 5: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?

In theory, the wc-ng data model allows arbitrary nodes in the working
copy to reference arbitrary repositories and paths in those
repository. This would be a great way to *implement* externals,
leaving the property merely a UI to set and change them. We could
also introduce a new UI for doing so.

The problem, though is backwards compat with a heterogenous client
environment, so I'd think the property still has to be shuffled
around. (*sigh*)

-Hyrum
Received on 2012-10-19 00:07:38 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.