Page MenuHomePhabricator

Restore revision numbers in Special:Version
Closed, ResolvedPublic

Description

Several svn version numbers having preiviously been shown in Special:Version
have recently been removed. Please restore them, or, better, add them
everywhere.

If there were reasons, not to show them, e.g. to the ordinary layman,
make them available with an installation option, or the like.

Since MediaWiki, and its extensions, cannot usually be easily
"svn update"ed together, it is most useful when you can see,
if versions differ, and - roughly - since when which extensions have
not been updated. When you show MediaWikis version, the versions
of extensions should be shown as well. At least when they differ!


Version: unspecified
Severity: enhancement

Details

Reference
bz18242

Event Timeline

bzimport raised the priority of this task from to Medium.Nov 21 2014, 10:36 PM
bzimport set Reference to bz18242.

ayg wrote:

The version numbers were removed because they were completely inaccurate. They reflected the last time the extension inclusion point changed, which was usually much less recently than other files in the extension (that actually did something) changed.

I've seen several times that rev numbers were too recent, compared to
actual changes to files. I was assuming the highest rev no of the entire repository at the time of the download was shown in Special:Version.
However, since there were no changes to files in the extension between the
download time and the most recent file change before the download,
there was no problem to me. For this extension, one could choose any
rev in between, and get an identical set of files, isn't that so?

Then it is a cosmetic, not a real problem.

ayg wrote:

The revision will normally be too outdated, not too recent, AFAIK. If it was too recent, then as you say, that wouldn't be a problem.

That would mean we have to file a bug against subverson?

ayg wrote:

No. There is no bug in Subversion. The revision marker we use only changes when the file itself is changed, by design. It is not intended to reflect the version of the repository as a whole, so we were misusing it.

Aha, understood.
Subversion does not support keword substitution for the version number of the whole repository, as of http://svnbook.red-bean.com/en/1.5/svn-book.html#svn.advanced.props.special.keywords at least, but I nevertheless think, such support would be useful, and should be added. I believe, it is even pretty easily implemented. But its a feature request rather than a bug ;-) I tried several times on the
Here it is now:

http://subversion.tigris.org/issues/show_bug.cgi?id=3389

hyrum wrote:

I've closed Subversion issue 3389 as INVALID. Please see the following FAQ to see why, and with a possible workaround:
http://subversion.tigris.org/faq.html#version-value-in-source

ayg wrote:

Without explicit Subversion support, we could probably do this by calling "svnversion" a few dozen times for every Special:Version view. But that only works for actual Subversion checkouts, not tarballs based off Subversion checkouts. We could include the .svn directory in the nightly extension tarballs, perhaps . . . then it would work as long as svn is installed (which it won't be on most shared hosting, if the software can even use exec() to begin with).

Another way to do this would be to use an on-commit hook of some kind. Or we could add the functionality to ExtensionDistributor, which would at least solve a fairly common case (this could be used in addition to allowing svnversion to be called for those who do a direct checkout).

(In reply to comment #7)

I've closed Subversion issue 3389 as INVALID. Please see the following FAQ to
see why, and with a possible workaround:
http://subversion.tigris.org/faq.html#version-value-in-source

I don't think it would be impossible for Subversion to do this efficiently. You'd "just" need to maintain an index of all files with the marker in them, checking each file for it whenever a change to it is committed. Then whenever the revision number is incremented, all files in the index are updated, and you don't have to scan all files in the repo. That might be way too much effort for such a minor feature, of course.

I talked about this with ^demon on IRC about a week ago, and we came up with the idea of having an extension version file that just contains basic version information (extension name, 1.2.3-formatted version and SVN revision) which would be auto-updated by an on-commit hook. Reading the file would work similar to how we read messages files with wfLoadExtensionMessages(), which means the file would be in PHP.

Revision number shown in the Special:Version

This is just a mockup of the Special:Version with the actual revision number added to each extension when using the svn checkout function. (The revision number are highlighted as yellow to easier to read, using on this picture only.)

Attached:

Hopfully fixed this on r49890. However the revision number is required to adding it into the *every* extension file on the credits part.