5

Right now my company is using a network share to communicate with the SVN repository. It's really slow so I'd like to switch to SVNSERVE.

The main reason my company chose to go the filesystem route was because it made it easy to secure using our existing active directory authentication system.

From what I've read it is possible to use SvnServe with active directory as long as you use the Sasl library. I was just wondering if anybody else out there is doing this and could give some pointers on configuration since it doesn't seem to be documented anywhere.

Thanks

Edits

We have svn on a fast server but it is unfortunately used for other corporate file shares and services.

I'm being told that HTTP protocol won't be faster than file:// with SMB. Does anybody have any documentation of this. I figured a true client server model would perform better. We have about 13 developers and a build server committing and updating from it all day.

Richard
  • 627
  • 2
  • 9
  • 19
  • and you are sure the slowness is not from a pooly configured antivirus (that repeatedly scans the repository whenever someone accesses it?) – mihi Jun 24 '09 at 19:09

5 Answers5

10

Go the dead simple route and just install Visual SVN server.

http://www.visualsvn.com/server/

Install it on a server joined to your Active Directory. You now have SVN over http(s) with AD authentication. Manage permissions using the handy dandy MMC tool it comes with. From 0 to deployed in about 15 minutes.

Brian
  • 925
  • 2
  • 12
  • 20
  • 1
    +1 VisualSvn rocks. Correct term for "a server attached to your active directory" is a member server. You join AD, not attach to it. – Taras Chuhay Jun 23 '09 at 21:55
3

Be aware that file:// access is not recommended for SVN repositories, its more for admin tools. The problem with the file access is that you have no server in the middle to make sure all writes are written correctly. So stop using it ASAP.

Svnserve (or Apache) is much better but you will have the same performance issues - its not going to get better because your network uses http or svn protocols instead of smb. If your access is slow today, it'll still be slow unless you do something about your network or filesystem (or whatever else is making it slow).

However, migrating to Apache or Svnserve is worth doing in itself.

There is an issue with svnserve and the sasl libraries, as mentioned on the svn mailing list recently. The problem is that svn protocol doesn't allow plain text but plain text auth only is allowed by the saslauthd. End result - it just doesn't work, and is a known issue.

Its not all bad though, if you're running on Windows, just install VisualSVN Server. Its a top piece of packaging, and provides you with an Apache install, running as a windows service complete with snap-in management, and active directory authentication with just one click of a radio button during installation. You can even put acls on directories or files in the repo.

If not, I'd still recommend Apache as the configuration for it is better documented, and it does support LDAP auth (which works with AD). There's plenty of blog posts describing how to do this.

Performance of http instead of svn will be slower, but I doubt you'll notice it unless you install both side-by-side and checkout/commit a large directory. Try it - you can serve an Apache-served repo with Svnserve at the same time. (though I'd verify that claim before putting it into practice).

gbjbaanb
  • 3,852
  • 1
  • 22
  • 27
1

Sorry, no Svnserve with Windows auths. Still, I use Svnserve with SASL and manually manage the accounts because the number of actual programmers using SVN here is very low.

The fact that you're willing to risk Windows file sharing to do SVN shows you must be in a desperate situation, so I recommend SSL over Apache instead, where you can get Windows authentication. It's using SSL instead of SVN, but it's close enough. Here ya go:

  1. Turn off the file share.
  2. Install CollabNet Subversion Server (free). This includes Apache, which is how you'll access SVN from now on.
  3. Install mod_auth_sspi in Apache and set it up in the httpd.conf that comes with CollabNet Subversion server.

I run both HTTPS and SVN, but personally prefer to manually manage the SASL accounts so I can get the extra bit of speed of the SVN protocol, which is a bit faster than HTTPS.

1

In short, switching your SVN repository from a network share to SVNServe or Apache/WebDAV will not improve the performance of your clients. If anything, clients will see worse performance.

Of course, the above assumes that you're planning to continue running the repository on the same server that currently hosts it. If you move your SVN repositories to a more powerful server, you may see an improvement in performance.

Have you checked whether the current server is overloaded? Is it serving lots of non-SVN clients/files, too? If so, you will probably see an improvement in performance by moving your SVN repositories to a dedicated server. If you have multiple repositories on one server, consider splitting them across more than one server. (You can split existing single repositories into multiple repos, if needed, to help with this.)

Really, though, you need to figure out why the existing performance is poor. Analyze the load on the current server, first. Performance is usually limited by the capacity of some system resource, chiefly your RAM, CPU, disk I/O rate, network I/O capacities. Try answering these questions:

  • Is your CPU pegged at 100%, or do you have lots of free cycles? CPU usage may vary, but if it's averaging at or near 100%, then you may need more/faster CPUs.

  • How much free RAM do you have (by % of total)? How much swap space are you using (again, by % of total)? If your free RAM is less than 10%, you may be running out of RAM, which forces the system to use disk swap, instead. This slow everything down, but it's worse for you because the swapping competes with SVN activity for limited disk I/O.

  • How much data (bulk transfer) are you moving to/from your disk, per second? How many seeks per second is your disk performing? How long are your disk queues? Your server's disks should be rated for bulk data transfer and seek rates. (If not, you can benchmark them, yourself.) If your average transfer and seek rates are at or near the maximum, you need to use faster disks. If you're using RAID, add more disks in a way that increases performance. If you're not using RAID, start using it.

  • How much network data are you transferring to/from the server, per second? If that rate approaches 80-90% of the rated maximum (e.g., 10Mbit/s, 100Mbit/s, 1Gbit/s), you are probably hitting the limits of your network link. (Note that cheaper NICs or bad drivers can have substantially lower maximums--benchmark your link to be sure.) Try upgrading to a faster link, or see whether your NIC drivers support bonding (also called "link aggregation" or "channel bonding") for increased performance.

Given the answers to these questions for your environment, try increasing the capacity of any resources that are limited. This may mean a server upgrade or replacement, or possibly a network upgrade.

Ryan B. Lynch
  • 2,006
  • 1
  • 12
  • 13
  • I figured http or svnserve would be faster then a network share because it would only have to send diffs of files and have other client server optimizations. Can you document that the performance is similar? – Richard Jun 24 '09 at 20:59
  • You're not asking an answerable question, in your comment. The performance difference (if any) depends on which network file system we're using in the comparison, plus the local versions, configurations, etc. of both the web server and the filesystem. Even if we did establish a specific test, I'm not going to do all that work--that's your job. I would be shocked if you could construct "fair" benchmarks showing more than a 20% performance difference between Apache, SVNServe, NFS, and Samba, on the same OS and hardware. Two or three days work isn't worth a 20% boost, to me. You may differ. – Ryan B. Lynch Jul 31 '09 at 23:01
  • Why worse performance? Network share access is generally the slowest access method, in my experience, especially when you have several concurrent users - apart from the fact that you're risiking all your data... – MarkusSchaber Dec 08 '17 at 08:28
0

It's not exactly the same but I have a svn repo on a Linux server. The server is not running svnserve, but allows users to use svn over ssh. Since the Linux server is an AD member server and the users are from AD as well, this a pretty easy and safe solution.

wzzrd
  • 10,269
  • 2
  • 32
  • 47