Brion Vibber wrote:
This produces massively incorrect numbers in many
cases, since the entry
point file is relatively rarely changed in non-trivial extensions
consisting of multiple files. Updates to the body, class, i18n, and
other files are not reflected.
Yes, this is the biggest argument against the use SVN keywords. SVN
keywords exist mostly for compatibility with CVS, otherwise, their use
is highly discouraged. If you need really want to use such type of
version numbering, you should consider creating some code that runs
'svnversion' and use its output as the version number. 'svnversion'
number also reflects working copies with mixed revisions and in modified
state.
But 'svnversion' itself has other problems. It has to quickly recurse
into all subdirectories in order to calculate the revision number. If
run once every (standalone) application startup, it is ok... for not for
a web application.
But the whole idea of using SVN version numbering for something outside
revision control is still problematic.
If we're running on a SVN checkout of the
extension, we could check the
directory for its current revision much as we do for MediaWiki itself;
this would tell us for instance if an extension's subdirectory has been
updated separately from the core MediaWiki.
This brings another set of problems. Check this for example:
http://juliano.info/en/Special:Version
It improperly detects that my MediaWiki version to be "r368", that is,
the version in *my* repository, not the official MediaWiki repository. I
use Subversion in a distributed way, through SVK, so my revision numbers
are private, have no meaning outside my repository. And the revision
number in Special:Version includes a link to MediaWiki's viewvc log for
revision 368, that means nothing in this scenario.
But if we aren't on a SVN checkout, or if
individual files have been
updated to different versions, this may or may not tell us anything useful.
The later problem is addressed through 'svnversion'.
Anybody have a suggestion on how to best handle this?
Forget using SVN revision number for anything outside revision control
itself.
You may want to create a VCSTimestamp.php containing just:
<?php
$wgVCSTimestamp = '20090101';
Have this file included in includes/DefaultSettings.php and this
variable appended to $wgVersion, ending with something like
"1.14alpha.svn{$wgVCSTimestamp}". Create a cron job that updates and
commits a new version of this file once every day.
This way, it is much more friendly to distributed revision control. You
may not know the specific revision of a checkout, but you can infer an
approximate checkout time (and a range of possible revisions). That is
enough to determine how old is a checkout or if it may contain some old bug.
People who replicate the repository will keep the same timestamp from
the upstream repository, and it will stay frozen until the next pull,
which is much more sensible.
Due to how MediaWiki's repository is structured, you probably want two
timestamp files, one for trunk/phase3/, another for trunk/extensions/.
For extensions, each one conditionally includes "../VCSTimestamp.php" if
found.
Also, the solution still applies when you move from SVN to a DVCS.
--
Juliano F. Ravasi ··
http://juliano.info/
5105 46CC B2B7 F0CD 5F47 E740 72CA 54F4 DF37 9E96
"A candle loses nothing by lighting another candle." -- Erin Majors
* NOTE: Don't try to reach me through this address, use "contact@" instead.