What happens if I add a symbolic link to subversion?

I’d like to add a symbolic link to subversion and when I do a checkout all it does is add the same symbolic link right to my checkout but I’m afraid to add it if that’s not what happens.

  • How do I restrict Apache/GIT access to specific users (ldap/file-based authentication)?
  • SVN: Moving repository trunk to another's branch (with history)
  • How can I change the revision number of a repository in Tortoise SVN?
  • Subversion protocol performance
  • What's the best way to version control graphical assets on Windows?
  • How do I check out an SVN project into Eclipse as a Java project?
  • Enable password in both commit and checkout
  • Ignore file in Subversion removes old values from svn:ignore property
  • Use local Git repository with a master Subversion repository
  • How to add an existing folder with files to SVN?
  • Copy a whole directory with phing
  • How to deal with Git-svn when have to use both Git and Subversion
  • 7 Solutions collect form web for “What happens if I add a symbolic link to subversion?”

    It’ll work as long a you’re on a Unix/Linux based platforms when you check it out. Good luck on Windows since it does not support symbolic links.

    See the note on this page in the SVN Book about symbolic links for more information.

    Windows Vista, Windows 7, and Windows 8 all support true symbolic links on the NTFS file system1. These symbolic links are entirely compatible with Unix file system symbolic links

    I want to emphasize the above. Too many people wrongly believe that Windows doesn’t support symbolic links.

    This misinformation comes about because Windows 2000 and Windows XP did not support symbolic links. They supported Directory Junction Points, but not POSIX style symbolic links. Even more weird, neither Windows 2000 or Windows XP came with the required linkd command to create these Directory Junction Points.

    This is no longer true. Windows Vista, Windows 7, and Windows 8 not only support symbolic links, but also come with the required mklink command. These symbolic links are compatible with POSIX compatible operating system symbolic links (Mac OS X, Linux, Unix)

    Now to the heart of the problem:

    Although Windows now supports symbolic links, and those symbolic links are compatible with Unix/Linux/Mac symbolic links, Subversion itself does not support symbolic links on Windows. I have no idea why this is the case.

    I don’t recommend putting in symbolic links into the repository, even if you only work in POSIX style OS systems and not Windows. Instead, you should have your build and/or deploy steps create any required symbolic links. This gives you more flexibility since you can test your OS during a build or deployment and handle any issues.

    Plus, creating symbolic links during the build/deploy stage creates less maintenance headaches than having it in your repository. Imagine if I rename, move, or delete a file that has a symbolic link pointing to it in my repository. I have to also remember to look for any symbolic links and modify them too — something that’s not likely to happen. After all, it’s impossible to look at a file and know all of the symbolic links that maybe pointing to that file.

    So as a recap:

    • Windows supports symbolic links where are compatible with POSIX style system symbolic links.
    • Subversion still does not support symbolic links on Windows.
    • If you want symbolic links, create them during the build/deploy part of your process as part of your build/deploy scripts, and not as a repository artifact.

    1. Yes, I know that the FS in NTFS stands for file system.

    Nothing happens if you add a symlink from Linux or other POSIX OS. It just works.

    But when you try to add a symlink from Windows, you will see

    C:\repo>svn add test_link
    svn: E200007: Symbolic links are not supported on this platform
    

    I guess that’s because Windows requires UAC to create a symlink. If Subversion allows symlink on Windows, UAC will break normal svn up.

    Well…I’m not sure of the technical answer or what the ramifications might be, but I just tried it. I created a sym link to a dir in a checkout I had. Added and committed it. Nuked the whole checkout. Re-checked it out and the sym link is still there with the appropriate link.

    Hope that will suffice for your worries 😉

    Maybe I missed it in other answers but thought I might add.

    Windows 7 client:

    TortoiseSVN 1.8.7, Build 25475 – 64 Bit , 2014/05/05 20:52:12
    Subversion 1.8.9, -release

    Linux client:

    svn, version 1.6.17 (r1128011)

    Symlinks not only ‘survive’ but they can be created and edited in the repository from Windows. You just need to make a file with the following content and an SVN property of svn:special = *.

    link name_of_source_file
    

    When you check this out with an SVN client which knows how to create symlinks one will be created for you. The Windows 7 client creates text files but the Linux client creates symlinks.


    In response to zb226’s comment:

    “An SVN client which knows how to create symlinks” is a binary which has been built from source, which has been written to use a function, which knows how to create a symlink, in a file-system which has a concept of symbolic links.

    A quick look at the Subversion source of 1.8.13 shows on line 608 of io.c it using the symlink function which I’m not aware of existing in standard Windows libraries.

    Another answer points out there is a program called mklink which can be used to create a symbolic link on Windows1. In C and C++ normally you would include a library instead of calling out to a program which may or may not exist. It does look like Microsoft has a similar function called CreateSymbolicLink but it looks very immature. I can’t see anything about whether it works on NTFS which is what 99.9% of SVN working directories will be backed by on Windows I expect. It does mention ReFS but I don’t imagine that will be commonly used for a good while yet.

    In summary it looks like the availability and stability of symbolic links on Windows with NTFS is not there, so Subversion developers have not added code to make use of Windows equivalent commands yet.

    When (or if) symbolic links become an every day part of Windows I expect they will make it into the Windows versions of Subversion clients. Most people I know who only work on Windows don’t even know what a symbolic link is and of the people I know who work with non-Windows OSes few are aware that Microsoft are experimenting with them.


    1. On the documentation for mklink it states this applies to “Windows Vista, Windows Server 2008, Windows Server 2012, Windows 8” and oddly omits Windows 7. I assume it actually means that it exists and works only on specific versions of Windows which have specific versions of NTFS which support symbolic links. I don’t imagine symbolic links have always existed in NTFS.


    I’ve just noticed Github’s Git for Windows client supports Windows NTFS symlinks. They even provide instructions on how to enable it! Another nail to add to Subversion’s coffin.

    When a symlink is committed into a Subversion repository, Subversion remembers that the file was in fact a symlink, as well as the object to which the symlink “points.”

    When that symlink is checked out to another working copy on a non-Windows system, Subversion reconstructs a real filesystem-level symbolic link from the versioned symlink.

    But that doesn’t in any way limit the usability of working copies on systems such as Windows that do not support symlinks. On such systems, Subversion simply creates a regular text file whose contents are the path to which the original symlink pointed. While that file can’t be used as a symlink on a Windows system, it also won’t prevent Windows users from performing their other Subversion-related activities.

    Taken from svn-book

    The faq says the reason that symlinks aren’t supported on windows is that by default only administrators can make symlinks.

    Git Baby is a git and github fan, let's start git clone.