#72 Use build number in About Box

David Benn

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.


  • mikeu

    mikeu - 2009-11-22

    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.

  • Adam

    Adam - 2009-11-25

    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?

  • Adam

    Adam - 2009-11-25

    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.

  • mikeu

    mikeu - 2009-11-27

    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?

  • mikeu

    mikeu - 2009-11-27

    Correction: the recent vstar.jar from SF shows 301, and not 299M as in my prior post.

  • David Benn

    David Benn - 2009-11-28

    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.

    Valid options:
    -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.

  • Sara Beck

    Sara Beck - 2010-03-03
    • milestone: 952198 --> Enhancement_-_Phase_2
  • David Benn

    David Benn - 2010-06-14
    • priority: 8 --> 2
  • Sara Beck

    Sara Beck - 2011-01-06

    Is this still a problem?

  • David Benn

    David Benn - 2011-01-07

    We don't really rely upon this in the same way now no, so closing.

  • David Benn

    David Benn - 2011-01-07
    • status: open --> closed-wont-fix
  • David Benn

    David Benn - 2011-01-07
    • status: closed-wont-fix --> closed-out-of-date

Log in to post a comment.

Get latest updates about Open Source Projects, Conferences and News.

Sign up for the SourceForge newsletter:

No, thanks