top button
Flag Notify
    Connect to us
      Site Registration

Site Registration

support of symlinks in SVN on Windows

+1 vote
1,066 views

Any thoughts regarding supporting symlinks in SVN on Windows? Windows has supported symlinks since Vista:
http://msdn.microsoft.com/en-us/library/windows/desktop/aa365680(v=vs.85).aspx

Supporting cross-platform symlinks where possible will ease some compatibility pain for cross-platform development.

posted Nov 7, 2013 by Majula Joshi

Share this question
Facebook Share Button Twitter Share Button LinkedIn Share Button

1 Answer

+1 vote

Probably the biggest issue here is that by default creating symbolic links requires administrator access on Windows. Users can be granted the permission without being an administrator. However, lacking the functionality for all users (as is the case on unix) makes it possible to cause problems for users on
Windows without the permission.

http://superuser.com/questions/124679/how-do-i-create-a-link-in-windows-7-home-premium-as-a-regular-user

I think nobody has put the effort into figuring out the appropriate way of dealing with this. The obvious thing to do would be to fall back to the current behavior if the permission isn't available. My concern would be that this would be confusing when the feature works for some users and doesn't for other users based on something as obscure as Windows a user permission.

answer Nov 7, 2013 by Ahmed Patel
Subversion could fall back to using junctions if the link target is a directory or hardlinks if it is a file. Junctions don't support links to things like network shares, though, but it's better than nothing and will surely cover 99% of the use cases. Hardlinks have the same caveat of course and suffer form recreation of files, like when a file gets reverted the former created hardlink to it will get invalid. But in theory as Subversion should normally be the on doing the revert it could beforehand get all hardlinks to the file and recreate those after the revert. Getting all hardlinks to a file is fast operation since Vista.

Of course it sucks that symlinks are restricted on Windows, opposed to junctions and hardlinks, especially that Windows itself doesn't use symlinks that much at all, but relies heavily on hard links instead.
Similar Questions
0 votes

I am looking to integrate SVN support into a Windows application. This application comes as both 32bit and 64bit versions and therefore I would need to have 64bit libraries. I have trouble finding the binaries for Windows 64bit development.

I would not mind compiling one myself, but it seems instructions are sparse and do not directly pertain to 64bit, perhaps because most people are just interested in the clients and 32bit is just fine there for most uses.

Thanks in advance?

0 votes

I received the following message when running SVN UPDATE --SET-DEPTH INFINITY on Windows (build 1.8.9 downloaded from VisualSVN site):

THIS APPLICATION HAS HALTED DUE TO AN UNEXPECTED ERROR. 
A CRASH REPORT AND MINIDUMP FILE WERE SAVED TO DISK, YOU CAN FIND THEM HERE: 
   ....

This seems to happen only when downloading many large files (like third-party DLLs) or many, many small files (I am guessing about 3000 files). This seems to be a problem with 1.8 as 1.7 never did this (again my guess)

I have also tried the svn included with 1.8.7 version of TortoiseSVN and it pops up the "encountered an error and needs to close" message.

Any suggestion on how to solve this?

+1 vote

We have a custom tunnel protocol with repository URLs of the form:

 svn+foo_bar://

After upgrading from svn 1.7.x to 1.8.1, these URLs are considered invalid, giving an error of:

svn: E170000: Illegal repository URL

This occurs on an 'svn up' or an 'svn checkout'. Changing the tunnel protocol name to 'foobar' (i.e. drop the underscore) appears to work properly, both 'svn up' and 'svn checkout' work fine.

0 votes

I just moved a subversion repository from an ubuntu linux 12.04 server running subversion 1.6.12 to an ubuntu Linux 14.04.1 server running subversion 1.8.8.

I have been able to export the code to an ubuntu 14.04.1 client running subversion 1.8.8 and when I do a
svn -u status
W155007: ‘home/xxx/src/trunk/c/eco’ is not a working copy

I get this error no matter what directory I do it in and it used to work fine before the move when we were running Ubuntu 12.04 clients with the old repository.

We are using apache2 with ssl for old and new repository.

0 votes

Is there a limitation in size on the property value that can be set? Any scalability traps to be aware of (i.e. non-linear increase in time due to increase in size of the property value)? I tried a 4Mb property, seems to work fine...

...