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

Re: follow symlinks (2)

From: C. Michael Pilato <cmpilato_at_collab.net>
Date: Thu, 7 Nov 2013 15:31:54 -0500

On 11/07/2013 02:34 PM, Dirk wrote:
> It is utterly pointless to argue here.

[...]

> Unsubscribed before I get cancer or permanent brain damage from reading
> your passive-aggressive bullshit.

Uh... what just happened here?

I'm going to back up to the beginning of this thread, and see if we
can't restart with a bit more civility and a focus solely on the
technical matters at hand.

--------------------------------------------------------------------------

> 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.

Believe it or not, Subversion stores symlinks in the way it does because
that's the feature that its developers wanted. Many folks use
Subversion to version critical areas of their servers -- /etc, for
example, which is chock full o' symlinks. Depending on how much of /etc
you choose to version, that might mean that certain versioned symlinks
point to other things which are likewise versioned, but that's not
necessarily the case. What is of interest here is that, should someone
decide to roll back their /etc working copy in time, any versioned
symlinks are likewise restored to the state they held at that time.

I and others who use Subversion in this way clearly don't find this a
weird or foolish feature. We simply see Subversion doing what most
other popular archival programs would do with symlinks.

(Generally speaking, Subversion tries not to make too many assumptions
about your data, erring on the side of literal version control. This
isn't a design approach that was made ignorantly. Subversion's original
designers were long-time CVS users and maintainers who recognized from
years of manually fixing up CVS repositories for their support customers
that most of the time CVS tried to do something clever on the users'
behalf, stuff got fouled up.)

> 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.

Ah! This is a use-case that Subversion attempts to cover with its
"Externals Definitions" feature. It's not a perfect feature by any
stretch, and has historically caused us some degree of maintenance
frustration. But alas, it's what we currently have. See
http://svnbook.red-bean.com/en/1.7/svn.advanced.externals.html for
documentation on that feature (if you're not already aware of it).

> 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.

Yeah, sorry about that. Subversion is designed so that users on
different platforms can interoperate as much as possible without
platform-specific concerns getting in the way. !HAVE_SYMLINKS (which is
true on Windows, right?) essentially just tells Subversion to not
attempt to perform the magic OS-specific steps needed to translate
"the-repository-versioned-manifestation-of-a-symlink" into a real
symlink. This allows folks to version symlinks on Linux without their
Windows-wielding peers having partial or otherwise distorted working
copies of the same dataset.

> 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.

This might be something worth exploring further. Are you able to share
more details -- perhaps a reproduction recipe script?

> 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.

There's probably no small amount of work associated with such a feature
request, but it's not an unreasonable one by any stretch. Dirk, if
you've not already been thoroughly turned off, would you be so kind as
to file an issue tracking this?
http://subversion.apache.org/reporting-issues.html has the instructions
for doing so (and per this email, you may consider your issue
"validated" ... no need to mail users@ as described on that page).
Received on 2013-11-07 21:32:31 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.