On 30.01.2015 18:14, Stefan Kueng wrote:
>
>
> On 30.01.2015 01:10, Stefan Sperling wrote:
>> On Fri, Jan 30, 2015 at 12:43:47AM +0100, Johan Corveleyn wrote:
>>> From the peanut gallery: I'm with Stefan Küng on this. I think
>>> "intra-repository externals" are used *a lot*, especially in
>>> companies. I'm not a big fan of this way of working myself, but I can
>>> certainly see it happening (just a couple of months ago in my company
>>> someone reused an xml schema (which was relevant to three different
>>> subprojects) by using file externals).
>>
>> File externals can't be recursive. So that's not the issue.
>> Those will just work.
>>
>> As I understand, the question is whether
>>
>> svn copy --pin-externals ^/A ^/A_copy
>>
>> should recursively pin externals found while crawling externals
>> definitions within externals definitions, ..., found in A_copy.
>>
>> I'm struggling with the idea. It doesn't really seem to make sense
>> for 'svn copy' to do this, and I'm not sure it's even well defined
>> as an operation. What does it mean for an external defined at ^/Y/Z
>> to be "pinned" when it is not within A_copy? It was found because,
>> say, an external at ^/A_copy/B/C points to ^/F/G within which
>> another external points at ^/Y/Z?
>>
>> To pin an external we need to copy it. Where do we copy ^/Y/Z for
>> pinning?
>>
>> Currently TSVN creates a separate commit which pins these externals
>> within the copy (and elsewhere?).
>
> it tags the externals within the externals at the location they point
> to. Example:
>
> dir
> dir\ext1
> dir\ext1\ext2
>
> ext1 points to root/project1/
> ext2 points to root/project2/
>
> dir is copied from root/project to root/branches/project
> TSVN now tags ext1 using the property on dir, then ext2 on the
> property on ext1.
>
> Which now I realize might not be the best idea. :(
>
> You're right, recursing into externals of externals is not such a good
> idea.
It's not ... and modifying externals in the WC prior to doing a WC->REPO
copy is not a good idea either, because you can't guarantee that you can
restore WC state after an error. Imagine that your commit (copy)
succeeds, then TSVN crashes, losing all data about previous externals
defs ...
> But can you maybe implement my other request about using an array of
> externals to tag so the user can chose which externals to tag and
> which ones to just leave as-is?
Sure, that's doable.
>>> I think it's fine for some features to work only for intra-repos
>>> externals and not for, well, external externals :-). As long as it's
>>> clear to the user. (don't we have a similar limitation for e.g. 'svn
>>> commit --include-externals'?)
>>
>> The only similar limitation I can think of is that file externals have
>> to be from the same repository -- which is widely considered to be a
>> major bug in their "design" :)
>
> Yes, that's one thing I have to explain a lot to beginners.
Well, since file externals literally have a "design" which has caused
tons of bad interactions in the WC in the past, good grief, it's a good
thing they're not complicated by supporting different repositories ...
-- Brane
Received on 2015-01-31 10:18:18 CET