Code maintenance

Keeping track of code through time is a very delicate task.

It gets to be a really important issue when customers are making usability tests to a program. You make some changes, the customer reviews them, approves and you send them to production, a couple of days later the customer changes his mind and ask you to go back to how the program looked 3 months ago.

That scenario gets to be very common in web development and can be a serious problem if you don’t give your customer what he wants. How could you go back to a 3 months old version of a page? Did you backed up your files? Is your presentation layer different from the logic one? What has changed since then? How can I merge those changes?

Changes are part of software life, so they must be documented properly. Changes documentation should answer the following:

Who made the change? If something goes wrong you may identify who made what and the settle responsabilities.

What changes were made? You should keep track of what files were affected, what code lines were modified and what was changed in the logic.

When were those changes made? You’ll keep track of time invested on that change.

Why? Was it because of a user request?, a bug fix?, an enhancement?

If you work for a company answering these questions will prove to be a great way to justify your work. It will even make it easier for your colleagues to keep up with your coding style and logic.

Most developers use inline comments to document changes for example:


* author: Me

* date: October 25th 2009

* version: 1.0.1

* summary: User asked for the color to be changed from red to blue so the code changed from $color = “red”; to current


$color = “blue”;

That’s a nice way to keep track of changes but you’ll get to the point that one change requires a lot of file content modifications, folder creations, code logic changes, etc. which on large projects can be a real hell to keep track of. This just happened recently on my job.

We solved a lot of things by using a version control software. We tested it and finally decided to go for SVN or subversion. It’s pretty easy.

Even though projects creation and repositories administration were a mess at the begining because we wanted to limit access to developer groups only to their assigned projects. We kept SVN and installed USVN on  top of it…. needles to say we are very very happy with the results.

We get to admin our repositories in a very simple way. Since USVN is developed in PHP Zend Framework and you get to modify the code we have made some customizations to it so it works as we want it to work.

One great thing we managed to do with SVN is have a strict control over our stage environment. Developers do a SVN commit which immediately updates a stage environment so changes are visible to QA.  Once QA approves a version we create a tag meaning its a new release which then goes to production.

That’s the main reason I’m posting this, I was the one responsible for implementing those automations and they do work.

How did I do this? Well it’s actually pretty simple. Once a SVN project is created you go into that project’s folder and go to the hooks subfolder. This is where the magic happens.

Though there are several types of hooks I only messed with the post-commit hook.

I granted execution permissions to post-commit file (remove the “.tmpl” part).

Modified the hook so its aware of some important paths and then coded a few lines so, for example, we got SVN to send an email reporting what changed, who did the changes and when was the code commited to project owner so he could keep track of his project.

SVN works for us right now and hooks are a charm. I’m pleased right now and so are my boss and my colleagues :D:D:D:D

I keep repeating to myself: Linux rocks, free software rocks and most of all I rock! hahahahahaha

Comments are closed.