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.
We have a Java application under Mercurial version control. We’re working on implementing a
Share
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 commitis 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
latesttagdistancetemplate 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 likeSee the Mercurial
setup.pyfile for more inspiration.