Branches and Tags and All That

Today, my diligence in creating branches, and then tags, for releases finally paid off. And bit me back.

A product, live at version 28.1, and currently at version 29.2 in User acceptance testing, had a critical bug reported in Build 28.

No problem - I created a branch from the Build 28 tag, checked this out, fixed the bug (one line), and deployed that to the customer. Hooray - happy customer.

However, after creating a new build 28.2 tag, I then had to merge this change back into both the current 29 branch and the trunk, and commit both separately.

I know I would not have been able to support this change without the rigorous tagging/branching, but it still grates when you have to do the same merge more than once.

It was worth writing those unit tests...

Simple specification:

If the user is not in the "Admin" role, then buttons x, y, and z are hidden.

You'd have thought that unit tested the presenter/controller for this would be pointless, but it highlighted the fact that I'd hard-coded false for the visibility of one of the buttons.

I think that was worth the five minutes it took to put the tests together.

SyntaxHighlighter

As you can see, I've used SyntaxHighlighter to smarted up the posted code.

One thing I found was that Blogger likes to put "<br>" elements in any "<pre>" code, so I wrote a little javascript to replace them with newlines:

(function(){var pres = document.getElementsByTagName('pre');
for ( var i = 0; i < pres.length; ++i ) { 
  for ( var br = pres[i].childNodes.length; br > 0; --br ) {
    if ( pres[i].childNodes[br-1].nodeName == 'BR' ) {
       pres[i].replaceChild(document.createTextNode('\n'), pres[i].childNodes[br-1] );
    }
  }
}})();