You are here

version

Upgrading this blog to Wordpress 2.5.1

Finally. Jeez.... Anything broken?

After having been stuck on version 2.0.1 for over two years, I’ve just upgraded to the most recent version, 2.5.1. The only hiccup was needing to ask my web provider to give me a new MySQL database: since 2.5, Wordpress has required MySQL 4.0 or newer.

Otherwise, it all seems to be running very smoothly. Do let me know if you see anything crazy. I hope to upgrade more frequently in future, as it was a far better experience than I’d expected.

Blog category: 

Subversion log messages need not be set in stone

Simon Willison mentioned a while back a link to help on how to undo a svn commit in subversion (more a kind of internal branching than an actual undo, of course: but that’s subversion). That’s all very well, but how about undoing the log message for a particular commit?

Say you have a codebase that only you’ve worked on, and the log messages are (to say the least) idiosyncratic. Worse, they might contain swear words like “p*mh*le,” “cl*ff-pr*nker” or “Gr**nsp*n.” How can you, for example, get rid of a bit of bitching between programmers like:

$ svn log -r 200
————————————————————————
r200 | jps | 2007-05-30 14:50:56 +0100 (Wed, 30 May 2007) | 2 lines

oh for heaven’s sake - cacheing at view layer broke CSS!
Which buffoon wrote l51-78, ***Malcolm***?
————————————————————————

The svn propset command in principle lets you change log messages. However, most archives are set up to prevent this by default with “hooks.” You can alter the configuration of the archive to permit this, if you’ve got administrator’s access to the physical files of the archive. But if you’ve got that, then you can change the log message directly with the svnadmin setlog command and the -

-bypass-hooks option:

% echo “Fixed” > /tmp/newlog.txt
% svnadmin setlog -

-bypass-hooks /home/svn/repositories/bluefish /tmp/newlog.txt -r 200

The advantage of this is that all hooks remain in place afterwards, so you don’t have to worry about re-securing the archive. As the link to the Redbean book up there states, though, be warned that -

-bypass-hooks bypasses all hooks: if you have email alerts set up to report each submission, then they too will fail to fire. Another reason not to do it permanently, I suppose.

(And I don’t work with anyone called Malcolm.)

Checking the changes for many svn versions, one version at a time

Say you want to see both the log and diff of a given svn version, just the differences between it and the previous version, plus log message (i.e. what was committed, and why, for version NUM) The following will work at a bash command prompt:

$ r=NUM; rr=-r`expr $r - 1`:$r; svn log -r$r; svn diff $rr

It looks a bit unwieldy, but you can keep pressing the up arrow and home key, and re-editing NUM, multiple times to look at multiple changes:

$ r=320; rr=-r`expr $r - 1`:$r; svn log -r$r; svn diff $rr
. . .
$ r=321; rr=-r`expr $r - 1`:$r; svn log -r$r; svn diff $rr
. . .
$ r=322; rr=-r`expr $r - 1`:$r; svn log -r$r; svn diff $rr

Also, you can automate your checking to loop gradually over a range of changes:

$ for ((r=310;r< =336;r+=1))
> do rr=-r`expr $r - 1`:$r; svn log -r$r; svn diff $rr
> cat -
> done

Press CTRL-D whenever you’re finished looking at a given change, and the next change will come up.

New version of rmrip

Following user requests, I’ve uploaded a new version of rmrip which takes a command-line argument specifying your configuration file:

./rmrip.py foo.conf

As the user himself implied, this has the added bonus of making it more crontab-friendly e.g. you can have a crontab entry saying:

0 2 * * 2 $HOME/rmrip/rmrip.py tuesday.conf

You can download rmrip as before from http://www.jpstacey.info/blog/files/code/rmrip.tgz. Thanks to Matt for the idea.

Universal re'locator

What happens when nobody will take responsibility for a standard that the web relies on?

RSS, the standard millions of us use to syndicate content, and view other people’s syndicated content, was originally invented by Ramanathan Guha at Netscape, for use on its my.netscape.com portal. Soon afterwards, Netscape lost interest in the format, leaving it ownerless and later on picked up by a development community spearheaded by UserLand Software.RSS 0.91 became 1.0 and 2.0, yet despite the deprecation of the grandaddy of them all 0.91 is still around and in use, arguably because of the vast overcomplications in its immediate successor and the divisions that it caused in the community.

The problem with that is as follows. Every time someone views an RSS 0.91 syndication feed with certain types of syndication software, their computer attempts to get the DTD from this location on the my.netscape portal—it’s hardcoded into the way that the software understands what XML format it’s dealing with. So this URL gets plenty of hits:

http://my.netscape.com/publish/formats/rss-0.9.dtd

Which is great, until Netscape decide—legitimately, one might argue—to update the my.netscape portal and get rid of the DTD. Which they did, at the start of the year. At that point, a good portion of the syndication lights go out across the world. And although we now have a moratorium until July 2007, nothing has really been solved in the long run.

Anyway, Netscape shouldn’t have to support the bandwidth of millions of DTD downloads for a standard they declared defunct—when did they sign the don’t-be-evil contract?—and maybe people should “just” move to a newer version of RSS, or Atom. But this whole episode is an Ozymandian warning of what is to come. We’ve reached the point where the URLs of industry (one-time) giants are simply no longer to be trusted as the location of standards.

One day Microsoft, and Sun, and IBM, will cease to exist, and their websites become the 22nd century equivalent of Google-adsensed search engines (Google, of course, will be around forever, more’s the pity). Sooner or later something really horrible will happen for the open communities, say Purl disappearing for good, taking things like the Dublin Core XML specification with it. We need to know how to deal with the loss of their specifications and standards now: the unreliability of the URL as a locator for DTDs and schemata. Or is the only lesson we can draw from history, that we’re destined to wander from standard to standard as the specifications drop off the radar, leading the nomadic life of those standardized today, obsolete tomorrow?

Blog category: 
Subscribe to RSS - version