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.
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?
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.
Stefan
--
___
oo // \\ "De Chelonian Mobile"
(_,\/ \_/ \ TortoiseSVN
\ \_/_\_/> The coolest interface to (Sub)version control
/_/ \_\ http://tortoisesvn.net
