[Dirk] > It doesn't make a lot of sense. These special files are platform > depending and there is no point in having them in /any/ repository. > Even if it is a project that is only for a single platform it doesn't > make sense storing special files in the repository. Symlinks, device > files, etc. are most likely worthless on another machine.
I question both assertions: that symlinks are platform-dependent, and that it is not useful to be able to store them. First, they are "platform dependent" only in an extremely broad sense. According to APUE, symlinks "were introduced in 4.2BSD and subsquently supported by SVR4." That's almost 25 years ago, about the same range of Unix variants where filenames can be longer than 14 bytes. (Remember that annoying 14-byte filename limit in Unix? Me neither.) Heck, even Windows Server has symlinks these days. Granted, they're kinda weird (with 2 distinct types, file links and dir links, and it seems 'mklink' requires administrative access). But they do exist. But the second and more important part of your argument is that there's no valid use case for symlinks in a repository. And there I think you're conflating relative links and absolute links. Absolute links, as you say, are often rather specific to one host or one OS. But relative links, links _within the checkout_, aren't at all. I've used them. Couldn't I have just written a script or Makefile to generate and delete them? Sure, but by that argument I could put uuencode and uudecode into a script, and never need the ability to store non-text files in svn.
