Mailing-List: contact dev-help@subversion.apache.org; run by ezmlm
Precedence: bulk
Received-SPF: pass (nike.apache.org: domain of jcorvel@gmail.com designates
 209.85.192.54 as permitted sender)
MIME-Version: 1.0
In-Reply-To: <20150130001049.GB18561@ted.stsp.name>
References: <20150128095434.GM26869@ted.stsp.name>
 <1422530067.22855.47.camel@localhost.localdomain>
 <20150129113324.GS26869@ted.stsp.name> <54CA7B39.3010101@gmail.com>
 <20150129214554.GZ26869@ted.stsp.name> <54CAADBC.1000805@gmail.com>
 <20150129221539.GB26869@ted.stsp.name>
 <CAB84uBVZZWPOYLYQsXnBYHvgPrXCFLUis7rLz9kPpfxAM+w6Gg@mail.gmail.com>
 <20150130001049.GB18561@ted.stsp.name>
From: Johan Corveleyn <jcorvel@gmail.com>
Date: Fri, 30 Jan 2015 01:32:46 +0100
Message-ID: 
 <CAB84uBURoSVXioyQJdbV8tH3g32CVWTr8K=kpZxsMaPhhYtvSA@mail.gmail.com>
Subject: Re: [vote] pin-externals branch to trunk
To: Stefan Kueng <tortoisesvn@gmail.com>,
	Subversion Development <dev@subversion.apache.org>
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: quoted-printable

On Fri, Jan 30, 2015 at 1:10 AM, Stefan Sperling <stsp@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=C3=BCng 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=C3=BCng 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 wit=
h a
                             fixed revision. (See the svn:externals propert=
y)
]]]

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.

--=20
Johan