Yet another new version, subatom 0.11 again prompted by Hans F. Nordhaug. The only change this time is to add a feed_title option to the config file, so you can specify the title for the feed as a whole.
Now, I’m going to sit down and attempt to rework all this as a module+script, along with some tests. That I managed to break things in the 0.09 release was very irritating, and the tests should have caught that.
Update: Please grab subatom 0.12 instead when it shows up if you want a working version. Doh.
I’ve made another release of subatom. This contains a number of fixes for bugs that I managed to put into the 0.09 release (as well as a couple of minor features). This has really left me with a very nagging need for some tests for this module.
- Restore the ability to send output to stdout.
- Make the command line mode work, as well as the config file.
- Don’t cover up stderr when executing “svn log”.
- Force subversion to give us back UTF-8, and cope with it.
- Add support for using—limit if your svn has it.
That item about UTF-8 has annoyed me, because it’s brought me into contact with a hated topic: locales.
Subversion internally works with UTF-8 everywhere. This is a sensible design. But in order to interface with the outside world, it needs to convert that into whatever character encoding you are using. How does it know what character encoding to use? It guesses from the locale.
The locale is meant to be a specification for how to sort characters, how to format the date and so on and so forth. In recent years, it’s also been taken over to specify the character encoding that’s in use. So, to specify that I want to see the world in UTF-8, I need to say:
Except that breaks ls(1). Yes, ls(1). For some insane reason, setting a locale changes the way that things work such sorting now happens in a case-independent manner. So that “README” files no longer appear at the top of a directory listing. I haven’t investigated any further to see what else is broken. I quickly switched back to the “C” locale, which effectively means no locale.
So now, I’m left wondering how to tell the system that I’d like UTF-8, but none of the other inconveniences that locales bring me.
I’ve released a new version of my tool subatom. If you haven’t seen it, it produces atom feeds for subversion commit messages. It’s pretty handy for monitoring activity in a subversion repository and it doesn’t need access to the server.
There are only two new features in this release:
- Add in a option to specify
link[@rel="self"], which means that the generated feeds can now pass the feedvalidator with flying colours. Many thanks to Hans F. Nordhaug for the patch.
- I’ve added in a config file. I broke down and did it because I’d ended up with scripts that just called subatom in a variety of ungainly ways. Using a config file makes things slightly more manageable.
However, as with all releases, there are already a couple of problems:
- Hans found that it doesn’t really cope with character encodings properly. This is particularly shameful for me. So I’ll take a peek at it tonight to ensure that we tell subversion to give us UTF-8 and process that accordingly.
- Another point brought up by Hans is that it should invoke
svn log --limit. I’d been avoiding that because I’m still on an older version of svn at work, but there’s no reason to not run
svn help logand check the output to see if