On Wed, Feb 23, 2011 at 9:53 AM, Julian Foad <julian.foad_at_wandisco.com> wrote:
> (I've appended the issue subject to the subject line.)
>
> Stefan Sperling wrote:
>> I filed a new issue today (issue #3818, "fix handling of externals in
>> wc-ng" http://subversion.tigris.org/issues/show_bug.cgi?id=3818).
>>
>> I had a brief chat with sbutler at the elego office before filing
>> this issue. Below are basic ideas we've had for approaching the
>> problem. Feedback appreciated!
>>
>> The basic problem we have in the current design is as follows:
>>
>> Given a local_abspath, there's an ambiguity about which wcroots
>> are associated with it when externals are involved.
>> E.g. given the path was foo/bar/baz, where bar has an svn:externals
>> property that configures an external to be downloaded into the
>> folder 'baz'. When we try to find a wcroot for this path, there are
>> two possible outcomes. One is the wcroot of the relpath 'foo',
>> the other is the wcroot of the external itself ('baz').
>>
>> (svn:externals ^/branches/foo baz)
>> |
>> .../foo/bar/baz
>> o----------------wcroot1
>> o----wcroot2
>>
>> The ambiguity arises because the local_abspath of wcroot2 is also
>> a local relpath within wcroot1.
>
> 'baz' is not a versioned node within wcroot1 so I don't see any
> ambiguity. I thought the intended interpretation was that each external
> tree is a separate WC, so, working with your example, I would expect
> each abspath to have an unambiguous interpretation as follows:
>
> abspath .../foo => wcroot1, relpath ".../foo"
> abspath .../foo/bar => wcroot1, relpath ".../foo/bar"
> abspath .../foo/bar/baz => wcroot2, relpath ""
>
> What is wrong with that approach? (Let's assume 'baz' is a directory.
> For file externals, this doesn't work so neatly, since a file can't
> currently be a WC root, so 'wcroot2' would have to be interpreted
> differently or faked or something.)
>
> - Julian
>
>
>> 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).
-Hyrum
>> We can look at this set of wcroots as a tree with the root node being
>> the wcroot of the parent working copy and any wcroots for externals
>> within it being children of the root node. This way we can also
>> easily represent externals nested within externals (children of
>> children). I'm thinking about using this tree abstraction in a new API
>> for wcroots in libsvn_wc. It would allow usual tree operations (insert,
>> delete, iterate nodes etc.) to manage wcroots. Every node apart from
>> the root node represents an external.
>>
>> This model could later be extended to support multiple trees of wcroots
>> when we start managing more than one working copy within a single wc.db.
>> (Steve also suggested to use this feature later for storing different
>> versions of the conflicting trees involved in tree conflicts.)
>>
>> To support this tree abstraction within wc.db we'd need a way of
>> identifying a local_relpath as the root of an external, and obtaining
>> the wc_id of this external. Any children of this local_relpath would
>> carry this wc_id. A nested external would work the same way. It changes
>> the wc_id again for a subtree of the external.
>>
>> (Most of?) our existing queries already make use of the wc_id, so they
>> work within the parent or within an external. The calling code can
>> decide which working copy to operate on by passing the appropriate wc_id
>> (or maybe a wcroot obtained from the tree abstraction API).
>>
>> Does anyone see any serious issues with this approach? Thanks!
>
>
>
Received on 2011-02-23 17:09:00 CET