On 19.05.2015 16:40, Bert Huijben wrote:
>
>
>> -----Original Message-----
>> From: Marc Strapetz [mailto:marc.strapetz_at_syntevo.com]
>> Sent: dinsdag 19 mei 2015 15:59
>> To: dev_at_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? Or would this
happen implicitly when switching to the planned 1.7 storage?
-Marc
Received on 2015-05-20 09:21:20 CEST