Setting up a commitlog

Tuesday, February 3rd, 2009 by rjm

I set up a new mailing list that can be used to track commits to the Subversion repository. Subversion has some hooks that you can use, like post-commit for example. I used this hook to invoke the mailer script every time a commit has taken place.

The mailing script will sent an e-mail to the commit log mailing list with information on the files that have been changed and the diff’s between the previous version along with more general information, like the name of the author and the timestamp of the commit.

You can subscribe to this list from the Support page at the project’s website.

Too bad they still include that deprecated Perl mailer script in the distribution. It took me some time to find out that mailer.conf was only to be used by the Python mailer script. And even then, the Perl version doesn’t support SMTP auth (which I added myself, but that doesn’t matter anymore).

Project hosting

Sunday, February 1st, 2009 by rjm

Today I decided to keep my development server at home running non-stop. One of the reasons is to host the source code repository myself. Everything else, like this backlog and the website (including the forum and the bugtracker) are still served from Martijn’s server.

The service I mentioned in a previous blog post will eventually also run from my development server since I don’t want to clog Martijn’s bandwidth with my stuff.

From now on the Subversion repository is served directly from my development server at home. I had previously enabled the Subversion repository at SourceForge for this project so Ohloh could analyze the code. But now that I have my server running non-stop I can serve the repository myself. So I disabled the repository at SourceForge again and updated the enlistment at Ohloh to query my own server for updates.

The location for the source code repository is: svn://source.irc-collective.org/

I could of course host the entire project at SourceForge, and save myself from doing all kinds of maintenance. But the point is, I take great joy in setting up all those services. I learn something new every time. Of course, it can be frustrating when things brake or when they take up much more time than expected. But once I get things working, I get a great deal of satisfaction from it.

I might want to see if I can use svnsync to synchronize the source code repositories between SourceForge and my development server, but that’s something I’ll save for later.

I still have to move ViewVC to the development server, otherwise I have to copy (dump and load) the entire repository from my server to Martijn’s server with every change.

Update 25/10/2009: The development server which hosts the source code repository is offline again. The power consumption of the server is simply too high. Until I buy a replacement with much lower power consumption it will remain offline.

Revision 41

Saturday, January 31st, 2009 by rjm

I added two components to the page that displays logfiles in the web application, namely:

  • a selection box to limit the number of results per page
  • and a check box to show or hide non chat messages.
logfile.pl rev

logfile.pl rev41

The code for the web application is in some really bad shape. What’s killing me, is the fact that the view and the logic are not separated from each other, along with a whole bunch of other bad practices. If anything needs a rewrite, it’s going to be this part of the software!

On the same note; the entire web application could use a paintjob! A neat CSS stylesheet might just do the trick though.

Thoughts on setting up a service

Tuesday, January 27th, 2009 by rjm

The mission statement for this Open Source project is:

“Providing solutions to archive, query and analyze IRC logfiles.”

My idea of “solutions” is twofold; On one hand, I should create software so users can archive, query and analyze IRC logfiles themselves. On the other hand, I should setup a service that provides the same functionality to users that don’t have the time or know how to install and configure the software.

At the time of writing, the software itself is not mature enough to actually start working on such a service.  But, I can ponder about it from time to time and publish some of the ideas here on this blog. Besides, I should spent that spare time on developing the actual software.

The service would basically be a website where users can register themselves and the channel they want to log. After they have registered, they can either invite a logging bot that will start logging the channel or upload their own IRC logfiles. Users should then be able to make use of the same functionality that the web application provides, such as viewing a logfile, browse the image gallery, create a paste, etc.

Back to coding…

mIRC

Wednesday, January 21st, 2009 by rjm

I wanted to update Appendix B “Notes on logfiles” from the installation guide, because except for mIRC all the other IRC clients have logging set up by typing commands whereas for mIRC it has to be done through the GUI.

To straiten this out, I installed mIRC on a Windows box, created a copy of the original config file, than ran mIRC and configured logging according to the instructions in appendix B. I than finally compared the new config file with the copy.

I was surprised at first to find out that mIRC doesn’t store all the changed settings as separate variables, but instead uses a set of obscured serialized variables that hold more than one setting each.

Then I  realized that for this reason Martijn (a supporter and contributor to the project) had to incorporate the instructions for mIRC as a GUI walk through, rather than listing commands that the user must type (as is the case with the other clients). A real bummer.