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 o开发者_如何学编程r 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.

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.

This is how Fog Creek does the build versioning using Mercurial + some other suggestions: http://kiln.stackexchange.com/questions/2194/best-practice-generating-build-numbers

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.

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

I'm using hg log -r 'ancestors(.)' from this answer in conjunction with a simple --template and wc -w to count the amount of ancestors that a given changeset has.

This number is fixed for a given changeset as it depends on the changeset's history. It doesn't depend on the order changesets arrived in the repo. That is, it is global (unlike Mercurial's local revision numbers) as a given changeset always carries with it the full history of all its ancestors. However, it is a nicer and more useful numeric value to a user than the node ID hash. Within a given branch it allows to compare and sort the amount of ancestors.

You do still have to keep track of branches, if you use them, but this number is less of a hassle to preserve and communicate than the local revision number.

Other than the branches I believe this is close to the monotonically increasing revision number that you want. It might be useful to include a branch name along with the amount of ancestors to avoid duplicates across different branches.

Here's the changeset I linked above:

mak.sh: in revision ID string include amount of ancestors

This number is both fixed for a given changeset whereever it goes and also allows to compare two numbers, assuming they're on the same branch, to one another to figure out which one is "later" or more advanced, so to say.

-  [ -z "$build_revision_id" ] && build_revision_id="hg $(hg id -i)"
+  [ -z "$build_revision_id" ] \
+    && build_revision_id="hg $(hg id -i) ($( \
+      hg log -r 'ancestors(.)' --template '1 ' | wc -w) ancestors)"