SVN, Samba and symbolic links. How to make them all play together?

Question

I have a versioned website project that relies on files from an unversioned directory on the same server via Symbolic Links.

I currently store symbolic links in the repository. The idea is that if someone checks the working copy on the same server, they can edit and check the working copy of the project before returning it to the repository.

When they check their working copy, it successfully establishes symbolic links so that the entire site works during testing.

The users working on the project are Windows users, so I installed samba shares on the server and then mapped them to network drives in Windows. People can edit their working copies directly on the server through network resources, and then test them in a web browser before transferring their changes back to the repository via TortoiseSVN.

Problem

The problem is that Samba resolves symbolic links as expected, but when a user tries to push their changes back to the repository, TortoiseSVN considers the linked files to be part of the project and tries to transfer the target files to the repository and not the symbolic links themselves.

I tried disabling symlink support in samba, which means that linked files cannot be resolved, since I really don't want people to have access to linked files, and I don't want to import related files into the repository. The problem is that I get Can't stat '\\webserver\projects\working\project\symlinked_file.php'. Access is denied Can't stat '\\webserver\projects\working\project\symlinked_file.php'. Access is denied

Besides the problem with symbolism, everything else works 100% perfectly. Users can either check website designs on their computer, or work on them (but cannot check), or check them on their dev web server, and work on them and fully test them. Therefore, I do not want to change the workflow process, I just need a solution to the problem with a symbolic link.

Many thanks.

Answer 1

I decided to remove the symlinks from the repository. Then I created a bash script that prompts the user to create symbolic links in their working copy. I had to make sure I turned off the Samba follow symlinks to stop TortoiseSVN from trying to add related files to the repository.

It should also be noted that when a user commits using TortoiseSVN, he will show links in the change log, but they will not be checked and therefore will not be added to the repository. You just need to ignore them.

Answer 2

Could you use UNIX symlinks along with NTFS symlinks for windows compatibility? Or you can always browse other files and use svn: externals to link to them.

Answer 3

Aight, having gone through several options, is what I came across: the problem is that Windows does not know about symbolic links, but Tortoise does not destroy them during Windows checks. The solution is to allow people to quote around the Windows share, and then find a way to add symbolic links.

Of course, just rewriting them is not an option, as Tortoise will complain about modified files / directories, etc. We want to leave them alone. For a web server with static images / other resources, a simple Alias will work in the symlinked dir in the Apache configuration, but, alas, our code base also includes code with a symbolic link.

Under debian unionfs-fuse these problems were resolved. A recipe that seems to work here:

• Create basic checks somewhere on the linux server (svnroots).
• Create the directory where we are going to create the "overlay" (carcass).
• Find the svn-checkouts directory for symbolic links and recreate them in the framework:

.

 for file in `find $DEVPATH/svnroots/ -type l`;do path=`dirname $file | sed "s,$DEVPATH/svnroots,$DEVPATH/carcass,g"` mkdir -p $path path=$path/`basename $file`; ln -s `readlink $file` $path; done 

• Create the necessary directories (with peoples files from their shared resource, but symbolic links are stored in subversive activities:

.

 for user in ${windowsusers[@]}; unionfs-fuse -o cow,allow_other,suid,uid=33,gid=33 $DEVPATH/carcass=ro:$DEVPATH/$user/=rw $DEVPATH/correct_dirs/$user done 

Reading / writing to this directory will go to the user directory, and the carcass directory is read-only, but superimposed on the user directory, which leads to the correct symbolic links. The scripts are light enough to rerun symbolic changes in subversion (and no need to remount: changes in the frame are directly reflected in the correct disks).