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.