CODEWITHSUNDEEP
mercurialversioning
Ben
Ben

Reputation: 62336

Force version numbers with TortoiseHG

We have a Java application under Mercurial version control. We're working on implementing a versioning schema into the application and I'm wondering how TortoiseHG can help with this. Is it possible to do something like increment the build version when commits are made, or must this be soley up to the developer? Our current plan includes creating Bookmarks for each version number when we go to push to UAT.

Upvotes: 4

Views: 1218

Answers (2)

Laurens Holst
Laurens Holst

Reputation: 21026

It’s best to let the build system insert a current version identifier into your distribution archive and/or file name.

The first question is, how do you acquire this version identifier. There are basically three ways:

  1. By letting the build server issue a hg id command to find out the build error.
  2. By having a version file which is populated by a changegroup hook configured in your Mercurial repo configuration.
  3. By having a version file which is populated using the keyword extension. (Not recommended!)

The first approach directly pulls the info from Mercurial, which requires little to no set-up for developers. Downside is that it tightly couples the build system with the presence of a specific version control system.

The second approach stays independent of the repository system, and will remain usable if you e.g. build from a source archive, or if you want to manually specify a version label. Downside is that it does require you to set up a hook, however as build machines are usually specially configured central servers this ought not to be a big issue.

I mention the third approach for the sake of being complete, but I think it is universally agreed that you really want to avoid that mechanism.

It’s probably best to go for a hybrid approach of 1 and 2, which tries approach 2 first, and falls back on approach 1 when a version file can’t be found. To better support hg archive source exports, you could also check for an .hg_archival.txt file.

Second question is, what kind of value do you use for the build number:

  1. The version identifier (from hg id -i).
  2. The local revision number (from hg id -n).
  3. An identifier using latesttag and latesttagdistance, see Martin’s answer.

Advantage of the first is that it is rather simple and uniquely identifies the exact version that is built. It is not very human-readable though, and no relative age can be derived from the hash.

The second has an incremental number, however this number only applies to the repository of the build machine, so you should provide developers a means to loop up this number to get the changeset hash id, or it will be rather useless.

The third approach I personally particularly like, it gives temporal information using the tag and distance in a very human-readable way, and additionally specifies the node ID for the exact revision. It is rather long though.

Upvotes: 3

Martin Geisler
Martin Geisler

Reputation: 73748

In principle, you have to do this outside of TortoiseHg — the job of Mercurial (and hence TortoiseHg) is to preserve the state of your working copy exactly as it was when you clicked "Commit".

You might get a little help, though: TortoiseHg can trigger this "outside" action with a pre-commit hook. This is a script that is run before hg commit is run and that script has a chance to change files.

When you try to implement such a scheme, remember that Mercurial is a decentralized version control system (that should be no surprise...) and as such people make the commits locally without talking to a central server. It is therefore impossible to guarantee that a version number isn't used by someone else. The only workaround is to use a changeset hash as a version "number", but then you wont get nicely incrementing numbers. If you have a centralized build server, then you can let that increment the version number, though, and get back to a simple centralized world-view.

Finally, let me mention that Mercurial has a latesttagdistance template keyword that can be very helpful for the centralized build machine: it computes the distance down to the latest tag and this distance is generally monotonically increasing on a build machine. Use it like

hg parents --template "{latesttag}+{latesttagdistance}-{node|short}"

See the Mercurial setup.py file for more inspiration.

Upvotes: 9

Related Questions