Concepts

Associated with each file that's under Version Control is a revision history, which is the set of changes (commonly called deltas) from the initial revision. This set of changes can be linear (a steady progression of revisions from the initial one), or it can be a tree, with many different variations floating around. In CVS, each revision in a file's history has a revision number, of the form X.Y, where X is a branch number (more on branches later), and Y is the version number in that branch. Here's a sample history listing for a file:

----------------------------
revision 1.3
date: 1999/04/19 03:04:04;  author: philg;  state: Exp;  lines: +32 -14
adding anti-spam proofing.
----------------------------
revision 1.2
date: 1999/03/05 07:23:11;  author: philg;  state: Exp;  lines: +30 -8
changed the bboard to do generic file uploading
----------------------------
revision 1.1
date: 1999/02/27 06:32:09;  author: jsc;  state: Exp;
branches:  1.1.1;
Initial revision
----------------------------

The Revision Numbers are the 1.1, 1.2, and 1.3 values. 1.3 is a newer revision than 1.1. The lines value is the number of lines of text added to the previous revision, and the number of lines of text removed from the previous revision.

Labels

Labels are names that apply to a certain set of revision numbers, one per file. Labels are used to "tag" the set of files under version control at a certain point in time, or with a certain stable set of functionality. For instance, when producing a beta version of a piece of software to deliver to customers, you would label the source code with a name like "Version 2.1, Beta 4". You can then recreate the source tree for the beta at any time afterwards. If you were now working on version 3 of the product, and wanted to see what was in Beta 4, you could check out the files as they existed when Beta 4 was produced.

Labels are also handy development tools. You can make a label of the current set of revisions before you make radical changes. If the changes don't pan out, you can easily revert to the label you created and start again.

Branches

In many probjects, you'll end up branching your files. That just means that a particular revision can become the base revision for more changes.

As a concrete example, say you have a source.c file. You make changes and check in versions. Release 1.0 is made. More changes are made and checked in. Release 2.0 is made. A hgh-paying and valuable customer finds a problem in 1.0 and needs a fix, but isn't ready to upgrade to 2.0 yet. You can make a branch off of the 1.0 revision and make changes and check them in to the version of the code as it existed back then. Since this work is occuring in its own branch, it won't affect the 2.0 work that's going on in the main trunk.

Branch file revision numbers usually have the form of A.B.X.Y. A.B is the version the branch is created from, and X is the new branch number, and Y is the revision number in that brach. Sample revision numbers are like 1.3.2.5, that is, the second branch of code, using revision 1.3 of the base; and this is the 5th new version in the branch.

Many version control systems (CVS included) have features to allow the merging of branches. Some shops have exploratory development occur in branches (so they won't affect anyone working out of the main trunk), and then merge their changes over at one time.

The Revision Tree

You'll frequently hear of something called the Revision Tree. This is the set of all changes. The most recently checked in version is called the tip, which like the tip of a living tree, is where new growth occurs.

Here's the revision tree for a ficticious file called "ham.c" that's one component among many in a large software project called CheeseSoft. The revision numbers are listed in their branches, and label names are in italics.

ham.c started out its life as revision 1.1. Some changes were made and checked in, leading to revision 1.2. At that time, as the product was being released as version 1.0, the source tree was labeled with v1.0. Now, anytime someone checked out a source code tree with label v1.0, they'd get revision 1.2 of ham.c.

Work continued on CheeseSoft. Two revisions of ham.c were checked in, and versions 1.2 and 1.3 of the product were released. Since ham.c didn't change between product versions 1.2 and 1.3, the same file revisions (1.4) has two labels.

At this point in time, someone discovered a really bad problem in CheeseSoft 1.0 that had to be fixed. Rather than take revision 1.4 and modify it to the same state as 1.2, and then put those fixes in the main tree (which would be a dumb idea anyway), they made a branch of ham.c off of revision 1.2 to fix the problem. A Beta 1 of CheeseSoft 1.0.1 was released. While that was being tested, more work was being done in the branch, as well in anohter branch to make beta 2 of CheeseSoft 1.0.1. Finally, CheeseSoft 1.0.1 was released, with revision 1.2.1.5 of ham.c being the one included.

While all of that was going on, work on a 2.0 version of CheeseSoft was progressing. The programmer Bork decided to create a branch of his own to do exploratory development, which (while not shown here) was merged back into revision 1.7 for ultimate inclusion into the 2.0 version.