Why I hate Visual Source Safe

Recently I was working on-site at a client's office on a small PHP project. There was one other developer working on the project with me, one of the client's full time people. The client (who shall rename nameless, but suffice to say everything went well and this is not at all a gripe against them) was a solid Windows shop, unfortunately. Windows XP on the desktop, Windows Server 2k3 on the back-end, MS SQL Server running the database. That also meant Visual Source Safe for source code management.

Now, I've used VSS before. It's not horribly bad. The main problem, though, is that it is a lock-based source code manager. CVS, Subversion, and assorted others (vis, those popular in Free Software and Open Source circles) are merge-based. That is, in VSS every person on a project checks out one file from the repository at a time, and then he is the only ones who can edit the file, period. Once he checks in the file, it's flagged as read-only on his local file system. Other developers can then run a "get latest version" to update to the newest version of any files they have, or that's done automatically per-file when they check out a file someone else has checked in.

In contrast, merge-based code managers (e.g., CVS and Subversion) have everyone check out an editable copy of the repository (or HEAD, anyway) at once. Everyone then makes their changes and saves them back to the repository. If there's a conflict, the software can do some smart merging. (I added 5 lines to the top of the file, Bob added 5 lines to the bottom, so just make both changes and save to the repository and Bob's your uncle... as well as co-worker. Now that's just weird.) If that doesn't work, let the user sort it out because the user is way smarter than the computer. Of course, that works best when you commit early and often.

So what's so wrong with lock-based source code managers like VSS? Well, there's the hassle of having to re-checkout a file every time I need to edit it. Not a huge hassle, but a hassle. The bigger one, though, is that we were lucky that I was just down the hall from the other developer. There wasn't a day that went by when we didn't have to walk down to the other's office to ask the other to check in some file so that we could edit it. It generally wasn't a file that would have had a conflict, either. The most common was our translation file, a simple XML file with keyword-to-localized strings in the languages we were supporting. All either of us ever did was add new lines to the bottom. That's hardly something that would cause a major conflict, yet we had to do the checkin/checkout dance every day.

Fortunately we weren't far enough away from each other that it became a cardio-vascular exercise, but had we not been in offices only 100 feet from each other it would have been a major stumbling block. I'm glad there were only two of us working on the project. 3 or 4 people and we would have had a complete deadlock mess. And if he'd been on a different floor? Or a different building? Or, heaven-forfend, in another city? Since the company didn't allow IRC or IM through their firewall, that would have meant a lot of emailing just to ask each other to check in a file. My time is better spent than that.

Is it any wonder that Open Source projects (which are very frequently widely distributed) use merge-based tools? I like my Subversion. It makes me happy.