Performance in Subversion vs. SourceSafe

Question

We're a distributed team of 5 developers working on rather large integrations project. We currently use SourceSafe (yes I know it sucks but it has just worked until recently and we've used it forever). Our biggest problem has recently become performance. Checking in and out project just takes forever and we're finding ourselves spending a lot of time just waiting for SourceSafe (yes we've turned off anti-virus check and all the other performance boost trix - it's still slow).

We're now looking into setting up and moving all our stuff to Subversion instead. How is performance in SourceSafe over the web compared to Subversion? I guess that the history isn't that important to move (we could just go back to the VSS database if we need an old file) and the the actually moving of files to Subversion should be a problem - right?

I'd also like to have some input on tools and add-ons that are "must have" besides the actual Subversion core tools.

Answer 1

Remote access is much easier with Subversion.

If you don't care about retaining your history, moving from VSS to subversion is also easy. You just have to manually delete the source-control bindings (*.scc files).

As for tools, you will probably want to get TortoiseSVN and maybe a plug-in for use with Visual Studio (if that's what you're using) like Ankh SVN (free).

Answer 2

If you do care about keeping your history, then http://www.pumacode.org/projects/vss2svn will convert from one repository to the other.

I've had very limited success with this and it's one of the reasons we still use source safe.

Answer 3

I agree with @relentless about subversion, but I prefer to use command line. It takes a bit to learn but once you've learned you will be faster.

Also, if performance is an important issue you might want to take a look at http://git.or.cz/, it is claimed to be really fast and reliable.

Answer 4

Based on my experience, it will be much faster.

I've not used the same large project in VSS and SVN, but I've done different projects in each, and migrated a smallish one from VSS to SVN.

Some things are much faster. In particular, checking in / committing a large number of files produces a warning message something along the lines of "this will take a long time and may not actually work? Do you want to try to do it anyway?" (This is not exactly what it says).

Committing a large number of changes is not actually really possible in VSS - you have to do multiple small commits, leaving the project in a temporarily broken state (although it doesn't have atomic commits anyway, so that would happen at some point anyway).

Answer 5

TortoiseSVN is indeed a very nice client, and I use this in combination with Trac on the server to have web access to the repository and a nice wiki / ticket system.

LiveCD - link.

Answer 6

You may also find this question relevant.

Performance

The major difference in how long individual operations take in SVN and VSS is in the SVN principle: time of the operation should be proportional to the size of the change, not the size of the project. This is best seen with Get latest version (VSS) versus Update (SVN). VSS "Get latest version" always iterates over all files in the project, checking their status. This takes very long. Compared to this, SVN checks the project history and only manipulates the files which were touched. In a typical scenario this a huge win, as most often only a few files are touched. Even when a file is touched, transferring the change is a lot faster in SVN than in VSS, because only changes are transferred, compared to whole file in VSS. The same is true for Commits (Checkin), where again SVN is a lot faster when doing small changes in huge files. This applies to binary files as well, as SVN is able to do differencing with those as well (using XDelta as its core differencing engine).

Most important tools

For a Visual Studio developer the most important tools are:

• TortoiseSVN - access the repository via Windows Shell
• AnkhSVN - Visual Studio integration
• some also recommend VisualSVN as VS integration, but I think with AnkhSVN 2 the integration is already good enough

I even go as far as saying having TortoiseSVN and AnkhSVN you do not need "Subversion core tools" installed at all. Core command line tools are extremely useful e.g. for automation, but for general everyday work I am never using them and installing them is not needed for TortoiseSVN or AnkhSVN to work.

Web access

Access over web is supported natively by SVN, and is supported extremely well. For VSS you need external applications for this and while they are not bad, they are not 1:1 to the original environment, and their speed is still somewhat lacking.

How to convert

The VSS2SVN is a tool which performs the conversion reasonably fast and reasonably well. Based on our experience I would strongly recommend not using the "stable" build, use a daily snapshot instead - it is able to handle many items in the history which make the previous build failing completely.

We have used the recent daily build successfully with a huge database with long history and the result was very good.

Answer 7

The check in of VSS is called commit in SVN. This operation is many times faster, as SVN will only transfer the changes (aka the "diff")you made to the files, while VSS will send the whole file and difference it on the server.

the check out in SVN (getting an initial workingcopy) is somewhat slow in comparsion to other systems, if you are using http(s) and have a large (>100MB) overall size of files. SVN worst case is lot of files and directories, as HTTP-transfer will be much slower than big, single files.

However, I doubt that VSS will be faster than SVN. Overall performance of SVN is faster, more robust(no database corruptions) and easier to understand than VSS.

Nice Tools are TortoiseSVN(Explorer Plugin), smartSVn(VSS-lookalike) and commandline(flexible) as Tigraine added in my comments:AnkhSVN(Visual Studio Integration) and subversive/subclipse for eclipse IDE

Answer 8

Visual SourceSafe is built on top of file sharing. So when you book in a file everything is done using the file system. So instead of just sending the files text to a server and everything happening remotely VSS accesses physical blocks from the disk when accessesing the vss server. Including looking up the file in the shared disks directory etc... This is roughly 10 times slower than a client server bespoke protocol.

There is a product called SourceOffSite which adds a faster front end to the VSS database which makes VSS usuable over slower links.

Tony