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. 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:32:56 CET