Into the world of version control with Root

You’ve probably run into the problem of controlling and managing resources on projects large or small, whether they’re source
code, HTML pages, XML data, binaries (images or compiled files, for instance), XSL stylesheets and so on.
Root has started
publishing A Trip into the World of Version Control, a series on possible solutions. Its motto puts it well.

There’s no shortage of tools that track project versions and let you go back
in time. In this series we’ll first see what
RCS is and how it works. Then we’ll dive deep into CVS, and
finally, with luck, surface, take a deep breath and talk about why CVS is far
from ideal and what to do about it.

As of today, April 25, 2003, the series has five parts.

• A Trip into the World of Version Control I gives
  a first glimpse of the subject and introduces
  RCS.
• A Trip into the World of Version Control II continues
  with RCS, specifically branching, locking files and revision states.
• A Trip into the World of Version Control III
  covers more features, including merging branches and why and how conflicts arise.
• In A Trip into the World of Version Control IV,
  the author starts to say goodbye to RCS and shows us some handy magic
  keywords. The piece ends with a historical note on
  SCCS.
• A Trip into the World of Version Control V
  is a first look at CVS, which the author calls
  RCS on steroids.

I can only speak from experience about CVS, but I
can no longer imagine developing a larger project without it. A few practical
examples will show why. I decide to release a new version and tag
the relevant source in CVS, say as 2.14. That version is checked out, built and distributed while I work on new requirements. A
week later a customer reports a bug in 2.14. In CVS I can check out the source
for that version, make a branch for the 2.14 fix, change the code, commit the change to the fix branch and, if the feature is still supported in the main development
branch, merge the change there.

There are plenty of other examples. I can compare my local source files with the repository
and see what I’ve changed and where. I can look up a file’s history to find
who changed it, when and how, along with their comments. CVS
can put information such as a version number in the file itself, which is useful for checking file versions at a customer site.
For example, an XSL stylesheet can check its own version on each transformation
against the recorded current version. You could also write a script in Ant or make and run it automatically for each release to fetch source
files, put them in the right distribution directories, compile them and send the result to beta testers.

The article might give you the impression CVS needs Linux and everything runs from the console.
That isn’t quite right. There are clients for most platforms, as well as plenty of ordinary
graphical clients that are easy to use. I use
WinCVS, for instance.

The series is still going. I’m looking forward to the next parts and hope to write about them.