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.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?
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