#include

Indexing a repository in Subversion takes a very long time. Especially if you have the Subversion repositories stored on an NFS and the size is over 15 gigs. Below are some performance improvements that worked for the repositories I’ve dealt with and some workarounds that might not have been previously documented.

For performance, if you have the repository on an NFS share that is also pointed to by the serving mechanism you should duplicate the repository locally using svnsync. This helps remove some of the overhead when dealing with the live filesystem on the NFS share.
Additionally, using PostgreSQL or MySQL in place of HSQLdb is always helpful! The new versions support these external databases, this reduces CPU usage immensely.
If you have a ton of code (who doesn’t?), tag versions, then remove the versions at some point in a single merge you’ll have to reduce the block size of the repository as it will eat a lot of Memory as it indexes all the files that have been deleted.

If you run into the problems with certain revisions not being indexed and the scanner getting hung in an infinite loop, and get exceptions like this:
com.cenqua.fisheye.rep.DbException
com.cenqua.fisheye.rep.RepositoryClientException
com.cenqua.fisheye.util.VisitorException
com.cenqua.fisheye.rep.DbException
sun.io.MalformedInputException

What you need to do, in Linux anyway, is set the LANG environment variable to UTF-8 and restart the Fisheye server. I had this problem and it took forever to find a solution to it. The environment variable was previously set to: UTF-8.en_us on the server I was dealing with.

I recently upgraded my computer to take advantage of a great deal at Fry’s. Plus the darn thing was running slow sluggishly even after upgrading the RAM to 6 gigs. I upgraded from an Athlon X2 3200+ to:
Intel Core i7 860
MSI X58 Pro-E Motherboard
6GB OC-Z DDR3 Ram
ATI Radeon 5770 1gb From XFX
Windows 7 Professional x64

When first assembled everything seemed fine. I ran memtest86+ to make sure the ram and everything was fine. I ended up getting a bad stick of Ram and had to send in an RMA to get it replaced. I will probably never buy OCZ Ram again, it seems so sketchy after my previous encounters with them. In any case, the computer is running much much better now and seems generally more responsive. I can run multiple Virtual Machines without problem whereas previously it’d slow down for the first and struggle with anything more than one. But I’ve got a small problem; see, the video card apparently has a problem that ATI is looking into (I will post my sources later) whereas the graphics are a bit glitchy and will eventually cause the computer to lock up and gray screen. This is really unfortunate because its been two weeks since the last revision of drivers and I’m currently stuck with a malfunctioning computer. I found a workaround though that might not work for everyone. I noticed the problem when running fullscreen 1920×1200 on my 24″ monitor but not at lower resolutions. When the screen was filled the top part of the screen would get random glitches/refresh problems and after about a day of running it actually crashed on my. I lowered the resolution to 1920×1080 and besides the black bars at the top and bottom of my screen everything is running well. So that might work if you have the same problem. Now to hope they fix this issue in the next driver release…

Update! The recent drivers fixed the problems. Now I’m back to full resolution without flicker and no crashes (yet).