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).
Thanks.
Blake McBride
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…)
The second reason is that we need to keep the Lisp-based build in somewhat of a parity here, since we're talking about modifying the value of LISP-IMPLEMENTATION-VERSION. Not impossible, but extra work than just hacking 'build.xml'.
The third reason is a non-reason: one of the developers (me), actually manages the ABCL source via Mercurial-to-svn bridge, so since the information wouldn't be that useful to me, I wasn't really motivated to provide such a functionality. Since I am the developer who usually ends up hacking the Ant build system, this feature never got addressed.
But given the number of people who track trunk, and that Alan had leaned on us heavily before for this functionality I acknowledge we should probably implement something along these lines. We certainly have a vested interest in more accurate and easy bug reports that this would provide.
A quick description of the outstanding questions for an implementation:
0. Since there is no SVN tag expansion (like $Revision$) that would output the current SVN version, we have to move the canonical value outside of org.armedbear.Version to a separate file. Version.java will then only contain the base value "x.y.z" (i.e. "0.24.0") for the branch.
1. 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".
2. Production versions will be built without this version file.
3. The current use of "version.src" in 'abcl.properties' (which places the Implementation-Source value in the jar manifest) will be replaced with this mechanism.
4. The code in Version.java will look for the 'version' file on the default classloader. If it exists, it will remember and use this value for future invocations. If it doesn't exist, it will output its base value.
Some problems
1. We would then lose the clear distinction that "0.25.0-dev" conveys (i.e. that this isn't a production version). Should we have a string like "0.25.0-dev-12344"?
2. I'm assuming that branched releases should not include the SVN version, but not exactly sure how to detect that. Maybe place the base value in a top-level file that gets manually changed when we branch?
3. 'exported' is the value that 'svnversion' gives when it can't determine the SVN revision associated with the source. Maybe we should changed this to 'unknown' or something a little more informative? Maybe 'undetermined'?
4. I'd like to indicate to the user that the output of 'svnversion' indicates the SVN version, but "0.24.0-dev-svn-13111:13112M" seems kind of long, but maybe it makes sense (if we follow my solution to problem #1).
Comments, ideas, directions, please.
On 30 January 2011 19:24, Mark Evenson evenson@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.
- 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.
- 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.
On Jan 30, 2011, at 12:53, Ville Voutilainen wrote:
- 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.
That is the last-changed revision of that individual file. It will not advance, even on a fresh checkout, as long as that file is not modified.
svnversion is the right tool for this job, as it scans the entire working copy and produces an appropriate summary.
svnversion is the right tool for this job, as it scans the entire working copy and produces an appropriate summary.
I just checked that TortoiseSVN doesn't have the svnversion command. It has a SubWCRev command which works entirely different.
So, from where I stand now, I think it's ok to depend on svnversion being on the PATH on all OSes.
However, it would be too bad if we strictly depended on having Subversion available; especially if that would apply to our source code distributions. If we can come up with a scheme where we can prevent the version file from being overwritten when building from such a tarball, I don't see any issues with such a feature anymore.
Bye,
Erik.
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…
On 30 January 2011 20:10, Mark Evenson evenson@panix.com wrote:
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
Can't we update the version file with a post-commit hook?
we would still have to detect if the local SVN copy had been modified at build.
How could we do that?
Hi Ville,
On Sun, Jan 30, 2011 at 6:53 PM, Ville Voutilainen ville.voutilainen@gmail.com wrote:
On 30 January 2011 19:24, Mark Evenson evenson@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.
Yes. However, that file will disappear in 1.7 and the layout of that file has changed roughly in every release since svn 1.0. That's why the developers of Subversion say that you need to use the subversion libraries to query the version info.
- 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.
Right. But that's the revision of *that* file (the one in which the file was last changed), not the revision of the entire tree. Files which don't receive updates don't have their $Id$ updated.
- 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.
I see Mark already explained these outputs quite correctly.
Bye,
Erik. PS: I'll look up if TSVN contains 'svnversion' as well.
On 1/30/11 6:24 PM, Mark Evenson 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).
[…]
After reviewing the (damn quick, thanks!) feedback, I've committed implementation of my proposal [in r13197][1]. Now, In the Ant-based build, if the executable 'svnversion' can be found on the PATH and the topmost '.svn' subdirectory exists, the output of 'svnversion' is appended to the value returned by LISP-IMPLEMENTATION-VERSION (which is what appears in the ABCL banner).
[1]: http://trac.common-lisp.net/armedbear/changeset/13197
The only suboptimal part of my implementation is that we produce a lot of weird looking "empty" targets ('abcl.version.src.0', 'abcl.version.src.1', etc.) as is necessary to get around Ant's lack of conditional properties on all tasks. If there is an more aesthetically pleasant way to do this with core Ant (i.e. without adding code or jars to Ant), I'd be happy to learn about it…
To finish this issue:
1) test under Windows (and in general), possibly adapting to the presence of other methods of retrieving SVN information (like what TortoiseSVN provides).
2) implement the same algorithm in the Lisp-based build
3) (weakly necessary) provide an extension mechanism to customize the information
Hi Mark,
On Sun, Jan 30, 2011 at 11:33 PM, Mark Evenson evenson@panix.com wrote:
On 1/30/11 6:24 PM, Mark Evenson 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).
[…]
After reviewing the (damn quick, thanks!) feedback, I've committed implementation of my proposal [in r13197][1]. Now, In the Ant-based build, if the executable 'svnversion' can be found on the PATH and the topmost '.svn' subdirectory exists, the output of 'svnversion' is appended to the value returned by LISP-IMPLEMENTATION-VERSION (which is what appears in the ABCL banner).
Thanks! I'm now running a build on Linux to see what I should have seen, but I think I already know.
On Windows, there's an error: the output hasn't changed. I think I know what the error is: svnversion doesn't exist in the PATH; it's svnversion.exe which does....
Testing that assumption now....
[5 minutes later] nope. I'm not seeing the same output as in Linux. Any ideas?
Thanks for the quick turn-around on the feature!
Bye,
Erik.
On 1/30/11 11:49 PM, Erik Huelsmann wrote: […]
On Windows, there's an error: the output hasn't changed. I think I know what the error is: svnversion doesn't exist in the PATH; it's svnversion.exe which does....
Testing that assumption now....
[5 minutes later] nope. I'm not seeing the same output as in Linux. Any ideas?
One thing might be that the condition for abcl.version.svn.p might be failing if
<available file="svnversion" filepath="${env.PATH}"/>
is wrong. I read a note indicating that the system path in Windows 2000 is case sensitive, so this would be
<available file="svnversion" filepath="${env.Path}"/>
I ignored this advice, figuring that it didn't apply to WinXP and its successors.
To debug, I'd add a line like
<echo>abcl.version.svn.p: ${abcl.version.svn.p}</echo>
to the 'abcl.stamp.version' target, and try various things to get this value to be 'true'.
Hopefully, I can get some time tomorrow to figure out what's wrong under Windows.
You guys know about http://svnbook.red-bean.com/en/1.4/svn.advanced.props.special.keywords.html? Basically you enable the keyword substitution you want and it gets substituted into a pattern you put in files, when you either check in or check out (can't remember which). -Alan
On 1/31/11 2:27 AM, Alan Ruttenberg wrote:
You guys know about http://svnbook.red-bean.com/en/1.4/svn.advanced.props.special.keywords.html? Basically you enable the keyword substitution you want and it gets substituted into a pattern you put in files, when you either check in or check out (can't remember which).
Yes, we considered that, but the problem is that there isn't a $GlobalRev$ variable, so the Version.java file would have to be part of the commit. And we would lose the information emitted by svnversion when the local SVN tree has applied patches. 'svnversion' doesn't say what patches have been applied, but it does indicate that the build can't be easily reproduced via a simple svn checkout.
I think you'll be pretty happy with what we have implemented in trunk using 'svnversion'. Users on UNIX and OSX should have everything "just work" as 'svnversion' is (almost) always present.
Let us know if what is in trunk doesn't work for you, and we'll try to patch further.
armedbear-devel@common-lisp.net
-
Alan Ruttenberg -
Blake McBride -
Erik Huelsmann -
Kevin Reid -
Mark Evenson -
Ville Voutilainen