On 25.05.2018 18:07, Daniel Shahaf wrote:
> Stefan Küng wrote on Fri, 25 May 2018 17:37 +0200:
>> Can anyone comment on this please?
>
> I'm not familiar with the Windows side of things, but I gave the
> patch a spin.
And I'm not familiar with soft/hardlinks on Linux. :)
> If I do 'mv .svn x; ln -s x .svn', things seem to work. However, if the
> target of the '.svn' symlink isn't in the same directory as the symlink,
> 'status' just shows everything with '!' status. I didn't check, but if I'd
> done 'ln -s ../../.svn subversion/tests/.svn' and run 'status' in
> subversion/tests/, I assume it would confuse trunk/README and
> trunk/subversion/tests/README (due to having the same basename).
ok, so this breaks on non-Windows systems.
I'll try another patch soon.
question: symlink handling in svn does not seem to actually work on
Windows. At least the docs state that they're not handled on Windows.
So why do we even check for 'special' nodes on a Windows build?
If e.g. svn_io_check_special_path() on Windows would always return false
and svn_io_check_path() always call svn_io_check_resolved_path()
instead, this would work fine with the reparse points on Windows.
So is there a reason why this is not done so on Windows? Is there maybe
a reason for handling reparse points specially on Windows that I don't
know of?
>>> IMHO handling links/reparse-points specially is only required in very
>>> specific situations, like adding them. In most cases, resolving the
>>> links/reparse points is what should be done. Or am I missing something
>>> big here?
>
> This is a very general statement ("most code should use stat() rather
> than lstat()"). What specifically are you proposing to do?
Seems on Linux this really needs special handling.
But as far as I can see, on Windows this special handling actually
breaks things.
Stefan
Received on 2018-05-25 20:30:16 CEST