Enter version numbers with TortoiseHG

Question

We have a Java application under the control of Mercurial. We are working on implementing a version control scheme in an application, and I wonder how TortoiseHG can help with this. Is it possible to do something like incrementing a build version when commits are made, or should it be done before the developer? Our current plan includes bookmarking for each version number when we go to UAT.

Answer 1

Basically, you should do this outside of TortoiseHg - the job of Mercurial (and therefore TortoiseHg) is to keep the state of your working copy exactly the same as when you clicked “Commit”.

You can get a little help: TortoiseHg can trigger this “external” action with a pre-commit hook . This is a script that runs before hg commit runs and that the script has the ability to modify files.

When you try to implement such a scheme, remember that Mercurial is a decentralized version control system (which is not surprising ...), and since such people perform local actions without talking to the central server. Therefore, it is not possible to guarantee that the version number is not used by someone else. The only workaround is to use the change set hash as the version number, but then you will not get beautifully increasing numbers. If you have a centralized build server, you can let this increase the version number and return to a simple centralized world view.

Finally, let me mention that Mercurial has the latesttagdistance template keyword , which can be very useful for a centralized assembly machine: it calculates the distance to the very last and this distance tends to increase monotonically on the assembly machine. Use it like

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

See Mercurial setup.py file for more details.

Answer 2

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

First question: how do you get this version identifier. There are three ways:

• By providing the build server the hg id command to find out the build error.
• Having a version file that is populated with the changegroup hook configured in your Mercurial repository configuration.
• Having a version file that is populated using the keyword extension. (Not recommended!)

The first approach directly pulls information from Mercurial, which for developers requires virtually no configuration. The disadvantage is that it tightly connects the build system with a specific version control system.

The second approach is independent of the repository system and will remain usable if, for example, you build from the source archive or if you want to manually specify the version label. The disadvantage is that it requires you to set the hook, however, since prefabricated machines are usually specially configured central servers, this should not be a big problem.

I mentioned the third approach in order to be complete, but I think I universally agree that you really want to avoid this mechanism.

Most likely, it is best to go for a hybrid approach 1 and 2, which will first try to approach 2 and go down to approach 1 when you can find the version file. To better support hg archive source export, you can also check the .hg_archival.txt file.

Second question: what value do you use for the build number:

• Version identifier (from hg id -i ).
• Local version number (from hg id -n ).
• Identifier using latesttag and latesttagdistance , see Martins answer.

The advantage of the first is that it is quite simple and uniquely identifies the exact version that is built. This is not very clear to humans, although relative age cannot be obtained from a hash.

The second has an incremental number, however this number only refers to the build machine repository, so you must give developers the ability to loop this number to get the change set hash identifier, or it will be useless.

The third approach, which I personally particularly like, provides temporary information using a tag and distance very convenient for human perception, and additionally indicates the node identifier for an accurate revision. This is quite a long time.