Pre-Commit Hook Scripts in Subversion

It is not everyday i get to implement policing in corporate environment. But it is also something that is required all the time. It is when your team is induced with more and more new people it becomes difficult to monitor what is being committed and how it is being committed. 

One of the key things the committed code is evaluated is via relation of the change with what it has been changed. This is achieved usually by breaking down the implementation into smaller chunks and committing it against the issue id.

The issue id is usually put in the log message with a commit message descriptive enough to let you know what the change is for and what it does. It is tricky to write a good enough commit message. Either it is too short, it is too long or well it serves no purpose.

This is the reason it is absolutely important to know against what the commit has been done. Hence these pre-commit checks.

Implementing Repository Hooks

Here I am quoting the content from the SVN Book. 

A hook is a program triggered by some repository event, such as the creation of a new revision or the modification of an unversioned property. Some hooks (the so-called “pre hooks”) run in advance of a repository operation and provide a means by which to both report what is about to happen and prevent it from happening at all. Other hooks (the “post hooks”) run after the completion of a repository event and are useful for performing tasks that examine—but don't modify—the repository. Each hook is handed enough information to tell what that event is (or was), the specific repository changes proposed (or completed), and the username of the person who triggered the event.

So basically a pre-commit hook from the server is kind of policing that we do before any transaction is being committed to the  actual repository. Usually it is done from the server side so all the developers adhere to it.

Requirements

The following were the key requirements in my case.

1. The commit message should be descriptive enough to describe what it fixes or does.
2. The commit message should have an issue id attached to it. (In unlikely scenario the commit message is just string of "Fixes" repeated after each other.)

The first requirement was pretty easy to solve by just giving in a minimum character length to the commit message.

The second requirement was very Issue Tool Dependent so cannot be generalized easily. The issue tool that we use is an RTC (Change Control Management) Tool provided by the IBM Engineering LifeCycle Solutions. 

The idea for the second requirement is that the subversion is linked with the tasks management and change management tool of the IBM. Any commit that is done there is recorded by the Tool. What we want is to neatly arrange the commit to each of its separate tasks or issues. This can be achieved by referencing the isssue id or in IBM terms "Work Item". The RTC tool can automatically pick up the commit if we commit the message starting with the string "Work Item:<IDNumer>" where the Work Item is a keyword picked up by the tool and ID Number is the system generated number for the work item that exists in the RTC tool. 

So what the check we want in the commit message is that the commit message should start with these key terms. Ensuring the Tool will pick up the commit.

To sum up two checks are:

1. Minimum commit message length of 50 characters
2. Commit Message should start with the keyword "Work Item:<IDNumber"

Environment

The environment is a windows server running an instance of Visual SVN Server.

We can go to the Hooks tab in the repository and see the list of all the available hooks from the server side.

Visual SVN Server Hooks

The hook script can be written here and the rest Visual SVN Server will take care. For windows this is quite easy to be honest. Though it is made in a way that it is simple to implement. Apparently lot of people need this when working in an open source environment. 

Pre-Commit Hook Script

I have split the script into two parts. One taken care by a python script and one take care by the application provided by the Visual SVN Application.

The incorporation of Work Item ID is take care first and is done by the python script appropriately named log-police.py The py script can be called just like it is done in a windows command prompt.

py -2 "script_path/log-police.py" %1 %2

This will call the log-police python script and pass the argument REPOS-PATH[%1] and TXN-NAME[%2]

1. The REPOS-PATH is path to the repository to be used in the script to get the logs.
2. The TXN-NAME is the transaction that is about to be committed. This too is used to get the logs.

The python script looks something like the following

We have a main function called run() that basically takes in the sys argument that is the REPOS-PATH and TXN-NAME.

The function calls the svnlook command that is added on the system path and asks it to show the log message for the repository named REPOS-PATH and transcation -t with TXN-NAME. 

The command outputs the log message that is then passed to the check_log_message function. 

This uses a regex to check whether the log message starts with the keywords "Work Item:<IDNUMBER>" if yes then it exists the system with the 0 error. Else it exists the system with error 1 and printing the reason on the standard error message.

The code that goes into the batch for the pre-commit hooks is also attached and the snapshot for the same is as below.

Pre-Commit Batch Command

 

Conclusion

This ends this short post on the pre-commit hook scripts. For now i had a basic requirement so these two things served my purpose possibly one can extend this to add code styling checks as well.