Ryan Schmidt wrote on Thu, 17 Dec 2020 09:59 +00:00: > > > On Dec 16, 2020, at 13:13, M.Eng. René Schwarz wrote: > > > I am using mod_dav_svn with Apache2 in combination with a SVN repository > > containing symbolic links. When a URL pointing to a symbolic link is > > accessed, the web server does not follow this link, but provides a text > > file with the content "link [path to file or directory]". > > > > I was wondering if there is a possibility to make mod_dav_svn actually not > > providing this text file but the contents of the linked file directly? > > > > Background: > > An installer is downloading several files for installation from the > > repository over the web server whereas the flexibility to specify a certain > > repository revision via the "!svn/bc/" special syntax is used, without the > > need for the installer to be aware of the SVN repo itself. For the > > installer, this address is just an ordinary URL. This worked well for a > > couple of years, but now symbolic links have been used in the repository > > which is causing the trouble for the installer now as it gets not the > > actual file, but the text representation of a symbolic link. > > As far as I know, mod_dav_svn does not have this capability.
+1 > mod_dav_svn is a server process, and symlinks are a client-side-only > feature. The server has no knowledge of symlinks and just stores the > files and their properties. The Subversion client stores symlinks in > the repository exactly as you're experiencing: as a text file with the > contents "link [path to file or directory]" and a property > "svn:special" set to the value "*". > > In this case, your installer is acting as the Subversion client, so you > would have to modify your installer code to get it to notice when a > file it's accessing is a symlink and to make it send another request to > get the real file from its actual location. If you want to do it right, > you should consider that there could of course be multiple levels of > symlink indirection, and any of the directories leading up to the file > you want could be symlinks. The need for Ω(1) round trips is a good argument for adding a server-side symlink resolution thing (similar to the ?p= query argument already supported), though we'd have to be careful about dot-dot symlinks that point to above the repository root or into !svn (which is a perfectly valid dirent name to lower layers), symlink loops, etc.. It's possible some repository viewers (ViewVC-like tools) already provide this functionality. Note that !svn and everything under it are implementation details. Cheers, Daniel