On 11/07/13 01:45, Peter Samuelson wrote:
>
> [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.
>
[Peter Samuelson]
> "Couldn't I have just written a script or Makefile to generate
> and delete them [special files]? Sure[...]"
Couldn't I just use an option to make Subversion follow symbolic links?
Nope.
See what I did there?
Thanks,
Dirk
Received on 2013-11-07 20:31:27 CET