How to use fossil to automatic generate package version?

I want to generate my version number automatically. In git, I can use

pkgver() {
    cd local_repo
    printf "%s.%s" "$(git rev-list --count HEAD)" "$(git rev-parse --short HEAD)"
}

But, how could I do something similar with fossil? I know I could use manifest.uuid, but that can not provide a sequence number that is suitable to compare version updates.

Solution

I'm going to ignore the version numbering with the ###.### style because what will be more generally useful is to access an identifier unique across all checkins (even between branches) and folks can do with it whatever they like.

A simple number you can easily acquire is the number of unique checkins throughout the project's history. The following command provides this number...

fossil info

For the sake of demonstration, I cloned the fossil-scm repository to find the number of checkins...

project-name: Fossil
repository:   /home/faculty/xxxx/fossil_repos/fossil-scm/../fossil-scm.fossil
local-root:   /home/faculty/xxxx/fossil_repos/fossil-scm/
config-db:    /home/faculty/xxxx/.fossil
project-code: CE59BB9F186226D80E49D1FA2DB29F935CCA0333
checkout:     d3b2dabaa5eb64e1f73595bbe9e42d9586d5ac9e 2014-02-28 20:00:02 UTC
parent:       3d7eaeda866cc831d59abe2b1ddf15184aa14c4a 2014-02-28 19:31:38 UTC
tags:         trunk
comment:      re-generate other makefiles (user: jan.nijtmans)
checkins:     6713

I would extract this value one of two ways. First, if you have grep with the Perl extension ("-P")...

fossil info | grep -oP 'checkins:\s*\K\d+'

Not all grep installations will support this (the university I teach at supports this extension on only most systems), so you may want to go with sed instead (the example below uses GNU sed)...

fossil info | sed -n 's/checkins:[ \t]*//p'

In either case, for the example output provided above, each command will provide...

Also, to throw my thoughts out there, it's not all that pleasing an idea to me to get product version/build numbers from your SCM. The role of the SCM should be to track revisions of the product's code and other artifacts. Adding fossil-ized or git-ized code to your product couples the source to its SCM, even if only a little. So later, when you're wiser and you decide to switch SCMs (it happens, right?), you lose your old version numbering mechanism for another... but not because the numbering mechanism in your code was unsatisfactory.

Further, one reason I use fossil is because it allows members of my teams to use different SCMs for their remote development because fossil supports git natively and can be made to support other SCMs without much difficulty (like NetBSD did with fossil/CVS). In this kind of development environment, one doesn't want the code married to one SCM.

Anyway... just my two cents.

Good luck.