JENKINS-7154 worked around this problem by adding a custom GitSCM/project-changes.jelly, but that just begs the question of why the default page has code which does nothing for an SCM which does not happen to provide a method named getRevision, and does something clearly wrong for an SCM which does.

To answer my own question: because SubversionChangeLogSet.LogEntry does define an public int getRevision() which is meaningful. Really it should have been the Subversion plugin which defined a custom project-changes.jelly with the special behavior of replacing list item numbers with Subversion revision numbers, a trick that of course is only meaningful for centralized SCMs which use integer revision numbers.

The various fix options are:

1. Remove value="${c.revision}" in core, override project-changes.jelly in the Subversion plugin, and eventually remove the project-changes.jelly override in the Git plugin (and anywhere else this might have been worked around) perhaps once the core fix makes it into an LTS release.

2. Work around in the Mercurial plugin the same way as in the Git plugin, basically compounding the error.

3. Change core to use getRevision only if it returns an Integer, rather than a String as the Git or Mercurial plugins would.

Code changed in jenkins
User: Jesse Glick
Path:
core/src/main/resources/hudson/scm/SCM/project-changes.jelly
http://jenkins-ci.org/commit/jenkins/63b829a482431cdd4e4592ca78799412f4dead5a
Log:
[FIXED JENKINS-14365] Show a ChangeLogSet.Entry.revision as a <li> value only if it is in fact an Integer.

Code changed in jenkins
User: Jesse Glick
Path:
changelog.html
http://jenkins-ci.org/commit/jenkins/051b0016c4500b317c904b88eb6398b13538f218
Log:
JENKINS-14365 Noted.

Compare: https://github.com/jenkinsci/jenkins/compare/3f8ea1923b37...051b0016c450

Integrated in jenkins_main_trunk #1805

Result = UNSTABLE