Upgrading a VERY old SVN Repository

Question

We currently have an SVN Server, using VisualSVN Server as our front-end server, and most clients are running both VisualSVN Visual Studio extension and TortoiseSVN.

The current repository we have is going back a while... it was created, by my guestimate, around 2006(!), and the format file says it's Version 1... which seems to be a pre-1.5 repository...

We are in the process of moving servers around and one of the servers being upgraded is the SVN box. Last time we did an upgrade, we just did a svnadmin hotcopy on the repository folder, installed a fresh install of VisualSVN server on the new machine, copied files over, pointed stuff in the correct direction and, well, it worked...

With this new upgrade, I am wondering what we can do to the repository to give it some new life? Speed increase, less space taken up (the whole repository currently weights about 13Gb), and well, more performance. I know I said performance / speed twice, but given the old machine we upgraded from was a 32bit P4 with about 4Gb ram (3.6Gb usable), and the new box is a Quad Core Xeon with 32Gb RAM and we have pretty much the same speed as we originally did, it would be nice to show something, speed wise, from the upgrade...

Any ideas?

Lunchroom

I've done a fair number of hardware upgrades for Subversion servers that serve 1000s of developers and the performance is always much improved. What is the load like? How is the CPU and memory usage on the new server? What's the benchmark? – Giblets

load is quite low... not over about 5-10% most of the time... the new box has full access to a Quad core xeon with the full 32Gb of ram. it will, eventually, be on a VM. the old box has been disposed of, so i cant run tests between it and the new box... The only other difference i can think is the old box was RAID 1 (2 500Gb 7200RPM hdds) but the new box is RAID5 (4 250Gb 7200RPM disks). The test box has its storage on a RAID 10, but is completely virtual with 4Gb of real Memory, and a max of 8 (HyperV). not done any performance testing on that though... just testing of the repo... – Lunchroom

Yeah sounds like a good spec, I would think that should perform much better than the old 32bit P4. Without a direct comparison of checkout times or some other metric it's hard to define what the performance should be. Also be good to check the spec of the clients doing the tests. For windows clients make sure they're on the very latest 1.6 release or any of the 1.7s – Giblets

Answer 1

See the Subversion 1.6 release notes at http://subversion.apache.org/docs/release-notes/1.6.html#repos-upgrades.

Apache Subversion 1.7 uses the same repository format as Subversion 1.6 so the entry also applies to SVN 1.7.

There are two options to upgrade the repository format:

• You can perform a dump / load cycle on the repository. This can result into a smaller repository size and overall better performance,

• You can upgrade repositories format with a command-line: svnadmin upgrade <path-to-repository>. Upgrading to the current repository format can result into a smaller repository size.

Stcyr

have tried running svnadmin upgrade <repo> on the repo, but it finished very quickly and did not seem to make any difference... the format file was updated to 4, but the size of the repo has not changed... anything else that should happen? Also, that "upgrade" is happening "offline" on a test machine, so no users are hitting it... yet... – Lunchroom

@Lunchroom This is expected behavior: Subversion just bumps format number and sometimes creates indexes/files if neeeded. But you may get better performance if you dump/load your repository. – Morlee

cool. thanks for the note. will try that and see what happens. – Lunchroom

So, we have been moving repos around the place, and have moved one of our projects to a brand new SVN Server, and the speed is excellent! very cool stuff! thanks again for the tip on the dump/load cycle! worked like a charm! – Lunchroom