Stefan Küng <tortoise...@gmail.com> writes: > Index: subversion/libsvn_subr/io.c > =================================================================== > --- subversion/libsvn_subr/io.c (revision 1831874) > +++ subversion/libsvn_subr/io.c (working copy) > @@ -342,8 +342,11 @@ > /* Not using svn_io_stat() here because we want to check the > apr_err return explicitly. */ > SVN_ERR(cstring_from_utf8(&path_apr, path, pool)); > - > +#ifdef WIN32 > + flags = APR_FINFO_MIN; > +#else > flags = resolve_symlinks ? APR_FINFO_MIN : (APR_FINFO_MIN | > APR_FINFO_LINK); > +#endif > apr_err = apr_stat(&finfo, path_apr, flags, pool); > > if (APR_STATUS_IS_ENOENT(apr_err)) >
This needs a comment to explain why Windows needs to do something different. I think we would have to back this change out if we ever attempted to add svn:special support on Windows, but I suppose any such support is unlikely in the near future; as Branko pointed out CreateSymbolicLink doesn't have the semantics we want. Making .svn a symbolic link on Linux came up in another thread recently: https://lists.apache.org/thread.html/d08f3a0b71600e2b67cd39817cd99e4de25a7e4f12817fe451f162e5@%3Cdev.subversion.apache.org%3E At present there is an assumption that .svn lives on the same filesystem as the working copy and that files can be atomically moved from .svn/tmp into the working copy (see workqueue.c calling svn_io_file_rename2). If .svn becomes a symlink that points to a different filesystem then these moves fail and Subversion doesn't work. We might be able to work around this by replacing svn_io_file_rename2 with svn_io_file_move. I don't know if Windows has the same problem. -- Philip
