When trying to describe this patch the words 'crazy' and 'wacko' come to mind, but believe it or not, this actually works _and_ it seems to be the only way to make --version use the svn revision correctly.
The current --version output only changes when superiotool.h is updated, which is not very useful, of course. This patch fixes it, in that all changes to *.c or *.h files bump the version number.
Note: You will not be able to easily test this before the commit. You'll get a segfault, as the $Rev$ instances will not be replaced until _after_ the commit. If you want you can manually change '$Rev$' to '$Rev: 2555 $' or so in all files (for testing)...
Uwe.
On 05.10.2007 19:46, Uwe Hermann wrote:
As the svn keyword $Rev$ is not replaced with the global repository ID but rather with the ID of the last commit which changed the respective file (where $Rev$ is located), the current --version output is incorrect.
This patch fixes the output by keeping a $Rev$ instance in every file (which can be different for every file) and then calculating the biggest revision (which is our superiotool version) at runtime when superiotool is invoked with --version.
This only takes *.c and *.h files into account, changes to the README and other non-code files will no be reflected in the version number. But this is actually a good thing in this case, we don't want to bump the version number upon README changes anyway.
Signed-off-by: Uwe Hermann uwe@hermann-uwe.de
Nack. Can we switch back to a more sensible versioning scheme (like 0.1 etc.) or at least ask some svn experts whether there is an easier and cleaner way to include a revision number? BTW, the $Rev$ output format is ugly beyond words.
Carl-Daniel
On Sat, Oct 06, 2007 at 12:00:50AM +0200, Carl-Daniel Hailfinger wrote:
On 05.10.2007 19:46, Uwe Hermann wrote:
As the svn keyword $Rev$ is not replaced with the global repository ID but rather with the ID of the last commit which changed the respective file (where $Rev$ is located), the current --version output is incorrect.
This patch fixes the output by keeping a $Rev$ instance in every file (which can be different for every file) and then calculating the biggest revision (which is our superiotool version) at runtime when superiotool is invoked with --version.
This only takes *.c and *.h files into account, changes to the README and other non-code files will no be reflected in the version number. But this is actually a good thing in this case, we don't want to bump the version number upon README changes anyway.
Signed-off-by: Uwe Hermann uwe@hermann-uwe.de
Nack. Can we switch back to a more sensible versioning scheme (like 0.1
That's not more sensible, IMO. We want a versioning which is automated (svn rev), so that we don't have to change it manually upon every commit (we'll surely forget that many times).
And I'm also pretty sure we want a per-commit version-number-update as superiotool is a moving target and we don't do (tarball) releases. We want to know exactly which svn revision a user was running for a specific superiotool dump output.
etc.) or at least ask some svn experts whether there is an easier and cleaner way to include a revision number?
Yeah, that would surely be great. Do you know any method or whom to ask? I browsed the svn code and manuals but didn't find anything better than $Rev$.
BTW, the $Rev$ output format is ugly beyond words.
Full ack.
That's why it has to be mangled quite a bit before usage. However, the final output looks ok IMO:
$ ./superiotool -v superiotool r2821
Uwe.
On Sat, Oct 06, 2007 at 12:30:06AM +0200, Uwe Hermann wrote:
etc.) or at least ask some svn experts whether there is an easier and cleaner way to include a revision number?
Yeah, that would surely be great. Do you know any method or whom to ask? I browsed the svn code and manuals but didn't find anything better than $Rev$.
Can't we do this with a commit hook that would update the version number (which is in 1 place only) automatically to the SVN revision number?
Thanks, Ward.
On 10/5/07, Ward Vandewege ward@gnu.org wrote:
On Sat, Oct 06, 2007 at 12:30:06AM +0200, Uwe Hermann wrote:
etc.) or at least ask some svn experts whether there is an easier and cleaner way to include a revision number?
Yeah, that would surely be great. Do you know any method or whom to ask? I browsed the svn code and manuals but didn't find anything better than $Rev$.
Can't we do this with a commit hook that would update the version number (which is in 1 place only) automatically to the SVN revision number?
I was going to suggest that the buildscript pull the current revision # out of SVN, but the idea of a commit hook sounds like it could be cleaner. Would the hook apply whenever any file is committed to the repository, or just to files in the superiotool directory?
Robinson Tryon wrote:
On 10/5/07, Ward Vandewege ward@gnu.org wrote:
On Sat, Oct 06, 2007 at 12:30:06AM +0200, Uwe Hermann wrote:
etc.) or at least ask some svn experts whether there is an easier and cleaner way to include a revision number?
Yeah, that would surely be great. Do you know any method or whom to ask? I browsed the svn code and manuals but didn't find anything better than $Rev$.
Can't we do this with a commit hook that would update the version number (which is in 1 place only) automatically to the SVN revision number?
I was going to suggest that the buildscript pull the current revision # out of SVN, but the idea of a commit hook sounds like it could be cleaner. Would the hook apply whenever any file is committed to the repository, or just to files in the superiotool directory?
Ideally only commits to the superiotool directory should count, since its a seperate utility.
but we might want the same thing for linuxbios, too, and add that number to EXTRA_VERSION or so then we know which repository revision people work on when reporting problems.
On Sat, 6 Oct 2007, Robinson Tryon wrote:
On 10/5/07, Ward Vandewege ward@gnu.org wrote:
On Sat, Oct 06, 2007 at 12:30:06AM +0200, Uwe Hermann wrote:
etc.) or at least ask some svn experts whether there is an easier and cleaner way to include a revision number?
Yeah, that would surely be great. Do you know any method or whom to ask? I browsed the svn code and manuals but didn't find anything better than $Rev$.
Can't we do this with a commit hook that would update the version number (which is in 1 place only) automatically to the SVN revision number?
I was going to suggest that the buildscript pull the current revision # out of SVN, but the idea of a commit hook sounds like it could be cleaner. Would the hook apply whenever any file is committed to the repository, or just to files in the superiotool directory?
NACK. svn commit hooks should not change the contents of the commit, at least not according to the svn book (client side caching problems might occur).
I've attached a patch that during build time extracts the svn revision from $Rev$ comments in each source file, and keeps the extracted value up to date using make.
Direct application of the patch might give one failure on superiotool.h (it has the expanded $Rev$ in your working directory), and compilation failure on superiotool.c, since the new $Rev$'s haven't yet been expanded (these two issues should not appear when receiving the patch through 'svn update'). For testing I expanded the $Rev$ by hand to the corresponding svn revisions, and then it worked like a charme:
$ make sed -ne 's/.*Rev: ([0-9]*) .*/\1/p' ali.c fintek.c ite.c nsc.c smsc.c superiotool.c winbond.c superiotool.h \ | sort -n \ | tail -1 \ | sed 's/.*/#define SUPERIOTOOL_VERSION "&"/' >version.h gcc -O2 -Wall -Werror -Wstrict-prototypes -Wundef -Wstrict-aliasing -Werror-implicit-function-declaration -ansi -c -o superiotool.o superiotool.c gcc -O2 -Wall -Werror -Wstrict-prototypes -Wundef -Wstrict-aliasing -Werror-implicit-function-declaration -ansi -c -o ali.o ali.c gcc -O2 -Wall -Werror -Wstrict-prototypes -Wundef -Wstrict-aliasing -Werror-implicit-function-declaration -ansi -c -o fintek.o fintek.c gcc -O2 -Wall -Werror -Wstrict-prototypes -Wundef -Wstrict-aliasing -Werror-implicit-function-declaration -ansi -c -o ite.o ite.c gcc -O2 -Wall -Werror -Wstrict-prototypes -Wundef -Wstrict-aliasing -Werror-implicit-function-declaration -ansi -c -o nsc.o nsc.c gcc -O2 -Wall -Werror -Wstrict-prototypes -Wundef -Wstrict-aliasing -Werror-implicit-function-declaration -ansi -c -o smsc.o smsc.c gcc -O2 -Wall -Werror -Wstrict-prototypes -Wundef -Wstrict-aliasing -Werror-implicit-function-declaration -ansi -c -o winbond.o winbond.c gcc -O2 -Wall -Werror -Wstrict-prototypes -Wundef -Wstrict-aliasing -Werror-implicit-function-declaration -ansi -o superiotool superiotool.o ali.o fintek.o ite.o nsc.o smsc.o winbond.o $ ./superiotool --version superiotool r2828
/ulf
On 10/6/07, Ulf Jordan jordan@chalmers.se wrote:
On Sat, 6 Oct 2007, Robinson Tryon wrote:
On 10/5/07, Ward Vandewege ward@gnu.org wrote:
On Sat, Oct 06, 2007 at 12:30:06AM +0200, Uwe Hermann wrote:
etc.) or at least ask some svn experts whether there is an easier and cleaner way to include a revision number?
Yeah, that would surely be great. Do you know any method or whom to ask? I browsed the svn code and manuals but didn't find anything better than $Rev$.
Can't we do this with a commit hook that would update the version number (which is in 1 place only) automatically to the SVN revision number?
I was going to suggest that the buildscript pull the current revision # out of SVN, but the idea of a commit hook sounds like it could be cleaner. Would the hook apply whenever any file is committed to the repository, or just to files in the superiotool directory?
NACK. svn commit hooks should not change the contents of the commit, at least not according to the svn book (client side caching problems might occur).
I've attached a patch that during build time extracts the svn revision from $Rev$ comments in each source file, and keeps the extracted value up to date using make.
Direct application of the patch might give one failure on superiotool.h (it has the expanded $Rev$ in your working directory), and compilation failure on superiotool.c, since the new $Rev$'s haven't yet been expanded (these two issues should not appear when receiving the patch through 'svn update'). For testing I expanded the $Rev$ by hand to the corresponding svn revisions, and then it worked like a charme:
What about pulling the version directly out of SVN at build time? Like this:
svn info | sed -n 's/.*Revision: ([0-9]*)/\1/ p'
As long as the Makefile lives at the top level of the project, this value should always reflect the latest commit in the current checkout.
On Sat, 6 Oct 2007, Robinson Tryon wrote:
What about pulling the version directly out of SVN at build time? Like this:
svn info | sed -n 's/.*Revision: ([0-9]*)/\1/ p'
As long as the Makefile lives at the top level of the project, this value should always reflect the latest commit in the current checkout.
That looks like a good solution.
I read a bit in the svn book, and they recommend using svnversion for getting a "global" revision number for a set of files. However, that tool seems to have a bit more varying output, reflecting local changes and mixed revsion numbers etc.
/ulf
On Sat, 6 Oct 2007, Ulf Jordan wrote:
On Sat, 6 Oct 2007, Robinson Tryon wrote:
What about pulling the version directly out of SVN at build time? Like this:
svn info | sed -n 's/.*Revision: ([0-9]*)/\1/ p'
As long as the Makefile lives at the top level of the project, this value should always reflect the latest commit in the current checkout.
That looks like a good solution.
Attached is the much shorter patch using Robinson's suggestion to get the svn revision number as the superiotool version number.
/ulf
On 10/6/07, Ulf Jordan jordan@chalmers.se wrote:
On Sat, 6 Oct 2007, Ulf Jordan wrote:
On Sat, 6 Oct 2007, Robinson Tryon wrote:
What about pulling the version directly out of SVN at build time? Like this:
svn info | sed -n 's/.*Revision: ([0-9]*)/\1/ p'
As long as the Makefile lives at the top level of the project, this value should always reflect the latest commit in the current checkout.
That looks like a good solution.
Attached is the much shorter patch using Robinson's suggestion to get the svn revision number as the superiotool version number.
Looks good.
* Robinson Tryon bishop.robinson@gmail.com [071006 17:42]:
What about pulling the version directly out of SVN at build time? Like this:
svn info | sed -n 's/.*Revision: ([0-9]*)/\1/ p'
As long as the Makefile lives at the top level of the project, this value should always reflect the latest commit in the current checkout.
unless you svn up certain subdirectories..
On 10/6/07, Stefan Reinauer stepan@coresystems.de wrote:
- Robinson Tryon bishop.robinson@gmail.com [071006 17:42]:
What about pulling the version directly out of SVN at build time? Like this:
svn info | sed -n 's/.*Revision: ([0-9]*)/\1/ p'
As long as the Makefile lives at the top level of the project, this value should always reflect the latest commit in the current checkout.
unless you svn up certain subdirectories..
I believe that my statement is still correct: the revision in the binary will reflect the latest commit present in the current checkout. Of course, if that commit included files in a subdirectory as well as at the top level, then you could have the problem of only pulling-down half of a commit!
The only way I could see this causing a problem would be if someone tried to build a binary without doing a top-level update.... but that is pure folly, eh?
On Sat, 6 Oct 2007, Stefan Reinauer wrote:
- Robinson Tryon bishop.robinson@gmail.com [071006 17:42]:
What about pulling the version directly out of SVN at build time? Like this:
svn info | sed -n 's/.*Revision: ([0-9]*)/\1/ p'
As long as the Makefile lives at the top level of the project, this value should always reflect the latest commit in the current checkout.
unless you svn up certain subdirectories..
Also svn:externals gives problems, even "svn info -R" wont go down into them.
There are also a few other problems:
svn info is internationalized, so for sed to work reliably LANG=C is needed.
.*Revision: will read out the revision from the latest svn up.
Last Changed Rev: will read out the latest comitted change, which is more what we desire.
svnversion -c might be better, but it doesn't recurse, and has an interesting output format in the general case (but sed will fix it!)
To summarize some pros & cons:
1. $Rev$-based in files (at run time or build time):
+ granular control of which files' revisions are considered
+ clearly calculates version number only from desired files
+ does not depend on svn during build
- more complex, need to remember which files to tag with $Rev$-based code
2. svn build time based
+ easy to code both in source and makefiles
- need to be careful about which svn revision numbers are actually used to determine the "global" version number (latest svn up or comitted)
- recursion down into subdirectories and svn:externals needs to be carefully considered
- makes the build environment dependent on svn and svn meta data, which may cause concern in external automated build environments (like OS distributors)
/ulf
On Sat, 6 Oct 2007, Ulf Jordan wrote:
svnversion -c might be better, but it doesn't recurse, and has an interesting output format in the general case (but sed will fix it!)
The issue of how to derive version numbers from svn revision information is indeed non-trivial, as shown by our discussion here and on other lists like the Subversion users' list.
To obtain a global revision number from a working copy there is a very good example in the svn FAQ (it's the only one in a red box, so I guess it's really frequently asked):
http://subversion.tigris.org/faq.html#version-value-in-source
However, I believe we don't want the superiotool version to increase just because there are other commits in the v2 tree, so the example needs adapting by adding -c to svnversion.
Attached is a patch that:
* derives the superiotool version number from the latest committed change to superiotool files (NOT the latest svn up of the superiotool directory)
* strips away extra information from svnversion, to arrive at a single version number like 2828 instead of 2814:2828M ("this build is made up of files with latest modification in rev 2814 to 2828 plus local modifications").
* does not recurse down into subdirectories or svn:externals (there are no such things in superiotool for the moment)
* does all the work in determining the version number at build time
* depends on GNU make features (although it could be rewritten more portably using a version.h file instead, like my previous patch)
This approach could easily be combined with a traditional version number from a #define in superiotool.h, as Robinson pointed out.
Corey: if you apply this patch to current svn superiotool, does the trailing garbage go away?
/ulf
On Sun, Oct 07, 2007 at 11:09:24AM +0200, Ulf Jordan wrote:
However, I believe we don't want the superiotool version to increase just because there are other commits in the v2 tree, so the example needs adapting by adding -c to svnversion.
That's no problem IMO. The important thing is that the version _does_ increase if we change superiotool files. If it also increases upon other changes, well, we can live with that...
Attached is a patch that:
- derives the superiotool version number from the latest committed change
to superiotool files (NOT the latest svn up of the superiotool directory)
Hm, isn't that wrong? We want to know the extact version from which the binary was built, _not_ the most current version in the repository at the time it was built...
- strips away extra information from svnversion, to arrive at a single
version number like 2828 instead of 2814:2828M ("this build is made up of files with latest modification in rev 2814 to 2828 plus local modifications").
Hm, maybe that would even be a good thing? We could tell from that output that a user used a modified version and ask for a diff...
- does not recurse down into subdirectories or svn:externals (there are no
such things in superiotool for the moment)
Yep, not needed.
does all the work in determining the version number at build time
depends on GNU make features (although it could be rewritten more
portably using a version.h file instead, like my previous patch)
Maybe we could do this later, but it's fine for now. GNU Make should be available almost everywhere.
This approach could easily be combined with a traditional version number from a #define in superiotool.h, as Robinson pointed out.
Not needed and not useful. We don't want to confuse people with _two_ versioning systems.
Index: Makefile
--- Makefile (revision 2828) +++ Makefile (working copy) @@ -24,14 +24,19 @@ INSTALL = /usr/bin/install PREFIX = /usr/local
+SVNDEF := -D'SUPERIOTOOL_VERSION="$(shell svnversion -cn . \
| sed -e "s/.*://" -e "s/\([0-9]*\).*/\1/")"'
Please add a comment here which explains what the contents of the variable will be (svn rev of latest commit etc...), how it works, etc.
Personally, I like this approach. Either this one, or the one from my patch (which doesn't require svn at build-time). That's a small issue though, distributors can easily work around it by patching the Makefile.
If nobody complains, let's commit this ASAP so we have a working version in the repository. We can still continue the discussions to improve the version handling later, if necessary.
Uwe.
On Mon, 8 Oct 2007, Uwe Hermann wrote:
On Sun, Oct 07, 2007 at 11:09:24AM +0200, Ulf Jordan wrote:
Attached is a patch that:
- derives the superiotool version number from the latest committed change
to superiotool files (NOT the latest svn up of the superiotool directory)
Hm, isn't that wrong? We want to know the extact version from which the binary was built, _not_ the most current version in the repository at the time it was built...
My formulation was inexact. svnversion shows the local revisions of the working copy, not the repository. What I meant to say was:
* derives the superiotool version number from the highest revision number of the checked out superiotool files (NOT the revision number from latest svn up of the superiotool directory)
- strips away extra information from svnversion, to arrive at a single
version number like 2828 instead of 2814:2828M ("this build is made up of files with latest modification in rev 2814 to 2828 plus local modifications").
Hm, maybe that would even be a good thing? We could tell from that output that a user used a modified version and ask for a diff...
Yes maybe. More information at the expense of a more odd looking version number.
The stripping is implemented by the sed invocation, without which we would get the more detailed information. I'll leave it as is, awaiting further discussion on what we actually want to show in the version number.
This approach could easily be combined with a traditional version number from a #define in superiotool.h, as Robinson pointed out.
Not needed and not useful. We don't want to confuse people with _two_ versioning systems.
OK.
Index: Makefile
--- Makefile (revision 2828) +++ Makefile (working copy) @@ -24,14 +24,19 @@ INSTALL = /usr/bin/install PREFIX = /usr/local
+SVNDEF := -D'SUPERIOTOOL_VERSION="$(shell svnversion -cn . \
| sed -e "s/.*://" -e "s/\([0-9]*\).*/\1/")"'Please add a comment here which explains what the contents of the variable will be (svn rev of latest commit etc...), how it works, etc.
OK, added.
Attached is an updated patch.
/ulf
On Mon, Oct 08, 2007 at 10:03:10AM +0200, Ulf Jordan wrote:
Set the superiotool version number from svn at build time.
Signed-off-by: Ulf Jordan jordan@chalmers.se
Thanks, committed in r2852. This is the best solution IMHO.
Uwe.
On Sat, Oct 13, 2007 at 08:07:06PM +0200, Uwe Hermann wrote:
Set the superiotool version number from svn at build time.
Thanks, committed in r2852. This is the best solution IMHO.
Nice and neat.
What is the suggestion for projects with subdirectories?
//Peter
On Sun, 14 Oct 2007, Peter Stuge wrote:
Nice and neat.
What is the suggestion for projects with subdirectories?
I'll look into that and report back to the list when I get back in the middle of the upcoming week.
/ulf
On Sun, 14 Oct 2007, Peter Stuge wrote:
What is the suggestion for projects with subdirectories?
A generalized pipeline using svnversion when there are subdirectories (possibly coming from svn:externals) could be:
find . -type d \ | grep -v ".svn" \ | xargs -i svnversion -c {} \ | sed -e "s/.*://" -e "s/([0-9]*).*/\1/" \ | sort -un \ | tail -1
/ulf
Uwe Hermann wrote:
On Sat, Oct 06, 2007 at 12:00:50AM +0200, Carl-Daniel Hailfinger wrote:
BTW, the $Rev$ output format is ugly beyond words.
Full ack.
That's why it has to be mangled quite a bit before usage. However, the final output looks ok IMO:
$ ./superiotool -v superiotool r2821
Uwe.
Not here it doesn't:
amp@hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v superiotool r2821�z�� amp@hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v superiotool r2821���� amp@hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v superiotool r2821�� amp@hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v superiotool r2821���� amp@hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v superiotool r2821�*�� amp@hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v superiotool r2821� amp@hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v superiotool r2821�:��
I agree with Carl-Daniel, that we should probably switch to a non-svn based versioning scheme. For now, it avoids the headache of "how do we do it". It also means that down the road if we don't touch superiotool for 6 months, the version hasn't been bumped 300 times by LinuxBIOSv2 commits, without ever touching the tool. Which means that if this ever starts making it into packages, maintainers don't have the headache of trying to figure out if there actually is an updated version or not. Just my 2 cents.
-Corey
Corey Osgood wrote:
Uwe Hermann wrote:
On Sat, Oct 06, 2007 at 12:00:50AM +0200, Carl-Daniel Hailfinger wrote:
BTW, the $Rev$ output format is ugly beyond words.
Full ack.
That's why it has to be mangled quite a bit before usage. However, the final output looks ok IMO:
$ ./superiotool -v superiotool r2821
Uwe.
Not here it doesn't:
amp@hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v superiotool r2821�z�� amp@hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v superiotool r2821���� amp@hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v superiotool r2821�� amp@hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v superiotool r2821���� amp@hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v superiotool r2821�*�� amp@hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v superiotool r2821� amp@hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v superiotool r2821�:��
Also just noticed it doesn't work:
amp@hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v superiotool r2821�: amp@hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ svn info Path: . URL: svn://linuxbios.org/repos/trunk/util/superiotool Repository Root: svn://linuxbios.org/repos Repository UUID: 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1 Revision: 2828 Node Kind: directory Schedule: normal Last Changed Author: uwe Last Changed Rev: 2828 Last Changed Date: 2007-10-05 17:58:03 -0400 (Fri, 05 Oct 2007)
-Corey
On Sat, Oct 06, 2007 at 01:53:22PM -0400, Corey Osgood wrote:
BTW, the $Rev$ output format is ugly beyond words.
Full ack.
That's why it has to be mangled quite a bit before usage. However, the final output looks ok IMO:
$ ./superiotool -v superiotool r2821
Not here it doesn't:
amp@hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v superiotool r2821�z�� amp@hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v superiotool r2821���� amp@hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v superiotool r2821�� amp@hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v superiotool r2821���� amp@hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v superiotool r2821�*�� amp@hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v superiotool r2821� amp@hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v superiotool r2821�:��
Hm, is that random junk at the end of the version? In that case there's a bug somewhere in my code. Should be fixable, though.
Also just noticed it doesn't work:
amp@hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ ./superiotool -v superiotool r2821�: amp@hp:~/linuxbios/lb_clean/LinuxBIOSv2/util/superiotool$ svn info Path: . URL: svn://linuxbios.org/repos/trunk/util/superiotool Repository Root: svn://linuxbios.org/repos Repository UUID: 2b7e53f0-3cfb-0310-b3e9-8179ed1497e1 Revision: 2828 Node Kind: directory Schedule: normal Last Changed Author: uwe Last Changed Rev: 2828 Last Changed Date: 2007-10-05 17:58:03 -0400 (Fri, 05 Oct 2007)
That's expected, it won't work until you commit (and do
$ svn ps svn:keywords "Author Date Id Rev URL" *.[ch]
before committing). That's contained in the patch, but the svn properties are not applied when you simply use 'patch' to apply the patch...
Uwe.
Uwe Hermann wrote
That's expected, it won't work until you commit (and do
$ svn ps svn:keywords "Author Date Id Rev URL" *.[ch]
before committing). That's contained in the patch, but the svn properties are not applied when you simply use 'patch' to apply the patch...
Uwe.
Oops, my bad. I thought the patch had already been applied to the tree. Excuse my ignorance, sorry.
On another note, can we print something when superiotool is run without any parameters and fails to find any Super IO?
-Corey
On Sat, Oct 06, 2007 at 11:01:29PM -0400, Corey Osgood wrote:
On another note, can we print something when superiotool is run without any parameters and fails to find any Super IO?
Good point, yes. Fixed in r2835.
Uwe.
On 10/6/07, Corey Osgood corey.osgood@gmail.com wrote:
I agree with Carl-Daniel, that we should probably switch to a non-svn based versioning scheme. For now, it avoids the headache of "how do we do it". It also means that down the road if we don't touch superiotool for 6 months, the version hasn't been bumped 300 times by LinuxBIOSv2 commits, without ever touching the tool. Which means that if this ever starts making it into packages, maintainers don't have the headache of trying to figure out if there actually is an updated version or not. Just my 2 cents.
The patch that Ulf and I made should bump the revision number if (and only if) one of the files in the superiotool/ directory changes.
I agree that using the SVN rev as the version # seems a little non-standard, but when people mail in dumps to the list, it's really nice to know exactly which version of the code was in the binary that made that dump. What if the version # were something more standard and we just printed out the SVN rev alongside it? Something like:
superiotool v0.2 -- built from svn r255687 on Sat Oct 6 13:56:31 EDT 2007
-
Carl-Daniel Hailfinger -
Corey Osgood -
Peter Stuge -
Robinson Tryon -
Stefan Reinauer -
Ulf Jordan -
Uwe Hermann -
Ward Vandewege