Add SVN revision number to trunk versions

[BrianKoontz]

(From DarTar): what if your nightly build packager, before the zipping/tarballing, added the revision number to a place where it could be easily detected, e.g. a file in the docs folder or maybe the WAKKA_VERSION stored in the config file (e.g. trunk_1019)? This would help us support people who run a version of trunk the probably cannot date in a precise way.

(From Brian): In addition, an SVN hook that automatically updates the WAKKA_VERSION whenever a trunk checkin is made would be useful!

[BrianKoontz]

(In [1020]) Modification to prevent setup wizard from being invoked when versions are appended with -<string> or _<string> (such as "trunk-r1019"). Refs #719

[BrianKoontz]

Changes to mkTrunk.pl (not under SVN control) have been made, so the first part of this task is ready for testing as of trunk-r1020.

[DarTar]

Brian, good job - as for point 2. I was wondering if we couldn't have a post-commit script change an SVN property of one or more files each time a commit is done. Post-commit hooks cannot affect versioned content (as a string in wikka.php for example), because that would obviously lead to inconsistencies, but properties are unversioned and I think they can be set automatically after a commit is successfully completed.

[BrianKoontz]

(In [1024]) Fixed minor type with version check that caused installer to loop forever. Refs #719.

[BrianKoontz]

(In [1025]) Installer was failing when both WAKKA_VERSION and wakka_version were set to the same annotated trunk-r<ver> format. Refs #719

[BrianKoontz]

(In [1128]) Automatically sets revision number as version number for trunk checkouts/exports. Must (still) be set manually for releases. Refs #719.

[BrianKoontz]

(In [1129]) Set revision prop on file. Refs #719.

[BrianKoontz]

(In [1133]) Testing, refs #719.

[BrianKoontz]

(In [1134]) Testing, refs #719.

[BrianKoontz]

(In [1135]) Testing, refs #719.

[BrianKoontz]

As can be seen in the most recent revision, Rev keyword substitution does not appear to work consistently...indeed, the SVN folks recommend using svnversion on the client side to determine the "global rev" of the tree, rather than depending upon the Rev keyword. Which begs the question, what purpose does the Rev keyword serve?

At any rate, it would appear that svn does not offer a consistent and robust method to automatically include revisions in source code, and must be done with an external kludge on the client. Given the platform-agnostic nature of Wikka, it would not make sense to attempt to write an external client-side script that would work on every platform, consistently. I suggest this ticket be closed as unworkable. It would, however, be a good place to keep track of methods used by other devs to automatically update the global revision number in wikka.php.

Barring any disagreement, I'll be reverting the changes in the near future.

[BrianKoontz]

(In [1136]) Testing, refs #719.

[BrianKoontz]

(In [1137]) Testing, refs #719.

[BrianKoontz]

(In [1138]) Testing, refs #719

[BrianKoontz]

OK, I've decided to leave the changes in place. svn does not permit "forced" commits, so it is up to the developer to create some change in wikka.php so that it's committed with the new svn revision. This is the best we'll get with svn...

[DarTar]

Brian, let's look around to see if other SVN-based projects have found a way around this. I'm afraid enforcing manual changes on each commit is not the best solution.

[DarTar]

For reference, here's the official answer from SVN:

 http://svnbook.red-bean.com/en/1.4/svn.advanced.props.special.keywords.html

(search for "Where's $GlobalRev$?")

[BrianKoontz]

Replying to DarTar:

Brian, let's look around to see if other SVN-based projects have found a way around this. I'm afraid enforcing manual changes on each commit is not the best solution.

I have found that most projects that try to imbed versioning in their source files use client-side scripts and svnversion, or have switched to other versioning systems. For projects that use some sort of make facility, the action is trivial: Simply imbed the version during the make process. That still falls under the category of using a client-side process to do the job.

[BrianKoontz]

(In [1146]) Testing, refs #719.

[BrianKoontz]

(In [1174]) Split out version functionality into separate file; only this new file (version.php) needs to be modified to update WAKKA_VERSION to the most current revision. Refs #719

[BrianKoontz]

(In [1175]) Testing, refs #719.

[BrianKoontz]

(In [1203]) Trying to get rev property to update properly, refs #719.

[BrianKoontz]

(In [1204]) Testing, refs #719.

[DarTar]

Retargeting to 1.3, this ticket has already been closed in trunk, from which 1.3 will be branched. Consider backporting urgent issues to 1.2.X

[DarTar]

(In [1526]) Bumping version number to 1.3, refs #719 and #912