Easy change logs

Developers! Tired of status meetings? Fed up with regular requests for progress reports, change logs, version notes? What you need is an Automated Solution®!

The hard reality of the corporate coding way of life is that various people always want to know what you’re doing, what you’ve fixed, what changes are in what release, and so on and so forth. When it comes to Domino development, this is where a tool like Teamstudio’s CIAO! comes in to play. If you’re diligent about providing check-out comments, and you tag up a version within CIAO! every time you do a build for your deployment / admin. team, you already have the wherewithal to produce complete change logs, with next to no effort. How? Simply make use of this menu option:

Screenshot: CIAO! change report in action

Smashing stuff; can’t recommend CIAO! highly enough, even just for this sort of thing, never mind all the versioning / team development splendour.

But what about non-NSF code? What about all the stuff that you may ram into different version control systems? Well, I’m living in Eclipse at the moment, and as the project utilises the skills of a whole panoply of developers, CVS is a must for us. Every time we do a significant release of a component (our project encompasses two different—but related—modules in CVS), we have to provide some form of change log. And casting your mind back to the exact change you made to fix some bug, three weeks previous is tricky to say the least. What you need is some kind of tool for producing your change logs.

I have found such a thing. Moreover, it is really simple to use, is open-source, and it’s free. Allow me to introduce you to CVS Log Change Builder. CVS Log Change Builder is a simple soul in that it just comprises a single Perl script.

That’s it, no executables or other bits of nonsense, just a beautifully simple tool (assuming you have a CVS client on your path).

OK, how do you use it? Well, first up you need to edit it to point at your CVS server like so:

my $CvsRoot=':pserver:[email protected]_SERVER_NAME:/CVS';

Once that’s done, copy the Perl script to the check-out root of the module you wish to report upon, and run the script. Here’s one typical use for it:

perl -output=buildhtmlreport

… note that the script can take a wee while to run (and may prompt to save your CVS password in a .cvspass file the first time round also), but once it’s finished, you should have a lovely shiny report. In the example command above, we’re electing to output as a manager-friendly HTML file. Everything’s there: who checked in what and when, how many lines of code you got (always an important metric, right?), pretty colours, the lot.

Job’s a good ’un!

Comments on this post are now closed.


I’m a software architect / developer / general IT wrangler specialising in web, mobile web and middleware using things like node.js, Java, C#, PHP, HTML5 and more.

Best described as a simpleton, but kindly. You can read more here.