Stefan Sperling <s...@elego.de> writes:
> 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.
It?
We could tie a wcroot to a wc_id instead.
We could tie a path to a wc_id instead. This one?
> 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!
So you are planning to move the admin date for svn:externals into the
wc.db in the parent/root working copy? And use a distinct wc_id for
each external? It sound plausible, and I think having svn:externals in
a single wc.db is the way forward. It's a bit like "switch and change
the wc_id as well".
I don't really see how it solves the original problem: for a given path
which wc_id applies? I suppose having only one database makes it easier
to solve. Having identified a wc_id are you planning to pass a
wc_id/relpath pair around?
I'm not really sure exactly what you are proposing. How does a wcroot
differ from a wc_id?
Does wcroot refer to svn_wc__db_wcroot_t? Or to some more general
"directory containing a .svn"?
--
Philip
