Trying to use the svn revision number in the About Box to uniquely identify VStar versions does not always work as well as we would like. Instead, use a build number. Ant provides some support for this.
Comment: I like the current method where the number reflects the svn revision when I do a local build. This has a number of artifacts, though. For example, I was working with one of the CS-20Nov2009 tagged source packages. If I ran the SourceForge vstar.jar from the tag/dist on the command line it showed the old revision number that it was based on (294MP), but if I did a build from within the IDE is showed the (then) current svn that I had in my working directory (298) If I then updated using svn it showed the (new) current svn revision of (299M) after a build. Note that much of this is external to VStar and depends on my IDE. However, given that we are releasing this open source it is likely that others will be doing builds with different IDE methods.
I'll give some thought to how (ideally) I would prefer it to work. Perhaps we do need two systems: a current svn number in the local build, and a release number for the CS WebStart.
I frequently build, run and test more than one copy of VStar at a time and it would be handy to have some unique identifier to tell my windows apart and also to track which version has a bug reported by other members of the team.
Did some further digging and found this:
Perhaps this is a better way to go about it. Then we wouldn't have to go about copying the revisionaccesor around like crazy.
Have something like svnrevision-buildnumber?
Nevermind I just realized we'd still have to copy around the RevisionAccessor as that's the only way that SVN will update the revision number. Although we could still do the combination with the buildnumber to provide more info.
Could someone explain the meaning of the REVISION = string in RevisionAccessor? What does the number before the ":" signify?
When I do a local build and run, my IDE changes it from, for example, "294:296MP" to "301:304" and the About box shows "304"
If I run the vstar.jar from sourceforge w/o doing a build, I see "299M" in the About box.
Also, I did not commit the local update of RevisionAccessor when I built the most recent CS WebStart deployment. Should I have done this?
Correction: the recent vstar.jar from SF shows 301, and not 299M as in my prior post.
Hi Mike, to answer your second question first: yes, RevisionAccessor.java and anything else to be included as part of a release tag needs to be committed before the tag is created, including ChangeLog.txt.
Now, to answer your question about where the REVISION string comes from. This is generated by the first (exec) task in the Ant compile_src target in build.xml. That task uses the svnversion command. Here's the help message for that command:
tycho:vstar david$ svnversion --help
usage: svnversion [OPTIONS] [WC_PATH [TRAIL_URL]]
Produce a compact 'version number' for the working copy path
WC_PATH. TRAIL_URL is the trailing portion of the URL used to
determine if WC_PATH itself is switched (detection of switches
within WC_PATH does not rely on TRAIL_URL). The version number
is written to standard output. For example:
$ svnversion . /repos/svn/trunk
The version number will be a single number if the working
copy is single revision, unmodified, not switched and with
an URL that matches the TRAIL_URL argument. If the working
copy is unusual the version number will be more complex:
4123:4168 mixed revision working copy
4168M modified working copy
4123S switched working copy
4123P partial working copy, from a sparse checkout
4123:4168MS mixed revision, modified, switched working copy
If invoked on a directory that is not a working copy, an
exported directory say, the program will output 'exported'.
If invoked without arguments WC_PATH will be the current directory.
-n [--no-newline] : do not output the trailing newline
-c [--committed] : last changed rather than current revisions
-h [--help] : display this help
--version : show program version information
If the revision string generated is of the form n:m, RevisionAccessor.getRevNum() extracts the m value for use in the About Box.
If we could guarantee that VStar was only ever going to be built under some Unix flavor, we could instead using something like this instead of svnversion:
svn info | grep Revision | cut -d ' ' -f 2
But neither really gives us what we want. I think the requirements you state below would be best served by a build number, which Ant can help us with. This can be used in the About Box and also in the main VStar window if so desired. Build numbers are a common idiom. The ChangeLog.txt would tie together the build number with the release tag, and of course, from the tag can be determined the svn revision by looking at the repository's tags, e.g.
svn info https://vstar.svn.sourceforge.net/svnroot/vstar/tags/DEV-CS-22Nov2009
I will look at putting in place a build number after the Nov 30 release if that's okay with you.
Is this still a problem?
We don't really rely upon this in the same way now no, so closing.
Log in to post a comment.
Sign up for the SourceForge newsletter:
You seem to have CSS turned off.
Please don't fill out this field.