I recently helped a team to switch SVN servers and found a few gotchas along the way. This is a short guide on what worked for me and some stuff I tried that didn’t.

The reason for migrating to a new subversion server was that Atlassian shut down their hosted subversion service. The team had been dragging out on the migration for far too long (there was more than a year’s notice). When they asked me for help, there were only a few days left before the old service was shut down. They said that they had considered moving to git and that there was probably a server set up somewhere by the operations department.

I had a quick look at the repo and asked the team about their situation and found out a number of facts to take in consideration for a move.

A gziped dump of the repo was about 1.3GB

The repo had not followed the standard trunk/branches/tag structure. A few levels below a trunk directory I found another set of directories: trunk, branches, tags.

The repo contained code from different projects. Some legacy that were no longer needed, some being actively developed.

There was no time for a long service window. I basically had to get everything moved from one working day to another.

The pending changes list of TFS is a lie. It shows all files checked out for edit, not those with actual changes. A TFS power tools command can save the day.

A key factor of successful source control usage is to always review pending changes before check in. Without reviewing the pending changes it is far to easy to have unrelated changes slipping in with the commit.

Working with TFS, reviewing pending changes can be a pain because of the check out before edit model. Any file that has been touched, even with all changes undone, is listed as a pending change. I’m currently working with a large Entity Framework model where hundreds of files are regenerated on each change, even if only one of those files is actually updated with new content. Finding the actual changes among hundreds of false entries in the list is impossible.

The saviour is part of the TFS power tools (I can’t understand why it’s a separate add on and not part of the core TFS client.

The Pragmatic Programmer has a given place in my list of must read books for professional developers. The subtitle “from journeyman to master” explains the contents very well. The book is made up of short chapters with concrete advice on how to become a master software developer. The 70 numbered tips are short and look simple, but set a really high bar on the standards to strive for. Anyone following a majority of the tips would definitely be considered a master.

Have you heard about the DRY (Don’t Repeat Yourself) principle? This is the book that introduced it and has the original explanation and motivation for the concept. To be a book about software it is remarkable timeless. Most of the tips are as relevant today as they were 10 years ago when the book was written. Source control is now much more widespread than it was back then, but Tip 23: Always use source code control still applies. Believe it or not, there are projects out there without it.

In really old legacy code it is common to find comment blocks with complete revision history of each function and old, inactive code that has been commented out. It was fine 20 years ago, when version control systems where not wide spread. Today it’s a code smell.

An old legacy system I used to work with had a comment structure that looked something like the sample below.

The actual code was in C and not C#, but that doesn’t really matter – today’s topic is the comments. There are two things severely wrong with the comments in that piece of code. The number one is the version history. The number two is the commented out code block.

Do you really use Source Control? I’m not talking merely about having some code in a version control system. I’m talking about using source control as an efficient tool in your daily work. As a huge fan of the Joel Test I’ve put together my own 6 point test of source control usage:

The Anders Source Control Test

Is all of your code under source control?

Do you commit all of your changes, having your local copy and the repository completely in sync?

Is your source repository the master version of all code?

Do you know exactly what code revision that was used to build every single copy of the software deployed in production?

Can you make a bug fix to an old release and deploy it, without having to upgrade to the latest version?

Are all developers in the team comfortable with occasionally reverting all their working copy changes?

If you get 6 points you are definitely using source control. 5 points might do, but 4 or lower means that you are not using source control right.