views:

681

answers:

4

I have a directory on a Linux system that mostly contains symlinks to files on a different filesystem. I'd like to add the directory to a Subversion repository, dereferencing the symlinks in the process (treating them as the files they point to, rather than links). Generally, I'd like to be able to handle any working-copy operations with this behavior, but the 'svn add' command is where it starts, I think.

The SVN client utility doesn't appear to have any options related to symlink dereferencing in the working copy. I didn't find any references to this in the manual (http://svnbook.red-bean.com/en/1.5/index.html), either.

I found a poster on the SVN users mailing list who asked the same question but never received an answer, here:

(That poster ended up using hard links instead of symlinks. That technique is not an option, in my case, because the real underlying files reside on a separate filesystem.)

I'm using Subversion v1.6.1 on Fedora 11.

For what it's worth, I know that there are alternative tools/techniques that could help approximate this behavior, but which I have to discard for various reasons. I've already considered [and dust-binned] these possibilities: - a "union" mount, merging all of the the directories containing the real files, with the SVN working-copy directory as the "top" layer in the union; - copying/moving the real files to the same filesystem as the SVN working-copy, and using hardlinks instead of symlinks; - non-SVN version control systems. These were all neat ideas, and I'm sure they are good solutions to other problems, but they won't work given the constraints of this environment and situation.

+1  A: 

You have a lot of constraints but there is one thing that always works: hack the source.

You can easily build your own svn for linux, though making this mod may or may not be "easy". Anyway, if you don't have any managed symbolic links, you can make a crude hack and just have svn follow them always, as if they are hard links.

If your repository does contain versioned links, and you need to check out that part of it, then you will need a more sophisticated hack which, say, uses a property that controls the feature per file or per hierarchy or something.

There might be one other choice: versioned links appeared in 1.1.0, if the behavior prior to that was to follow symbolic links then perhaps you could just run an old client.

DigitalRoss
So, you're saying the answer to my actual question (can the SVN client do it) is "no". Right?
Ryan B. Lynch
Right, I'm saying "no, at least, not since 1.1.0 and maybe not before it, either". I suppose you have considered adding the other filesystem trees and then just keeping local unversioned symlinks. That would seem to work nicely except for requiring more than one commit or update to sync the whole working copy. (But not on other working copies without the local links.)
DigitalRoss
A: 

Idea: inject a shared library using LD_PRELOAD that intercepts stat/open/unlink etc so that svn does not see the symlinks. That would save you from having to modify the svn source.

David Leonard
A: 

You could also use physical links instead of symbolic links.

emel
A: 

As far as I know, with the current subversion version (1.6.x) there is no way to do that. If it had been for files (not directories) on the same file system you could have used hard links (w/o the -s switch in ln command).

trybik