I wanted a method to show what the version or subversion revision number a user was currently running. The main reason is to determine what code base was being run by users reporting problems I thought we fixed, or not seeing functionality I thought was complete.
Most people are familiar with this functionality exposed via the “Help->About” menu on a desktop application. Web developers need to do this differently, as there typically is no outer application menu.
Being a flex application, I have the ability to modify the context menu users see when they right click. This was part one of the puzzle, and that answer is well documented in this post by Kenny Lin. The way I have my SDK wired, much of the code documented there did not trigger the autocomplete on my system, but it compiles and runs perfectly.
Getting the revision number is the hard part. We currently use subversion as our source code repository, and it has a global revision number – what most developers would refer to as the build number. (Due to the fact that we now do a build every time we do a subversion update, see below.)
Subversion has a technique called keyword substitution which allows you to put a string in a file like $Revision$ and every time that file is updated on the repository subversion will update that string with the correct number. I thought I was done right here – but the problem is that subversion only does this substitution when it updates a file, i.e. when a developer edits it. I added this to our main application file, and it worked the first time I updated it, but it turns out we don’t update that file very often anymore.
The biggest piece of the puzzle was an autobuild process which is triggered by subversion updates. My very simple build script generates a subversion info file using this shell script command:
svn info > assets/svnInfo.txt
I embed this file in the application via this technique which is only a couple lines of actionscript code:
//Embed a text file that is autogenerated by the build process
//it contains the revsion number of the project from subversion
[Embed("assets/svnInfo.txt", mimeType="application/octet-stream")]
private static const svnInfoText: Class;
And the following function parses the revision and puts it in the context menu:
/**
* add the version number from the subversion generated file
* to the context menu so testers can verify what
* build they are running
*
**/
private function setUpContextMenu():void
{
var myMenu:ContextMenu = new ContextMenu();
myMenu.hideBuiltInItems();
var svnTextInstance: Object = new svnInfoText();
var svnString:String = svnTextInstance.toString();
var findString:String = “Last Changed Rev:”;
var revisionString:String = svnString.substr(svnString.indexOf(findString) + findString.length +1, 5);
var menuItem1:ContextMenuItem = new ContextMenuItem(“MyApp v0.1.”+ revisionString);
myMenu.customItems.push(menuItem1);
this.contextMenu = myMenu;
}
Getting the autobuild process up and running was the hardest part – learning the various libraries I needed and setting up the license information from adobe. I have a lot of ideas and opportunities around that, including ANT or other build tools – but for now the simple fact that I can control the build to the level of adding this step of creating the subversion information file get’s me the functionality required.
