[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.
Received on 2013-11-07 01:45:55 CET