You have subscribed to "."

Come on Google, you can do better than this, surely?

Source code managers (and why Visual SourceSafe isn't one)

I'm sure every programmer's blog has an entry on source code control, but this one has been lying in wait for some time now, so it's about time I got it out into the world.

This started as a pitch to my manager, and I may be preaching to the choir a bit, but hopefully this post will sum up the main reasons for SourceSafe failing as an SCM.

The bit with the big statements

Source code control is one of the most important aspects of the software development process. It is the very interface through which we develop and change our code.

A source control system's central role is to allow and accommodate changes to a software project. It needs to encourage programmers to make changes, both large and small, without hindering them in any way.

If a project's source control system is substandard, the project is substandard. The code will not be changed in the ways that it needs to be changed, and the programmers will not be working to their full potential.

Visual SourceSafe is not a professional source code control system. If you want to be serious about developing software, you should not be using SourceSafe.

When I say "Visual SourceSafe" I am specifically talking about this atrocity:

That's right folks, this '95 era software is still being used to develop software. Trust me, I lived through it and have survived to tell the tale.

Source control has evolved a great deal in the last thirteen frickin' years, and I believe that SourceSafe's problems fundamentally undermine the software development process. SourceSafe is the bane of any programmer's existence.

The reason people still use it comes down to ignorance. Ignorance of how much better things can be. SourceSafe is not a tool used by professionals, it is a tool used by people that don't know any better.

Jeff Atwood of codinghorror.com writes:

The more customers I visit, and the more developers I talk to, the more I believe that SourceSafe poisons the minds of software developers.

Poison is exactly what it is, and I'm going to explain why.

The fundamentals

From a developer's perspective, source code control is about one thing: editing files. It's as simple as that. An SCM (Source code manager) can provide revision histories, diffing, merging and branching, but the primary goal is to let you edit your files.

In any SCM, changing files under source control should be no harder than changing ordinary files (i.e. files not under source control).

If I'm browsing through a file and I notice a spelling error in a variable's name, I should be able to make the correction right there and then, save the file, and be done with it. Just like I would if the file weren't under source control.

If there is anything else I have to do, I am being hindered by the source control system. And if I am being hindered from making changes, I am less likely to make them. Suddenly, making changes has become a chore. That spelling error has changed from an oh, I'll just fix that now issue to a forget it, it's not that important anyway issue. This is a serious problem, and it only gets worse when the 'quick fix' becomes a multi-file refactoring to improve the design of some component.

Of course an SCM will usually have an additional commit step after editing a file, but what's important is the moment of editing itself. If there is anything getting between you and making that edit, then the source control system has failed.

This same rule applies to renaming or moving files and directories. To rename a file that is outside source control, I might type mv old_file new_file in a terminal, or right-click Rename from Explorer. Renaming a file under source control should be just as easy (although the steps might be slightly different, e.g. svn mv instead of mv).

The ability to trivially rename and move files is essential when it comes to coding. If I can't easily rename a class or reorganize files into a sane directory structure, then I'm just not going to bother. The code base will suffer as a result.

SourceSafe makes it hard to edit files in many ways, the most important of which are:

1. Read-only files.
2. Explicit and exclusive checkouts.
3. Poor renaming and moving support for files and directories.

Read-only files

When I Get latest version... on a project in Source Safe, all the files are made read-only by default. This is an instant barrier. In order to make that spelling correction, I have to switch to SourceSafe, check the file out (and if someone else has checked it out, forget it), reload the file so my editor realizes it's no longer read-only, and then finally I can make this damned change.

With something like Subversion or Git, I just make the change. Right there and then, I edit the file and save it. Job done.

The point here is that a good source control system should allow checking a project out as a fully writable local copy. A developer should not have to explicitly check files out to edit them, because then editing files is harder than it is without source control. Source control should be transparent when it comes to editing the files themselves.

Explicit and exclusive checkouts

SourceSafe is designed to be used with exclusive checkouts. This means if somebody else has a file checked out, you cannot edit it. Although SourceSafe supports concurrent checkouts, nobody uses them. It just isn't designed to be used in this way.

The problems with exclusive checkouts are obvious. If I need to make a change to a file that somebody else has checked out, I have to wait for them to finish their work. This wait can often take days.

Even worse, if I'm working on a feature that requires this change, I am forced to make local edits to continue my work, and then manually merge these changes later on when the file is available.

To make local edits you have to override the read-only attribute to modify the file. When the file becomes available for checkout, you must make a copy of your edits, check the file out (overwriting your current version), and manually merge these changes back in because SourceSafe cannot do this. This is Elm Street material, people.

The only conceivable argument against concurrent editing (which I have heard being used) is merge conflicts. This argument is 100% B.S. (Bull Shit). Merge conflicts are a total non-issue. Even when you do encounter a merge conflict with another developer, it's a simple matter of choosing which change you want to keep. Sure there can be more difficult conflicts to resolve, but this is a rare occurance and can always be worked through.

Is Linux is developed with exclusive check outs? Or Windows? No, they aren't. Because merge conflicts are a non-issue, even with hundreds/thousands of developers. The benefits of concurrent editing far out-weigh any issues caused by merge conflicts.

Poor renaming and moving support

Renaming and moving files is another area where SourceSafe fails miserably. You cannot move or rename files as part of a commit. Instead you have to directly rename/move the file within the database file system (or whatever the hell it uses as a back-end).

This means at the point after performing the rename, all your code is broken because the source files haven't been updated to reflect the change. Cue frantic editing and checking in to fix the code before anyone does a Get latest version...

But wait, what's this? When I've finished doing the rename, if another developer updates their local copy of the source, the old files will still be left where they are, hiding errors with the rename! The word 'clusterfuck' comes to mind...

Another bug with renaming: if your rename only changes the case of the filename, when another developer updates their local copy, this rename will be ignored. Headaches ensue, and you're left with totally inconsistent filenames as a result. People just don't want to deal with SourceSafe's problems.

I'm weeping just thinking about it. My God, how did they get it so wrong?

Source safe causes nothing but pain and hindrance when performing even the most basic of tasks.

And another thing:

Destroy permanently!? What the hell is this doing in a source code manager? Epic fail.

Freedom and experimentation

If a developer wants to do a large experimental refactoring of some core module, how can he go about this? He can't check out files because he instantly blocks anybody else from working on them. He can't make local edits because it's impossible to manage. Creating a branch in SourceSafe is a major operation, and he probably has to go to his boss to get it done. He's not going to bother.

Experimentation and freedom are very important for developers. They should be able to refactor, or prototype, or just play around without checking out files.

In my own experience, when checking out files to experiment, I always felt like Big Brother (my boss) was watching me because everyone could see which files I was working on. I should be able to create a private branch where I can work on anything I like, away from prying eyes.

A good SCM needs to encourage experimentation, and give developers the freedom and privacy to work on features without blocking others. SourceSafe fails in this regard.

Corruption

Most discussions about SourceSafe will bring up the issue of database corruption. This article describes the topic in more detail, but I can assure you this happens. The SourceSafe database for the project I was working on was corrupt. If I tried to get a history that went back over 2 years, SourceSafe bugged out and left this message:

Files and histories were gone. This is scary stuff.

To summarize

The core point I'm trying to get across is that an SCM needs to make it easy to change code. If developers have to jump through hoops to do basic tasks, they aren't going to get done.

As soon as code is added to Sourcesafe, there is an immediate staticness to it. It's hard to rename or move things around. Exclusive checkouts make it difficult to make large changes to the code, or to experiment/prototype.

When I started a new project at my previous job, I put off adding the code to SourceSafe for as long as possible because it would make it harder to edit the code! This is a fundamental issue. With other SCMs, you just edit your code. Simple. No manual checkouts, no read-only files. It's easy to rename and move things. Concurrent edits are merged trivially.

The fact that SourceSafe makes things harder is ridiculous. Developers need to be using tools that help, not hinder. SourceSafe hinders in many ways.

These issues I've discussed were reflected in the code I worked with. The code base consisted of messy file names with inconsistent casing, huge monolithic files that needed to be split up but weren't, and developers like me that where totally discouraged from doing any kind of refactoring or redesign.

And this my dear readers, is why Visual SourceSafe is poison.

Links

• Antidote #1: Subversion
• Antidote #2: Git
• Source Control: Anything But SourceSafe
• Visual SourceSafe: Microsoft's Source Destruction System

Thistles... everywhere

So I just got my Macbook Pro FedEx'd to New Zealand, where I am currently a Willing Worker On Organic Farms (WWOOF). This means I've been milking cows, weighing lambs, weeding organic carrots, grubbing out lots (and lots) of thistles, and generally helping out on organic farms in exchange for good food and a bed to sleep in.

I'm 10 months in, and this has been a really great experience for me. Over the past few years I spent all my time on the computer, and I kind of lost touch with reality. I lost the balance between computer time and outside-world time.

I was stuck in a hole, so I quit my job and headed to the other side of the world.

Doing some good honest work outside has done wonders for my spirit. I've met a beautiful girl who I will spend the rest of my life with, and some day we will own some land of our own to continue the lifestyle we've experienced here in New Zealand.

Being away from the computer for so long has left part of my mind a bit... hungry. I started getting some serious programming pangs a couple of months back, and I was forced to write a wallpaper changer in html/javascript that ran on a Windows 98 machine as an ActiveDesktop object. I felt dirty, but it satisfied some primal instinct inside me. I realized I have a fundamental need to code.

Around the same time I started thinking about my previous employer, and the problems I saw there with respect to the software development process. My brain went into overdrive and I couldn't stop thinking about source control, bug tracking, user testing, and everything in between.

So I started writing again, and managed to fill over 20 pages of A4 with notes and thoughts about software development. In the long term I want to improve my writing and maybe even come up with some interesting and thought-provoking ideas. I plan on using this blog to accomplish this.