subversion-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Branko ─îibej <br...@wandisco.com>
Subject Re: JavaHL: ClientNotifyCallback reports unexpected kind "file" for symlinks
Date Wed, 20 May 2015 09:18:50 GMT
On 20.05.2015 08:54, Marc Strapetz wrote:
> On 19.05.2015 16:40, Bert Huijben wrote:
>>
>>
>>> -----Original Message-----
>>> From: Marc Strapetz [mailto:marc.strapetz@syntevo.com]
>>> Sent: dinsdag 19 mei 2015 15:59
>>> To: dev@subversion.apache.org
>>> Subject: JavaHL: ClientNotifyCallback reports unexpected kind "file"
>>> for
>>> symlinks
>>>
>>> When recursively adding a directory "test" which contains another
>>> directory "sub" and a symlink "sub.link" pointing to "sub", "sub.link"
>>> is reported with kind=file where I would expect to receive
>>> kind=symlink.
>>> The problem can be reproduced by following code snippet, using quite
>>> recent 1.9 binaries:
>>
>> I don't think Subversion uses kind is symlink anywhere in its public
>> api (yet), so this is totally expected.
>>
>> When we build WC-NG for Subversion 1.7 we introduced database support
>> for storing symlinks as their own kind, but we never switched to this
>> storage yet. Currently symlinks are still files with an 'svn:special'
>> property set on them internally, for Subversion repositories.
>>
>> The node kind enum was extended when we moved to a single enum for
>> node kinds, but changing how we report and store symlinks is far from
>> trivial.
>
> Thanks, Bert. I was pretty sure to have seen "symlink" kind reported
> somewhere. Now I think it might just be our own code which uses (or
> checks) for "symlink" ... I'll investigate in more detail.
>
> Either way, from an API user perspective, it would be helpful to
> distinguish between normal files and symlinks, especially because
> symlinks may refer to (local) directories and usually need a different
> treatment. Should I file an RFE in the issue tracker?

We can't report symlinks (e.g., in "svn status") without writing new
versions of a whole bunch of svn_client and other functions. This will
definitely not happen any time soon, especially since there is a trivial
solution: either stat the path (on Unix) or check if it has the
svn:special property set (on any platform).

> Or would this happen implicitly when switching to the planned 1.7 storage?

Which 1.7 storage are we talking about?

-- Brane

Mime
View raw message