Source Control

In order to create a UNIX image, you have to have:

  1. A kernel
  2. A ramdisk containing your root filesystem
  3. A init programme on the root file system which will start up all of your services.

Most of this only has to be compiled once, and likely isn't going to be updated on a daily basis. So most of these packages can be kept in tarballs and simply unzipped into your ramdisk when you're packaging everything up. It's your development software that you have to take some care in keeping track of.

I've adopted a version numbering scheme to keep track of my ramdisks. Basically it's a three part number: X.Y.Z, where "X" is the major release, "Y" is the minor release, and "Z" is the patch (no change to the system, just bug fixes or improvements on existing components).

For all of my development code, I use CVS to manage everything. Unfortunetly, CVS has its own internal versioning numbers that don't have anything to do with the version numbers of my applications. So I have to use CVS "tags" to make a snapshot of a programme and mark that to that programme's version number. Then that version number must be tracked against the version number of my ramdisk. This way I know that a ramdisk with a specific version number has what version of each software module.

Enter XML

I use an XML document to hold all of the info of my ramdisk image's changing programmes. By changing, I mean the applications that I'm developing and constantly upgrading and improving upon.

Here is a copy of my XML file with just a single entry.

Notice that there's a date and id attribute in the "version" node? That's used by my java application to only pull up the requested version of the image.

Java + XML

My Java application parses through the xml file looking for the version id attributed to the image. Then, depending upon the parameters passed in, it will output the xml node in a manner that can be interpreted by traditional UNIX utilities like awk.

Example:

peterb@tpgpete dist $ java -version
java version "1.5.0_01"
Java(TM) 2 Runtime Environment, Standard Edition (build 1.5.0_01-b08)
Java HotSpot(TM) Client VM (build 1.5.0_01-b08, mixed mode, sharing)

peterb@tpgpete dist $ java -jar ./basecvscontrol.jar -l 3.0.0 \
> ~/base_cvs_control/base_ver.xml
data2xml,basestation/data2xml,r_1-0-8,1.0.8,Route Tracker binary file converter
bt,basestation/bt,r_1-2-8,1.2.8,Bluetooth Application
resetbt,basestation/resetbt,r_1-0-1,1.0.1,Application used to reset the Bluetooth GPIO line
setdate,basestation/setdate,r_1-0-1,1.0.1,Sets the system date based upon Java style time stamps
xpath,basestation/xpath,r_1-0-1,1.0.1,Searches DOM elements based upon a directory-like search path
parse,basestation/parse,r_1-0-4,1.0.4,Converts the setup.txt to/from binary form for storage on NAND
resetmodem,basestation/resetmodem,r_1-0-0,1.0.0,Toggles GPIO line attached to modem's power
scripts,basestation/scripts,r_1-0-0,1.0.0,All of the bash scripts used in /usr/local/bin

Now I can parse that output with a simple shell script and awk to call "cvs checkout" commands to download the appropriate versions of each module.

Java + XML + XSL

Since my source control file is XML, I can also translate it into an HTML page for easy viewing. I use a stock java application and a XSL file to convert the xml file into an HTML file:

java -jar xalan-j_2_6_0/bin/xalan.jar java org.apache.xalan.xslt.Process \
  -in base_ver.xml -xsl base_ver.xsl > base_ver.html

Click here to see a copy of base_ver.html.