On 1/30/11 6:53 PM, Ville Voutilainen wrote:
On 30 January 2011 19:24, Mark Evensonevenson@panix.com wrote:
On 1/26/11 11:58 PM, Blake McBride wrote:
Greetings, I've got a suggestion regarding the startup message on development versions of abcl. Rather that just saying "-dev" why don't we say "-dev (XXX)" where XXX is the subversion revision number? This would make it much more clear about what you are running, and I'm pretty sure subversion can automatically provide and update this (I am doing it elsewhere).
We kicked this around once running into the following problems: The version of SVN source is not readable from the filesystem (i.e. via a grep), but needs the SVN libraries to access it. The executable 'svnversion' that does this is not always available (is it available under TotoiseSVN or not? I forget what the answer to this turned out to be…)
This seems a non-issue at least to abcl developers, so it's an issue only for people who build abcl themselves. Furthermore, at least on my system the version _is_ greppable from .svn/entries.
But Erik uses primarily Windows, and if TortoiseSVN doesn't contain 'svnrevision', he wouldn't be able to use this mechanism.
From my research, the format of '.svn/entries' is documented as opaque, changes between SVN versions, and would require quite a bit of regression chasing to pin down.
If you have a regexp that you think will work, please share.
- Since there is no SVN tag expansion (like $Revision$) that would
output the current SVN version, we have to move the canonical value
Uh what? The id expansions at the top of our files expand the revision as well as other information.
You are right. But if we were to use such expansion we would have to guarantee that the 'version' file is committed with *every* commit, and we would still have to detect if the local SVN copy had been modified at build.
- The file 'org/armedbear/lisp/version' will be created during the
build process (it currently is) with the base value appended with the string "-<OUTPUT of svnversion>" or "-unknown" if 'svnversion' couldn't be invoked. Examples would be "0.24.0-exported" "0.24.0-12344" "0.24.0-13111:13112M".
The middle one looks almost like what we're after, but it can just as well say "-dev" somewhere in the string. We have that information hardcoded in Version.java, so we should somehow get it from there and just append the revision number. It seems to be a simple problem and I'd expect a simple solution to work.
Those three examples are examples of the output of 'svnversion', so we would see all three in practice. The first string means that 'svnversion' can't determine the revision (i.e. there was no '.svn' directory. The second string means the build was an umodified 12344 revision. The third string means that the SVN sources are a mixture between r13111 and 13112 that were then modified (I think).
I hope this is simple to implement as well…