On Wed, Feb 23, 2011 at 05:50:57PM +0000, Philip Martin wrote:
> 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.
The above. A wc_id maps to a unique wcroot and vice-versa.
> We could tie a path to a wc_id instead. This one?
No, because if externals are in use, a path can map to more than one wc_id
(the ID of the parent WC, or the ID of the external WC).
> 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".
Yes. And that allows us to tell apart switched paths from externals
(see my other reply).
> I don't really see how it solves the original problem: for a given path
> which wc_id applies?
You can never know the answer to this question if you're just given a path.
That's why we need either a wcroot or a wc_id to go along with a path to
resolve ambiguity.
> 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?
Or a wcroot/relpath pair. Or something similar that encodes enough
information (suggestions welcome).
> I'm not really sure exactly what you are proposing. How does a wcroot
> differ from a wc_id?
The wcroot (svn_wc__db_wcroot_t to be precise) is an object that contains
the wc_id among other things. So we could have an API that returns the
wcroot given a wc_id, i.e. once you know the ID you can get at the root
and then at more information about the WC.
> Does wcroot refer to svn_wc__db_wcroot_t? Or to some more general
> "directory containing a .svn"?
To a svn_wc__db_wcroot_t.
A .svn directory contains a wc.db which in this new model would manage
data for several working copies. Every one of those working copies has
a wcroot object associated with it.
The working copies can be nested in case there are externals involved
(i.e. a tree structure of nested wcroots represents a working copy
which contains externals).
Initially (in 1.7) we would only support the nested case to support
svn:externals. Later we can extend this design to cover more use cases,
e.g. allowing users to use a shared meta data area (e.g. ~/.svn) for
all or a subset of their working copies.
Is it more clear now?
And is there anything I'm overlooking that might not work for some reason?
