SVN, Samba and Symbolic Links. How to get them all to play together?

I've got a website project under version control that relies on files from an unversioned directory on the same server via Symbolic Links.

I'm currently storing the symbolic links in the repository. The idea is that if someone checks out a working copy on to the same server they can edit and test the working copy of the project before committing it back to the repository.

When they checkout their working copy it successfully sets up the symlinks so that the entire site works when testing.

The users that work on the project are Windows users, so I've set a samba shares on the server and then mapped them to network drives in Windows. People can edit their working copies directly on the server via network shares and then test them in the web browser before committing their changes back to the repository via TortoiseSVN.

The Problem

The problem I have is that Samba resolves the symlinks as expected but when a user tries to commit their changes back to the repository, TortoiseSVN thinks the linked files are part of the project and tries to commit the target files to the repository and not the symlinks themselves.

I tried turning off symlink support in samba which means that the linked files cannot be resolved as I don't really want people to have access to the linked files nor do I want to import t开发者_JAVA技巧he linked files in the repository. The problem with this is that I get Can't stat '\\webserver\projects\working\project\symlinked_file.php'. Access is denied

Apart from the symlink problem everything else works 100% perfectly. Users can either checkout website projects to their machine and work on them (but can't test) or checkout them out to their space on the dev web server and work on them and fully test. So I don't want to change the workflow process, I just need a solution to the symbolic link issue.

Many thanks.

I decided to remove the symbolic links from the repository. I then created a bash script that prompts the user to create the symlinks in their working copy. I had to make sure I turned off Samba's follow symlinks option to stop TortoiseSVN from attempting to add the linked files to the repository.

Also it should be noted that when the user performs a commit using TortoiseSVN, that it will show the links in the changes log but they will not be checked and therefore will not be added to the repository. You just need to ignore them.

Could you use UNIX symlinks alongside NTFS symlinks to maintain compatibility with windows? Or, you could always version the other files and use svn:externals to link to them.

Aight, after going trough several options, this is what I ended up with: The problem is that Windows does not know about symlinks, but neither does Tortoise destroy them on Windows checkouts. The solution is then to let people do the checkouts on the Windows share themselves, and after that, find a way to add the symlinks back in.

Of course, just overwriting them is not an option, as Tortoise will complain about changed files/dirs etc. We want to leave them alone. For a webserver with static images/other resources in a symlinked dir a simple Alias in Apache configuration would work, but alas, our codebase also includes code by symlink.

Under debian, unionfs-fuse solved those troubles. The recipe that seems to work here:

• Create base checkouts somewhere on the linux server (svnroots).
• Create a dir where we are going to create an 'overlay' (carcass).
• Search the svn-checkouts dir for symlinks, and recreate them in the carcass:

.

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 desired directories (with peoples files from their share, but the symlinks as stored in subversion:

.

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 on that directory will go to the users directory, the carcass dir is read-only but is overlayed on the users directory, resulting in correct symlinks. The scripts are easy enough to rerun on symlink-changes in subversion (and a remount is not needed: changes in carcass are directly reflected in the correct_dirs).