It's not Visual SourceSafe's v^Hfault

Lately, some people started blogging about a new source control system, Vault. I haven't used it, nor am I intending to do so. The reason is not that I don't like Vault or Eric Sink, but because I don't have problems with what I currently use, Visual SourceSafe (VSS). I personally believe Eric Sink knows what he's talking about big time, as his blogs are one of the few which truly show some vision on the total scope of software development, and therefore I think Vault must be a product that can live up the hype that is being build up around Eric's new source control system.

However (you knew there would be a 'however' somewhere, didn't you ;)), there is something that bothers me... a lot. It's not something new, because I've seen these remarks for years. It's about the quality of VSS. A lot of people seem to think it's crap: it should corrupt your files, it is slow, it can't keep up with the competition etc. etc. Well, I disagree. For the target audience VSS is meant for (and if you do not know what a target audience is, read Eric's marketing blogs or the books he mentions), VSS is an excellent product and works well. I'll tell you why. I'll also tell you why some people have problems with it.

VSS comes with visual studio enterprise and other enterprise variants. You can also buy it separately, however I don't think a lot of people do that. Most companies who have a team of developers use an MSDN subscription to save money and they'll receive a copy of VSS automatically. Microsoft didn't position VSS as a source control system which can be used to maintain the Linux kernel or other major software systems. It is positioned as a source control system for small to medium sized projects, you know, the average software project the average team of developers works on.

So we can safely (pun intended) conclude that VSS should be useful for the majority of software projects done with Visual Studio.NET. After all, loading a solution with 20 or more projects with a total of 1 million lines of code or more is no pick-nick either in Visual Studio.NET. A development team working on a project that falls into the 'average project' category should be able to work with VSS without any problem. How come a lot of development teams run into trouble with source control and VSS in particular and blame the problems on the tool with the most ugly and outdated installer on the planet: Microsoft Visual SourceSafe? Because they do not use it correctly, or better: they suffer from an organizational bug.

A while ago I blogged about concurrency control in databases and why functionality locking would be the best way to control concurrent access to database resources. Source control is not different: it also is about controlling access to shared resources, in this case source files, and maintaining a consistent state which can be called 'the current snapshot'. Be it source files or database records, it's all the same. But a lot of development teams do not understand this. They think a source control system can solve the problem of simultaneously made mutations to a shared resource element, like a source file. With tricks they can (most of the time), however in theory there always will be cases where simultaneously mutated source files can't be merged to a new consistent state. This is not the problem of the source control system, but of the users and the organization they're in.

I've seen development teams that check out everything when they arrive at the office in the morning and check in everything in the evening when they leave, even if they've changed just 1 file. Because everyone does this, multiple-checkouts has to be enabled. This is semantically wrong. If a file has to be mutated, one person should be scheduled to do that, another person who also wants to change that file should not be able to change the file also, he/she should delegate his/her changes to the person who is scheduled to change that file. This sounds theoretical BS and not usable in practise but that's not correct. It is useful in practise, and when delegation of work is done properly (and that's why project managers are paid that extra money, mind you!), more work will be done in less time: people should organize the work and thus the usage of the source control system, better. When you do so, a lot of problems with VSS will be gone and will not come back. Lesson learned: schedule work on shared resources properly.

Another problem a lot of development teams suffer from is the size of the VSS database. The documentation of VSS clearly states that the databases of VSS shouldn't be bigger than 1GB in size. If the database is bigger than 1GB, you should create a new database. This might be a little small, but 1GB of sourcecode and changes is a lot. I've been on a project where the VSS database the project was stored in was 8GB in size, it was stored on a 'left over' server (i.e. an old box with slow hard-drives) and the disks were almost full and heavily fragmented. It was slow and I mean really sloooo...oow. After I figured out the size of the database, I requested a new database for just my project. I exported the project, imported it in a new VSS database, on another server, and it was fast again. Lesson learned: keep VSS databases below 1GB

VSS databases are as any other database: if the disk gets corrupted, if hardware fails, if the server hardware isn't up to par, it will fall flat on its face. Admitted, VSS doesn't come with transaction support so you can't replay a transaction log to get a backed up database up to the state you were in prior to the crash. However you can work around this without much effort: backup the complete database regularly (that is, at least once a day), do consistency checks (with the tools that come with VSS, yes it has tools that help you administer the databases) regularly, weed out stale projects and move them to databases which are used for projects that are no longer in production, use proper hardware and OS and maintain that OS properly. Lesson learned: consider a VSS database vital to your organization and thus maintain it properly and use a dedicated machine for it or at least a machine that has a lot of power left for VSS, which also requires a system administrator who knows what VSS is and how to operate it properly.

When looking at other systems, VSS lacks some and gains some. If you consider it comes for 'free' for most development teams (because of the MSDN subscription), it's not fair to compare it to systems which cost thousands of dollars per developer. These systems are most likely worth every dime they ask you for it but do you need all the functionality of those systems when you can solve a lot of problems with the freebee system you get with your MSDN subscription (or other Microsoft subscription model)?

Do I think VSS sucks? Not at all. Personally I like it a lot and consider it more usable than for example CVS. Do I think Microsoft should update VSS? Oh yes. Not because it's not usable now, but because the integration with Visual Studio.NET can be better and VSS lacks some features which can be handy, like maintenance over the Internet (although you can solve that via VPN's for employees). Also some usability features could be added like multiple file merges instead of single file merges when you merge back a branche into the main tree.

I hope developers will look at the feature aspects of the source control systems, the price you have to pay for them and integration with popular IDE's when they talk about which source control system is better. I also hope those developers consider that, in theory, with proper management you don't need a source control system at all (although you'll loose change tracking). First get the management do their job, then get the tools in to streamline it, not the other way around.