(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!
