Monotone-increasing Version Number based on Mercurial Commits

When I was using subversion for the code for an application, I could append a period and the result of svnversion to the version number to create a unique and monotone-increasing version number and also be guaranteed that any check-out of the same revision of the code would generate the same version number.

In Mercurial, because revision numbers are not necessarily consistent across clones, the local revision number is not suitable. The hash is appropriately unique and consistent, but does not create a number that is monotone-increasing. How can I generate a suitable number to append to the version number based on the Mercurial repository commits?

edit: I have an application that has automatic update checking that is dependent on a version number that is a chain of period-separated whole numbers to determine whether or not a version is newer or not. It has become common that in the time between releases, I have some users trying out test builds. Often, these builds solve an issue the tester was having, so the tester stops using the released version and switches to the test build. My original goals in adding the additional component to the version number were to:

ensure that when the release came, those using the test build were automatically presented with the update as well
be able to easily tell if a tester was using the most recent test build

For example, the 0.5.0 release had version number 0.5.0.410; before 0.5.1 was released, there were test builds with version numbers 0.5.1.411, 0.5.1.420, and 0.5.1.421; then, the 0.5.1 release had version number 0.5.1.423.

Solution

Still in need of something to try to maintain ordering and matching of various development builds, I first tried using the unix timestamp of the last commit:

REV=$(hg tip --template '{date|hgdate}' | cut -f1 -d' ')

This, however, is annoyingly long (10 digits). (And, of course, it's not guaranteed to be unique, but on a project where I'm the only developer, the probability of two commits in the same second is essentially 0; in fact, the probability of two commits within 1 minute of each other is essentially 0.)

Since the "base" version number (the part to which this revision number is appended) only changes immediately after a tagged release, what I've ended up using is the number of minutes between the tip and the latest tagged ancestor:

HG_LAST_TAG_TIMESTAMP=$(hg log -r "$(hg log -r '.' --template '{latesttag}')" --template "{date|hgdate}\n" | cut -f1 -d' ')
HG_TIP_TIMESTAMP=$(hg log -r '.' --template "{date|hgdate}\n" | cut -f1 -d' ')
REV=$(( ($HG_TIP_TIMESTAMP - $HG_LAST_TAG_TIMESTAMP) / 60 ))

(edit: using tip was a mistake, as it refers to the latest commit to any branch; using log -r '.' refers to the revision on which the working copy is based.)