(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.
>
> 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 16:54:00 CET