June 13, 2009

SCM in Review

In this article, I provide a brief overview of Source Code Management/Version Control Software and why every developer needs it.

Target audience: Developers who don't know about (or don't use) version-control. If you are a developer, you must use version control software! (Sorry for shouting; I'm emphatic about this.)

Overview:
Source Code Management (SCM)--aka Version Control Software (VCS) or Revision Control--is used to maintain a revision history for some set of code (or any other version-worthy stuff). Note: in this article, I will use the acronym VCS because of other uses of the acronym SCM.

Motivation: (or... So what's all the fuss about version-control?)
Whichever model you choose, version-controlling your software captures not just the current state of the code, but a revision history of the code. This is useful for several reasons:

1) It lets you rewind changes! Let me start with an example... The class was Artificial Intelligence Concepts and the term project was creating a game-with-AI-player in LISP. I didn't know LISP when I started, so let me assure you the original game implementation smelled pretty bad. So, in the middle of term-project "crunch time", I happened to get fed up with some of the old code and started "fixing it up". Lo and behold, the game breaks and I can't for the life of me figure out why. Luckily, I was using VCS. Using the revision history, I found a revision/version of the game that was working correctly. I then put all the broken code in an "experimental" branch and reverted back to the working revision. I then incrementally merged changes from the experimental branch to the "baseline" code. Without revision control, I would have been screwed; possibly having to start completely over at the last deliverable/project submission.

2) It stores "meta" information about current and previous states of the code. Some of you may be familiar with the practice of annotating small code-changes you have made with initials/date. You know, something like this:
foo++; // EIB 2009-06-13 - forgot to increment the foo.
... While this may have merit as a form of bookmarking (but why not just use your IDE's bookmark features? ... you're using an IDE, right?), it can easily get out of hand. Alternatively, how do you track code changes for someone who isn't inclined to leave these little blurbs? Again, with an annotated revision history, you get all the following automatically:
  • You can see who did what when (who changed what and when they did it).
  • You can review old/previous versions of the code.
  • You can do a side-by-side comparison (aka diff or "diffing") of what so-and-so did on such-and-such a date. (This feature is especially useful for doing code reviews.)
  • You can explicitly refer to particular revisions/versions of the code. For example: Release 1.6R3 of product FOO corresponds to revision 1234.

You can also leave messages when you do change things (because the change itself is rarely self-explanatory). For example, in the revision history/logs you may find something like:
EIB 2009-06-13: (foo-bar component)
I forgot to increment the foo after each razzamatazz; this fixes bug #1234
(Note that the code can be left spotless and undistracting, and the "commit" message as verbose as necessary.)


Where do I start?
There are two revision control paradigms (models): Client-Server and Distributed. The client-server model has been around since before the 1980's; the distributed model is a more recent idea with most of the distributed VCS's being developed in the early-to-mid 2000's... I won't recommend which model to use, since each paradigm has its own advantages/disadvantages and each implementation has its own quirks/strengths/awesomeness. That being said, I prefer Subversion: good features, good documentation, good clients, and--more importantly--free. (I don't think anyone should pay for VCS these days...)

Required Reading:
How 'bout I let you out of class early today?


Stay tuned for more posts about version-control software, including a review of three common software packages: CVS, Subversion, and Mercurial.

No comments:

Post a Comment

Was this tip helpful? Do you have any related experiences?