Code audits. So a bunch of rogue companies and their ill-doings force us all to now comply with a small change to the U.S. securities laws called Sarbanes Oxley. For those of us in the SCM realm, this means that once a year auditors knock on our door and ask us for a ton of historical data for particular dates. ‘Tis an easy task! We have branches for releases and versions of every file! Well. Sorta. Developers check stuff in. Release engineers check stuff out and push all the changes to distribution/production servers. Under the gun of a cost-saving production patch and in the heat of the moment… who is spending time checking the patch into version control? or tagging? or creating sub branches? Or adding useful comments? What Conventions?!? Ok, so not everyone is CMM5.

CVS Users Beware — So you’re using CVS and someone says, “Identify all production patches for the YYYY-MM-DD build.” So you go back to your desk and calculate the date ranges that the branch was active in production. Quickly skim the ‘cvs diff’ man page and deduce that ‘$cvs diff -r <branch> -d <date>‘ will do the trick. Nope. CVS 1.11.x and early versions of 1.12.x have a bug where the ‘-d <date>‘ pulls versioned data from the Mainline (aka. TIP). Doing date-based diffs for branches Does Not Work. Here is how to get around it.. Enjoy…

Quick entry from the road to test posting from my Sidekick II. So far so good. I am out and about running errands.. Feels good to be downtown Chicago during the holiday rush. Yesterday I learned how to do inline Bash GSR on the previous command… $!!:gs/search/replace/. Way cool!