On Wed, Jan 25, 2017 at 2:23 PM, Dalton, Bill (GE Energy Connections)
<Bill.Dalton_at_ge.com> wrote:
> Johan,
>
> Thanks for your response.
>
> When I saw this description, I thought, "Oh yes. That's our problem." However, I think the thread I was looking at said it was fixed in 1.6. Our Subversion server is 1.9.2. Almost all of our agents are 1.9.4. A couple of the agents are 1.7.9. So, it doesn't seem to be the same problem. Or maybe there is a path to get to that failure that wasn't fixed.
>
> Sorry about the terminology. I'm not familiar with how these links are implemented. I have assumed that they were just Unix links. I know that what looks like a file is actually a pointer to another location which contains the actual file.
>
> Bill
No, the issue I referred you to, SVN-2516 [1] is not fixed, not even
in trunk. It's status in JIRA is "open", and I think that's correct.
The mail thread linked from the issue also ends without a conclusion
(there doesn't seem to be a definitive consensus on how it should
behave, and whether or not the new behaviour would need an option
flag, or if it would become the default). I don't see any mention of a
fix being in 1.6.
Also: externals are quite different from unix symlinks. For starters,
they are a working-copy-only thing ... the server doesn't know /
understand the link. It only sees a property ("svn:externals"), but it
doesn't interpret nor understand this property. It's just the svn
client which does some extra work when it sees such an svn:externals
property, by pulling in the extra items from the pointed-to repository
location into the working copy.
[1] https://issues.apache.org/jira/browse/SVN-2516
--
Johan
Received on 2017-01-25 16:33:15 CET