Monotone-increasing Version Number based on Mercurial Commits

Question

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.

Answer 1

You've pretty much hit the nail on the head. Using any monotonically-increasing local revision number can conflict with the distributed nature. There is no elegant way around this fundamental design decision.

Answer 2

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.)

Answer 3

As @Matthew said, you can't expect any comparison between version numbers across clones to be of any value. However, if you base your application around a single repository and always push back to that central repository from any clones then you could rely on that single central version number as long as you stuck to a single branch.

Essentially, if you use Mercurial in a way that mimics Subversion, i.e. with a single central repository, you can use version number as a marker on your application builds.

Hope this helps.