request to update version.php

Having a version number in trunk is in fact not correct, and should only get added when doing a release. You should be able to compare between svn tags easily, the issue tracker will be of great help too, see http://elgg.org/trac/browser -> View changes...

I agree that you don't want to update the version.php file on every changeset. Perhaps a better solution would be to enable the svn:keywords property on the version.php file. Then create a couple of new variables in there to reflect the current revision number and check-out date.

$svn_release = '$Rev$';

$svn_date = '$Date$';

Note the single-quoted strings here to prevent PHP from thinking that $rev and $date are variables for its own consumption. But now, SVN will automatically update these values for you without any human intervention. This is something that could easily be checked by end-users (or plug-in writers, in code) and doesn't affect things that depend on the current version variable, since we'd definitely want to leave that alone and change it only by hand for releases.

I do like Justinr's idea. It would help to keep track of what release I was actually running (there's no other way). Does resolution deleted mean that you've done this Justinr ?

No, I haven't fixed this (as I don't have write-access to the SVN). "resolution deleted" is apparently what happens when you reopen a closed ticket. The fix should be easy enough for them to implement though, if they want to do it. Unfortunately, I don't think that you can do this on just your local copy.

Additionally, It seems that $Rev$ doesn't actually get expanded to the full revision number of the current checkout, just the revision of the file. See here:

http://subversion.tigris.org/faq.html#version-value-in-source

So I'm not convinced that my resolution would actually work, either. Maybe I'm too used to CVS still. :)

From what I understand the keyword expansion needs to get done on the client side. An option would be to have this type of solution implemented in nightly builds, but is be something to reconsider again when the 1.0 branch lands. Closing this report with wontfix for now again.