On Fri, Jan 30, 2015 at 1:10 AM, Stefan Sperling <s...@elego.de> 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.
Ah, yes of course. Ignore my example for the purpose of recursiveness.
I was just trying to argue that intra-repository externals occur often
(regardless of recursive or not), which I thought you were disputing
(you said "How can we know that most people are using just one
repository?").
> 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?).
>
> Maybe I'm just misunderstanding what TSVN is doing.
> Perhaps it is simply doing what svn copy --pin-externals does now.
Ah yes, I see. I guess Stefan Küng will have to answer that one :-).
> Here's what 'svn copy --pin-externals' is currently doing, roughly:
> Any external defined within ^/A_copy (at itself and its children) will
> be pinned to the external's HEAD revision (if the source is a URL)
> or to the external's working copy's revision (if the source is a WC).
> For directory externals in the WC case we disregard the possibility that
> the external could be a mixed-rev WC and just use the revision of the
> top-most external directory.
>
>> 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 an ugly one. But I'm actually referring to:
[[[
C:\>svn help commit
...
--include-externals : Also commit file and dir externals reached by
recursion. This does not include externals with a
fixed revision. (See the svn:externals property)
]]]
I've never used it, but I'm now wondering what is meant by "reached by
recursion". Does it continue recursing into externals inside externals
etc.? Does it do a separate commit to other repositories for external
externals, and what happens when that commit fails etc.?
Anyway, I don't really want an answer to those questions, just trying
to point out another place in our code where similar considerations
might have been made.
--
Johan
