January 18, 2012

How I Use Surround SCM: Track Changes

Surround SCM
A funny thing happened during the writing of this blog post—I found a regression bug. And what is particularly great about this (as great as any regression bug can be) is that I found it by taking some screenshots of the Surround SCM feature I wanted to talk about. That, folks, is serendipity. [caption id="" align="alignright" width="149" caption="Penn and Teller"]Penn and Teller[/caption] Side note: Years ago I saw a live show of Penn and Teller. And Penn did his juggling broken bottles bit where he takes bottles, typically liquor bottles, then breaks them on stage, and proceeds to juggle their broken remains. This gives a sense of authenticity to the audience as he's doing something real right before your eyes. He even says something to the effect, "I do this trick all the time, but for real, THIS time these bottles broke in a REALLY difficult way." That's classic magician stuff, build the excitement even if the words aren't true.How does this relate here you ask? I honest to goodness, cross my heart and hope to die, REALLY did find a regression bug while researching this blog post. For real. The Surround SCM Track Changes feature is, in a nutshell, a way to quickly determine which branches a specific code change has been promoted or rebased to. You choose the code change either through the revision in a file's history, or my preference, by the TestTrack issue, a changelist, or a label the code has been associated with. For our Seapine ALM Reporting Platform product we use InstallAnywhere as the installation technology and, like all our development files, the installer project file is stored in Surround SCM. When I did a history command on the installer project I noticed this: It looks like I made some changes to the installer in June on a child branch as the result of a defect, but they were never promoted to the mainline. This was probably because I had already made changes to the installer file on the mainline and didn't want to clobber those changes. To make sure, I selected the revision of the file where I attached it to the defect and clicked the Track Changes... button. Sure enough there is no record of this change in the mainline. As a quick aside, I could search by changelist, defect, or label by changing the "Track changes for" drop-down selection. Clicking the Select button while "Defect" is chosen in the drop-down gives me the trusty TestTrack browser dialog where I can use filters and all that good stuff. See, searching by the defect number, #164, gives me the same result. To completely overuse a magician metaphor, there's nothing up my sleeve here. To make sure that I had applied the change to the mainline back in June, I first look at the setting described in the defect for the file on the 2011.1 branch: A quick look at the 2012 version and I find that it is the exact same uh-oh. I never applied that change to the mainline. This is a regression defect and one that QA will be more than happy to re-open when they find it. I'm not going to give them the satisfaction though. A quick update to the installer project file and I'm ready to check in, making sure I also attach this check in to defect #164. If I do a track changes on defect #164 for the mainline branch, I see my change. Note that I don't see original code change from the 2011.1 branch because that revision was never promoted. However, because I'm using the TestTrack integration and I attached all my changes to the same defect, I can still find everything. (Lesson here, integration is very good.) So there we go, code check in, regression bug squashed before QA had a chance to find it, blog post written, the only thing left to explain is how Track Changes worked under the covers in the depths of the code. That's easy. It's magic.