1 minute, 33 seconds

If you’re a developer, you probably use a revision control software. For both work and personal projects, I use SVN, which is great. At work we use SVN as a way of releasing new features and bug fixes to our web site. We can push a specific a revision as well as roll back to a previous revision, thus leveraging revision control to be our release software for a 4 server load balanced site. SVN + rsync + shell scripting = : )

Recently at work we were doing a bunch of little changes all over the site, including having the designers do a bunch of css and DOM tweak as well. The time came to commit all of the changes. Instead of doing the commit at the root of the repository and stuff all the changed files in at once, I enforced a multiple granular commits of the functionally changed files. Each commit had a relevant comment.

Enter a week later. We hadn’t done sufficient regression testing and a visual element was broken in ie6. Which of the thousands of new lines we committed and pushed was the culprit? Had we done one massive commit we would have been screwed. However, we were able to cull over the commites via our trac instance (awesome!) and review the comments. In this case we couldn’t actually find the exact commit that caused ie6 to break, but we were able to step through our dev instance of the site, slowly adding each revision to it until it broke in ie6.

The moral of the story is that, much like backup, revision software is only as good as it’s end user. Think of every commit as chunk of functional related code. Think of every comment for these commits needing to solve the problem for another developer who has no idea what the code was and they’re up at 2am trying to figure WTF is up with the site. For every commit, where possible, you should also site a bug number so that should the bug crop up again, it’s easy to cross reference the “fix” with the code.

Happy revising!