Morten Frederiksen: I wanted to be able to subscribe to the changes in a Bazaar branch. Starting out with Sam’s tarify.cgi and Joe Gregorio’s sparklines as working examples I have managed to create a simple Python-script for generating an Atom feed: bzr-feed. You can of course subscribe to the changes!
Morten Frederiksen: I wanted to be able to subscribe to the changes in a Bazaar branch. Starting out with Sam’s tarify.cgi and Joe Gregorio’s sparklines as working examples I have managed to create a simple Python-script for generating an Atom feed: bzr-feed. You can of course subscribe to the changes!
Sweet!
I’ll definitely be deploying this for Venus. But first I want to think a bit about what values make sense for link
, and I want to put in some sort of cap on the number of entries in the feed.
To make this happen, I had to make a few small changes (diff, branch), mostly to enable me to run this from the command line as bzr
isn't installed on CornerHost.
export HTTP_HOST=intertwingly.net export SERVER_PORT=80 export REQUEST_URI=/code/venus/index.atom python bzr-feed/bzr-feed.py dir=venus > /home/rubys/planet/code/venus/index.atom
Right, the link value isn’t obvious, at least not without something else in place, perhaps a change log with branch identifiers.
I’m not sure what you mean with “cap” — there should be exactly ten entries in the feed, or is there a bug or incompatibility somewhere?
there should be exactly ten entries in the feed
Ah, I missed the start_rev
argument to show_log
.
“as bzr isn’t installed on CornerHost.”
Is this a point of philosophy? Personally I have a full installs of both Python 2.4 and 2.5, not to mention bzr, in my $HOME on Cornerhost.
Is this a point of philosophy?
Not consciously, no. I’m sure that if I hadn’t figured out how to serve the results statically, I would have figured that out... eventually. :-)
As far as unique identifiers for feed entries, it would be better to use the revision IDs instead of things like “tag:intertwingly.net,2006-08-16:code/venus:190”. This way twp branches that contain the same revision in their mainline history will get the same ID.
Given the way Bazaar revision history is normalised, if two branches have the same revision in their mainline history they should assign the same revision number to it.
By the way, there is an SVG of the official Bazaar logo available here:
[link]
The colours and shape are a bit different to your version.
it would be better to use the revision IDs
The colours and shape are a bit different to your version
I’ve adapted the colors and shape somewhat to make the result simultaneously more similar to, and yet more distinct from, the original.