On Wed, Feb 23, 2011 at 5:08 PM, Hyrum K Wright <hyrum_at_hyrumwright.org> wrote:
> On Wed, Feb 23, 2011 at 9:53 AM, Julian Foad <julian.foad_at_wandisco.com> wrote:
>> (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.
>
> I've always thought we could handle it a different way: the externals
> are just part of the same WC as the directories which contain them,
> it's just the repos_id and/or repos_relpath which happen to point to a
> disjoint location. In other words, externals are nothing more than
> switched paths, save for the fact that their existence is communicable
> to other clients via the properties (whereas "pure" switched paths are
> single-client-only).
Interesting discussion. I thought (directory) externals were already
implemented this way, i.e. the client automatically performs a switch
upon processing the externals.
Because if you interrupt an "svn update" after changing external
definitions, the external parts that were not already updated appear
as switched (and you can fix the half-hearted situation by running
"svn switch" on the not-yet-processed externals to switch them to the
correct external position). This is the same for both intra-repos
externals as foreign-repos externals (and the workaround also works in
both cases (except that you need --relocate if the change of externals
changed the repos location)).
This is described in this issue:
http://subversion.tigris.org/issues/show_bug.cgi?id=3751 (Interrupting
an update after change of externals leaves working copy in
half-switched state)
FWIW:
- I'd really like for commit (and anything else) to recurse into
intra-repos externals by default (or if not by default, at least
support it as an option).
- I agree the situation may be different for foreign-repos externals.
- Maybe the concepts of intra-repos externals vs. foreign-repos
externals should be fleshed out more, and be handled differently. A
lot of things that make sense for intra-repos externals don't make
sense for foreign-repos externals and vice versa (like recursing, and
reusing the same connections, or also oft requested: configuring an
external to point to the same revision as its parent).
- Maybe intra-repos externals would benifit from a new name, e.g.
"internals" ;-)?
Just my 0.02c ...
--
Johan
Received on 2011-02-24 11:47:17 CET