This may be considered heresy by some, but for the first twenty years of my programming career, I never used a version control system. In fact, I barely even knew what one was.

I’d heard of CVS, and I knew that there was something called Visual SourceSafe in Visual Studio, but I never saw the need for them. They seemed to be nothing more than an odd way to back up different versions of source code files, and I handled that with archive files and regular system backups. Later I learned that they could be used to coordinate changes by multiple programmers, but that made little difference to me, since I was almost always the only developer on my projects.

But in the past few years, I’ve come to realize that version control systems are useful, even to me, in several ways:

• They let you “roll back” some (possibly extensive) changes that you later realize were misguided. This hasn’t happened to me often, but when it does, this ability saves a lot of time and effort.

• They keep a full history of different versions of your software, which is very useful for narrowing down which changes caused a particular problem.

• The more recent ones are far more efficient at storing multiple slightly-different copies of files than having archives of different versions. This becomes a lot more pronounced as your projects get larger.

• They let you record exactly why you made a particular change. There’s no longer a need to rely on fallible human memory or clutter up your code with long comments describing the changes (which you can never put in all the places you really need them anyway).

• They let you “tag” specific sets of file revisions. For instance, you can create a tag called “Version 1.00”, which contains all the source code files for your project as they were when you released that version.

• They let you create “branches” of your code, and later “merge” them. This lets you have, for example, a maintenance branch where you can fix any bugs in the last released build of your program, and simultaneously keep a development branch for the next version, and easily merge any code-fixes you do on the maintenance branch into the development branch.

I’m sure there are other good reasons, those are just the ones that I’ve come up with so far.

Unfortunately, few of these reasons are immediately obvious, and there’s a noticeable learning curve to using a version control system. It wasn’t until I recently read Eric Sink’s “Source Control HOWTO”, and worked with one for a while myself, that I began to really appreciate them.

The one I decided to use for my own projects (at least for now) is Subversion, a.k.a. SVN, with the RapidSVN visual tool to make things easier to see. (One good reason for choosing it is that it’s easy to create and back up local repositories with it; another is that it’s easily available on most operating systems.) Here’s how I set up version control for a project:

• First, I create the repository. I have a separate repository for each of my projects, all stored under a subversion directory (repositories can hold multiple projects, but unless they’re related I don’t like doing that). RapidSVN doesn’t handle the creation of repositories, so I have to fall back to the command line for that. For Cpp-Markdown, for instance, I used the command:

  svnadmin create /home/headgeek/subversion/cpp-markdown

• Then I add a “bookmark” for the repository into RapidSVN, by right-clicking the root “Bookmarks” item in the left pane and selecting the “Add Existing Repository” option.

• Next, I create the trunk, tags, and branches directories in the new repository, by right-clicking in the right-hand pane after selecting the newly-added repository. The trunk directory is where the latest development copy of the source code is stored. The tags directory is where particular groups of revisions are stored, such as a specific release or maintenance version number; more on this below. branches is where branches off of the trunk are stored (something I understand in theory, but haven’t needed to use yet).

• Then I select the trunk directory in the left-hand pane and import any existing source code into it, using the Import command on RapidSVN’s Repository menu.

• In the case of Cpp-Markdown, since I’d already released version 1.00 before I added the project to version control (I know, naughty me), 😉 I immediately create a tag for it. In RapidSVN, that involved selecting the trunk directory in the right-hand pane, right-clicking it, and selecting Copy.... For the destination, I put tags/1.00, and violà! A copy appears there. Any time I need to refer to that version of the source code for any reason, it’s right there, unaffected by any later changes I might make to the code.

• Finally, I create a working copy of the current trunk, where I’ll make any further changes, by selecting trunk in the left-hand window, right-clicking it, and choosing “Checkout New Working Copy”.

Now I can start using the repository. Whenever I make a change that I want to keep, I fire up RapidSVN, select the bookmark for the working copy that was created in the last step, select the files I want to send to the repository, and commit them via the right-click menu or the toolbar icon. That’s all there is to it. 🙂

(Well, okay, there is more to it — but that’s all that I have to worry about for now. Anything else comes into play when I have specific needs, like comparing different branches, and if I don’t already know how to do it, I can “page-fault it in” then.)