Thoughts On Version Control Tools

Over the years I’ve used a number of different tools for version control, either as just a stand-alone place to store my work, or as part of an overall configuration management system (note: something like CVS or SVN is not a CMS, only part of a CMS).

Settling On CVS

After experiencing SVN, RCS, SCCS and ClearCase, among others, I’ve settled on CVS as my version control tool of choice. Why? Well, for starters, I prefer to have unique version numbers for each file in the source file set. I also like symbolic tags, a lot. CVS isn’t perfect, by any means, but I also have to admit that I like it because I know it.

Here’s a site with an interesting side-by-side comparison of CVS and SVN: SVN vs CVS. One should probably not take it all as gospel, but they do make some good points, many of which I agree with.

I’ve never worked on an OSS project with lots of contributors scattered around the globe. Odds are that I probably never will, as safety-critical embedded real-time software isn’t something that lends itself to the OSS paradigm, and that’s mostly what I do. In the environments where I spend most of my time the concerns center around being able to maintain comprehensive and accurate configuration records, generate RDDs (release description documents) that capture the configuration data, and if something should go wrong, provide enough information to trace back through the change history of any specific source module. CVS lends itself to this quite readily.

I also tend to be fad-adverse. I fought C++ early on, as I didn’t think it was something that anyone really needed, and I saw it as a kludgy add-on to C. I still do, actually, but that’s another topic for another day. I’ve also resisted SVN, not because I think it’s kludgy, but because I think it has a whiff of fad about it, and I don’t think it’s a really good way to get fine-grained control of configuration. It may change over time, and it may not. I’ll wait and see.

Extracting A File List

Now, with all that said, here’s a little shell script ditty for CVS that I came across a while back that will extract a list of modules with a given tag, ready to drop right into an RDD:

TAG=$1
CVSROOT_DIR=${CVSROOT##*:}

if [[ $# != 1 ]]
then
  print -u 2 "usage: $(basename $0) <tag>"
  exit 1
fi

cvs -Q stat -v | egrep "Repos|$TAG" | \
gawk '
{
  if ($1 == "Repository")
  {
    num=split($0,array," ");
    fileName = array[num];
    sub("'$CVSROOT_DIR'/","",fileName);
    sub(/Attic\//,"",fileName);
    sub(/,v/,"",fileName);
  }

  if ($1 == "'$TAG'")
  {
    split($3,array,")");
    rev=array[1];
    printf("File: %-70s\tTag: '$TAG'\tRev: %s\n",fileName,rev);
  }
} '

Tagging

With CVS it is important that a consistent tagging scheme is used, so I make it a point to devise a tagging scheme (if one doesn’t already exist). For daily tags I let cron handle it for me. For releases I manually apply a tag at the appointed hour, after all the low-level testing is complete, any remaining defect issues have been resolved, and the software has been built and tested successfully. Then I run the script above to generate my RDD file set list.

Advertisements

0 Responses to “Thoughts On Version Control Tools”



  1. Leave a Comment

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s




Follow Crankycode on WordPress.com

Little Buddy

An awesome little friend

Jordi the Sheltie passed away in 2008 at the ripe old age of 14. He was the most awesome dog I've ever known.


%d bloggers like this: