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

Reply via email to