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
4 replies on “subatom 0.09”
Hi Dom. A handful of thoughts.
Could you use SVN::Log to help with this?
Also, Subversion stuff on CPAN normally sits in the SVN:: namespace. Perhaps modularising this as SVN::Feed::Atom (with a wrapper script taking the place of subatom)?
Or perhaps as an SVN::Notify plugin?
Also, you know that you can do “svn log—xml” to get the log information from Subversion as XML, right?
And one more thing
– you don’t fancy writing SVN::Web::Atom do you :) ?
Oooh, I hadn’t seen SVN::Log. That’s looks neat. Although a quick glance at the API shows that it’s not so easy to pull out “The last N applicable revisions”. I like that it uses the SVN perl bindings if available though.
As to the name, yes, it probably should sit in the SVN:: namespace. The trouble is that it started off as a shell script in my bin directory. If I get around to splitting it out into a script+module, I’ll probably rename it.
I’d not considered it as an SVN::Notify plugin, even though I use that. That could be a fruitful avenue.
As to the
svn log --xml, well that would mean depending on an XML parser as well. I’m already a little concerned that I have one dependency…
SVN::Web::Atom? I shall take a peek. I’m sure it can’t be that hard… I just need to find the time.
SVN::Web::Atom would largely be a case of subclassing SVN::Web::RSS, calling the superclasses run() method, and then changing the name of the template that’s used.
Then you just need a template that generates Atom instead of RSS.
I’d do it myself, only I’m too lazy to learn yet another feed format… 🙂
If SVN::Log would help (or is close to helping) let me know if there are any features that you need (via RT), and I’ll endeavour to add them.
As I said on private e-mail to Dominic, I think it sufficient to use ’’svn log—limit N—xml’’ and the some regular expressions to replace SVN XML tags with appropriate HTML tags – no need for a XML Parser or even SVN::Log.
PS! I assume I could look at SVN::Web::Atom, at least making the template shouldn’t be a problem, if Dominic doesn’t want to.