> -----Original Message-----
> From: Hyrum K Wright [mailto:hy...@hyrumwright.org]
> Sent: woensdag 23 februari 2011 19:47
> To: Julian Foad; b...@ted.stsp.name; Hyrum K Wright;
> dev@subversion.apache.org
> Cc: Stefan Sperling
> Subject: Re: initial thoughts on issue #3818: fix handling of externals in
wc-ng
>
> On Wed, Feb 23, 2011 at 12:26 PM, Stefan Sperling <s...@elego.de> wrote:
> > On Wed, Feb 23, 2011 at 04:26:52PM +0000, Julian Foad wrote:
> >> Hyrum K Wright wrote:
> >> > On Wed, Feb 23, 2011 at 9:53 AM, Julian Foad
> <julian.f...@wandisco.com> wrote:
> >> > > Stefan Sperling wrote:
> >> > >> So, ideally, we should decouple the
> >> > >> concept of a wcroot from the path. We could tie it to a wc_id
instead.
> >> > >> This would allow us to use a single wc.db to manage several
wcroots,
> >> > >> one for the parent working copy, and more for any externals within
> >> > >> this working copy.
> >> >
> >> > I've always thought we could handle it a different way: the externals
> >> > are just part of the same WC as the directories which contain them,
> >> > it's just the repos_id and/or repos_relpath which happen to point to
a
> >> > disjoint location. In other words, externals are nothing more than
> >> > switched paths, save for the fact that their existence is
communicable
> >> > to other clients via the properties (whereas "pure" switched paths
are
> >> > single-client-only).
> >> >
> >> > Since all the plumbing for switched paths already exists, we should
> >> > just be able to reuse it for the externals cases. In fact, as
> >> > currently implemented, switch can do some *really* interesting
things,
> >> > which Philip could probably better illuminate than me.
> >> >
> >> > In short, I don't think the answer is a set of wcroots but rather one
> >> > wcroot with a set of nodes (possibly pointing to various repos).
> >>
> >> +1 to that. In fact, I wrote about that idea a while back:
> >>
> >> Subject: [RFC] 'External' and 'Switched': common ground
> >> From: Julian Foad <julian.foad_at_wandisco.com>
> >> Date: Fri, 20 Aug 2010 18:54:09 +0100
> >> <http://svn.haxx.se/dev/archive-2010-08/0529.shtml>
> >>
> >> There are a few intentional differences in the way external directories
> >> (and files) behave, compared with switched nodes, but it looks far more
> >> sensible to implement them that way.
> >
> > We need to preserve 1.6 semantics of how operations affect externals.
>
> Why? People have been wanting to commit across externals and working
> copies for a *long* time. Putting them all in the same WC gives us
> this functionality for free (as well as other currently-not-atomic
> operations). Perserving these same limiting 1.6 semantics is
> something of a hard sell.
Because externals can come from different repositories and it would be very
caller unfriendly to return nodes from different repositories as if they are
from the same repository.
That way every loop throught the direct children of a directory would have
to verify the repository of every node. I think we should try to make the db
queries simpler (and faster) instead of heavier.
And we can't change the current behavior of externals on the libsvn_client
api or we would break all third party applications. (I think we can safely
invent a new type of externals).
I think just seeing every node below a workingcopy as a node in the parent
working copy will make things harder instead of simpler. So I would suggest
moving the redefining of normal externals to 1.8. (But I still think we have
to fix some file external issues for 1.7).
Whether or not externals are stored in the same db+pristine store as the
parent working copy is a different topic and that is very easy compared to
redefining what a 'child node' is. If somebody wants to do that for 1.7 he
has my +1.
Bert
