On 19.05.2015 16:40, Bert Huijben wrote:
-----Original Message-----
From: Marc Strapetz [mailto:marc.strap...@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? Or would this
happen implicitly when switching to the planned 1.7 storage?
-Marc
