You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@subversion.apache.org by Ben Reser <be...@reser.org> on 2012/10/18 23:30:27 UTC
Sparse Externals
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?
Re: Sparse Externals
Posted by Hyrum K Wright <hy...@hyrumwright.org>.
On Thu, Oct 18, 2012 at 5:30 PM, Ben Reser <be...@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
Re: Sparse Externals
Posted by Branko Čibej <br...@wandisco.com>.
On 21.10.2012 20:49, Ben Reser wrote:
> On Fri, Oct 19, 2012 at 1:00 AM, Branko Čibej <br...@wandisco.com> wrote:
>> Oh yes. Eventually I'd like to see something like this:
>>
>> * The functionality of repo-relative externals replaced with some
>> flavour of in-repo links, so that the client doesn't even have to
>> know about them.
>> o ... though quite likely the client will have to have /some/ way
>> to know about the fact that it can see the same file twice under
>> different paths in the WC
>> * Most of the current uses of externals to other repositories replaced
>> by better handling of remote branches (including support for remote
>> merges) -- Julian and I have talked on and off about how to
>> implement this.
> Indeed remote merges would be helpful to a lot of workflows. Our
> support for vendor branches could essentially be fixed by this and
> Subversion front ends to other version control systems have become so
> prevalent that people could even merge from other version control
> systems.
That's one of the use cases we talked about, yes. Given how
heterogeneous the VCS world has become, more and more people will want a
feature like that.
-- Brane
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: Sparse Externals
Posted by Ben Reser <be...@reser.org>.
On Fri, Oct 19, 2012 at 1:00 AM, Branko Čibej <br...@wandisco.com> wrote:
> Oh yes. Eventually I'd like to see something like this:
>
> * The functionality of repo-relative externals replaced with some
> flavour of in-repo links, so that the client doesn't even have to
> know about them.
> o ... though quite likely the client will have to have /some/ way
> to know about the fact that it can see the same file twice under
> different paths in the WC
> * Most of the current uses of externals to other repositories replaced
> by better handling of remote branches (including support for remote
> merges) -- Julian and I have talked on and off about how to
> implement this.
Indeed remote merges would be helpful to a lot of workflows. Our
support for vendor branches could essentially be fixed by this and
Subversion front ends to other version control systems have become so
prevalent that people could even merge from other version control
systems.
> This only leaves the case where you really want to pull the WC together
> from different repositories, and that would require new UI to exploit
> the potential of WC-NG. I'd recomment starting by:
>
> * deprecating the svn:externals property
> * completely deprecating file externals (in the sense that,
> eventually, we'd stop supporting including files from external
> repositories in the working copy).
>
> I know this will seem like a step backward, but really, I can't think of
> a good argument for continuing to indefinitely support a feature that we
> knew was broken from day one.
That's roughly what I was thinking. I hadn't really considered the
file external case. What are the problems with it (it's been added
since I haven't been active and I've never used it so I have no idea
what the problems are with it)?
Re: Sparse Externals
Posted by Branko Čibej <br...@wandisco.com>.
On 18.10.2012 23:30, Ben Reser 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?
Oh yes. Eventually I'd like to see something like this:
* The functionality of repo-relative externals replaced with some
flavour of in-repo links, so that the client doesn't even have to
know about them.
o ... though quite likely the client will have to have /some/ way
to know about the fact that it can see the same file twice under
different paths in the WC
* Most of the current uses of externals to other repositories replaced
by better handling of remote branches (including support for remote
merges) -- Julian and I have talked on and off about how to
implement this.
This only leaves the case where you really want to pull the WC together
from different repositories, and that would require new UI to exploit
the potential of WC-NG. I'd recomment starting by:
* deprecating the svn:externals property
* completely deprecating file externals (in the sense that,
eventually, we'd stop supporting including files from external
repositories in the working copy).
I know this will seem like a step backward, but really, I can't think of
a good argument for continuing to indefinitely support a feature that we
knew was broken from day one.
-- Brane
--
Certified & Supported Apache Subversion Downloads:
http://www.wandisco.com/subversion/download
Re: Sparse Externals
Posted by Johan Corveleyn <jc...@gmail.com>.
On Thu, Oct 18, 2012 at 11:30 PM, Ben Reser <be...@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