The History of the VCS

I’ve been looking for ways to convince more DBAs to use a version control system for their code. I realize that many of you have gotten along without them for years, but that doesn’t mean it’s a good idea. A VCS is like a safety net, and someday you’ll be glad you have one.

Recently I was reading about the history of VCS, and ran across some interesting posts. One on some amazing things, and another that has a timeline, showing us to be in a Renaissance period. If this is the Renaissance, then what comes next? I can’t even imagine, but I suspect someone will improve the process.

It’s incredible to think about the ways in which we’ve managed versioning code in the past. I’m sure most of us have used comments to both document as well as preserve old code. Some of us have worked with simple backups of files, one per day (for a week or month), or dealt with a first generation system where only one person could work with a particular file.

The move to CVCS systems, like TFS or Subversion, was a major improvement, allowing everyone to work on all the code, and merge their code with others when they needed to commit. That’s a system many of us inherently understand. It’s what we would do in an offline system. However the DVCS systems (Git, Mercurial), are much more complex, and they can be confusing. However separating the ability from committing changes to performing the merge can be valuable, especially in distributed development.

More and more tools are integrating version control, including for database code. Whether you like or hate TFS, it includes lots of additional functionality to allow bugs, features, and other workflow items to link to the VCS items that solve them.

The choice of which system works well in your environment will probably be driven by arguments from your development staff. Some will prefer one interface over another or feel the need to work offline, but I’m not sure it really matters which system you choose. I’d pick one of the modern CVCS or DVCS systems and use it.

That’s what’s really important; you need to use the system and track your code. It’s frees you as a developer, allowing you to clean up your code, remove excess comments, and easily find out what worked (or didn’t) in previous code.

Steve Jones

The Voice of the DBA Podcast

Listen to the MP3 Audio ( 2.9MB) podcast or subscribe to the feed at iTunes and LibSyn.

About way0utwest

Editor, SQLServerCentral
This entry was posted in Editorial and tagged , . Bookmark the permalink.