Visual Svn Server: How to restrict edit by specified IP Address

Question

I want to enable only a specific IPAddess to edit (add, delete, update...) my visual svn server, but all others IPAddess must be able to read...

I believe it is necessary a change like this in the file %VISUALSVN_SERVER%conf\httpd-custom.conf

<VirtualHost *:80>
  <Location /svn>
    # write access
    <LimitExcept GET PROPFIND OPTIONS REPORT>
      Order deny,allow
      deny from all
      Allow from XXX.XXX.XXX.XXX
    </LimitExcept>
  </Location>
</VirtualHost>

but do not know well visual svn server. what is the right way?

Visual SVN Server 3.2 x64 is installed in Windows 2008 R2 Server x64

UPDATE from VisualSvn support

Such feature is not available in VisualSVN Server 3.2 out-of-the-box, however we consider the possibility to implement it in future versions. [...] Generally speaking, it is possible to implement IP-based restrictions via modifying httpd-custom.conf file, however we strongly discourage to take this approach. VisualSVN Server has "SVNPathAuthz short_circuit" option enabled, which dramatically improves authorization performance. The option has a limitation, though: server configuration mustn't rely on other authorization modules such as "authz_host_module" (which is responsible for IP-based checks), otherwise you will encounter unexpected behavior with authorization. On the other hand, if you disable "short_circuit" you will definitely notice performance degradation when running authorization-intensive operations against you repositories (such as running svn log, svn checkout, `svn export, etc or running a graphical repository browser such as the one TortoiseSVN client provides)

Answer 1

Since there's no built-in support for that in SVN, you may want to look for a workaround.

You could configure SVN server to use authentication, then allow only selected authenticated users/groups to do commits and leave everyone for read-only access. Security can be hardened in IIS and, SSL/TLS can be used easily and you could even detect and block brute force password attempts, if that's your main reason to consider IP filtering.

If for some reason IP filtering is a must, I'd suggest having another SVN Server instance (that runs on a different IP port) and do a repository copy to that instance (use svn dump on main instance, then svn load on your read-only instance 2). Then have your firewall allow commiters (that are filtered by IP) access the main SVN server, and all other IPs can access the read-only SVN server instance.

With svn dump and load you actually copy everything - all commits, history, comments, etc. You could do that as often as you like, and you can also bind these actions to the post-commit hook, to have it happen after every commit.