[svn.haxx.se] · SVN Dev · SVN Users · SVN Org · TSVN Dev · TSVN Users · Subclipse Dev · Subclipse Users · this month's index

follow symlinks

From: Dirk <noisyb_at_pwnoogle.com>
Date: Wed, 06 Nov 2013 22:49:31 +0100

Hello,

after going "full retard" in IRC (it was good for me) I have calmed down
enough to give constructive criticism in regards of subversion and how
it handles symbolic links on Unix (and compat.) platforms.

I wan't to start with a question. I am confident there is no answer to
it. At least not from people who share code between projects.

* Why does subversion store symbolic links instead of following them? *

I really don't get it. Who has a symbolic link inside a codebase
pointing to another place inside the same codebase? That. And only that
would justify the way how subversion handles symbolic links.

It is in my 20 years experience with Unix, code and CVS and subversion
much, /much/ more likely you use symlinks to point to code that is
shared between multiple repositories.

So it would be intuitive and conform to operating system standards if
subversion would follow these instead of storing the actual symlinks
and, by that, potentially cause a loss of precious work in an update in
another local copy.

So it was suggested to do it the subversion way. I can only assume that
subversion reinvents the usability of symlinks in it's own
murky/un-intuitive/proprietary way because of alternative operating
systems like windows that have nothing like symlinks. (I am sure there
will be a enthusiast trying to convince me that subversion does it
better than the symlinks i used the last 15 years. - It doesn't.)

So subversion has been developed for more than a decade now and nobody
thought about adding --enable-follow-symlinks or something similar to
the configure script. Fine. I can do it myself.

So I did just remove the #define HAVE_SYMLINKS from the config and build
it myself.

Only to end up with a client who /still/ recognizes symbolic links and
refuses to follow them.

Tonight I found out that subversion also has a problem when I just use
mount --bind to share code between projects. I thought I could do that
after the .svn was centralized in the root of the project. But no.
Subversion doesn't like that.

Another Problem I have with subversion is that everything is stored in
binary files. It is not like that I damage my repositories all the time.
It happens maybe once every couple of years. But when it happens there
is nothing else to do that to start a new repository with whatever is
left in the local copy.

I'd like to point out that CVS can, under any circumstance, be fixed
with a standard text editor. I just never had it that I has to reimport
a CVS repository to fix a broken one.

I really wonder what the advantages of subversion are except from that
TortoiseSVN is more actively developed than TortoiseCVS whose developers
seem to have a irrational aversion against switching from XP to Win7.
Win7 is ok for a Windows.

So. Despite knowing that some narcissistic project herald will announce
to my face that "It is impossible. Because it doesn't flow with out
vision." I would like ask you to include a compile option in the
configure script that makes subversion follow symlinks. Just for (the
majority of) us developers who have no use for symbolic links instead of
the actual files in their repository.

The package maintainers shall continue ignoring that little feature.

That way subversion would embrace something that made Linux great: Choice.

Thank you,
Dirk
Received on 2013-11-06 22:50:25 CET

This is an archived mail posted to the Subversion Dev mailing list.

This site is subject to the Apache Privacy Policy and the Apache Public Forum Archive Policy.