Version Control And The Developer
Volume Number: 14
Issue Number: 6
Column Tag: Tools Of The Trade
Version Control and the Single Developer
by Richard Wesley
How Version Control Can Make Your Life Safer and More
Productive
We Don't Need No Stinking Version Control!
So here you are, writing the next great application in your basement. Maybe you are
by yourself, or maybe like me you only have one other developer to worry about. Why
should you bother with version control software? After all, you are probably use to
being able to modify anything you want at any time, and the worst you might have to do
is yell across the room "Dave - I'm going to work on the filter code now, so don't touch
it until I'm done!" Why give up all this freedom?
This article will attempt to convince you that there are many practical reasons to use
version control, even if you are just by yourself. Here at Electric Fish, we develop
many small projects for clients that require only one developer, yet we use version
control for every project. This article is intended to introduce the basic concepts of
version control and discuss what specific problems it can solve for you, the small
developer.
In this article, I will present all the basic version control commands and discuss the
problems that they solve. I will be using the CodeWarrior Version Control menu
terminology as it provides a simple interface to an abstract version control system,
and I will using examples from various source control systems, including Projector,
CVS, Perforce and PVCS, all of which have CodeWarrior VCS plugins.
Basic Concepts
Version control systems are a means of tracking various versions of a set of files. Most
of them also include facilities for tracking groups of files (although PVCS does not).
All of them deal with the issue of interaction between developers, although there are
many different ways of doing this. All systems have some notion of a database that
stores the various versions of a file.
There is a general sequence of events that happens when you use most version control
systems.
• First of all, a database must be set up somewhere. This may be on a local
file system (Projector, PVCS) or on a TCP file server (CVS, Perforce) or
somewhere else. Generally, all you need to know is where it is. This is the
Connect operation.
• Now that you have a database, you need to be able to add files to it. This
includes all the files you have now and any new files you may wish to add. This
is the Add operation.
• Once you have files in the database, you need to be able to modify them.
Some systems require you to tell the database you are working on them, but
some (like CVS) allow you to just modify the files at will and submit all the
changes when you are done. This is the Checkout operation.
• If you change your mind, you may want to revert to the last state of the
file. This is the Undo Checkout command.
• Once you have made your changes and tested them, you need to put them
back in the database for safekeeping and so that others can see them. Generally,
this involves giving the database not only where the new version is, but also a
description of what you did. This is the Checkin operation.
• After all the changes have been made and the software is ready, it is
common practice to label all the file versions that go into the shipping version
so that they can be referred to later. This is the Label operation.
• At some point, you may wish to go back and look at older versions of a file
or groups of files, or you may simply wish to get the latest versions of all the
files in the project after a coworker has made some changes. This is the