svn keyword magic

Subversion is officially the coolest thing ever 😉

And now on a related note…

Yesterday during a code review, the svn:keywords property was discussed, and the idea proposed to start using it to embed magical versioning information into our builds (for bug reporting reasons and such). Well, I decided to jump on the idea this afternoon. After a bit of fiddling, we now have a little component that can be used to display the revision number of the current application build – all w/o anyone having to remember to do it.

The SVN Book explains how to use the property in greater detail.

I created a simple xml file (it could be any text file, really), that I then dropped the svn keyword tags into it.

I then set the svn:keywords property on the file to “Date Rev” (ie, the names of the keywords i want replaced – see the full docs for a list of valid keywords).

Upon commit, the file is updated on the server to now look more like this:

Unfortunately… there’s a major hitch in what I wanted to do. These labels actually only update when the file in question is updated. Ie, it displays the last time the source file was changed, not the last time the entire repository was changed. So, this trick is useful for updating header comments or perhaps an internal version constant string (if you’re doing server-side post-commit builds or something). But… it’s not what I want in this case 😉

In the end, I wound up having to do a bit of old fashioned sed manipulation on the server side post-commit… but that doesn’t change the fact that subversion still allows me to do this kind of magic. It’s just not quite as magical as I’d originally hoped it could be.

My post-commit hook now looks something like this:

I’m keeping updated copies of a part of the repository in a web accessible directory, and am using Ant to build deployable zip files and such. The sed commands are performing a search and replace on the svn keywords before the build and I then revert the changes (just in case somebody actually changes the real contents of version.xml – which would result in a conflict if we kept these local changes around).

The file I’m producing now looks like this:

If I really wanted to, I could generate the same exact date format as SVN uses, but I prefer this one for its brevity.

2 thoughts on “svn keyword magic”

Leave a Reply

Your email address will not be published. Required fields are marked *