subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Sperling <>
Subject Re: [vote] pin-externals branch to trunk
Date Fri, 30 Jan 2015 00:10:49 GMT
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?).

Maybe I'm just misunderstanding what TSVN is doing.
Perhaps it is simply doing what svn copy --pin-externals does now.

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" :)

View raw message