8

I've recently started using mercurial for version control in a Java project. When I run my program, the input parameters it has used to produce certain a output, are written to a specific file. It would be nice if I could add the current mercurial changeset number (indicating the version of my program) to that output file as well.

What would be the easiest way to do so on Windows? I could write a simple Java parser to fetch the output of the first line of the hg log -l 1 command, but perhaps there is an easier way (i.e., less code lines)?

Rabarberski
  • 23,854
  • 21
  • 74
  • 96

5 Answers5

10

You can rather use hg identify.

hg id should be during the packaging step, when the sources have been committed and you generate the packaged (jar) version of your application.
During that step, you can generate a version.txt file with that kind of information.

$ MY_VERSION=$(hg id)
$ echo $MY_VERSION
53efa13dec6f+ tip

(see for instance "build identification" for Python)

Clare Macrae
  • 3,670
  • 2
  • 31
  • 45
VonC
  • 1,262,500
  • 529
  • 4,410
  • 5,250
7

Since you're in a Java project, this might be relevant to you. I use this Ant target to display the version info (Mercurial changeset id) in the application list in the Tomcat Manager page. I simply put the changeset id inside the display-name xml element in my web.xml.

<target name="build.release">
    <exec executable="/usr/local/bin/hg" outputproperty="scm.version.tag.id">
        <arg value="id"/>
        <arg value="-i"/>
    </exec>
    <filter token="build.version.tag" value="${scm.version.tag.id}" />
    <copy file="${web.home}/WEB-INF/web.xml" todir="${build.home}" filtering="true" />
</target>

Inside the web.xml, there's a token in the display-name xml element, like this:

<display-name>My Webapp @build.version.tag@</display-name>
Paul
  • 204
  • 1
  • 3
2

Here is the view of the Mercurial developers: Keyword Substitution - Why You Don't Need It

Devon_C_Miller
  • 16,248
  • 3
  • 45
  • 71
  • Hmm, I don't get the point. What is meant by keyword expansion? The only thing I can think of is e.g. that you can write 'hg id' instead of 'hg identity', but that concept doesn't seem to apply here. – Rabarberski May 11 '10 at 07:18
  • 3
    Other VCS allow you to add special keywords such as $Id$, $Rev$, $Author$ that are expanded when the file is checked out. This allowed you to write things like const char * version = "$Rev$"; which would become something like const char * version = "$Rev: 1.2$" when the file was checked out. – Devon_C_Miller May 11 '10 at 14:52
2

Mercurial has an extension for keyword expansion. See KeywordExtension for instructions and warnings.

Vadim Kotov
  • 8,084
  • 8
  • 48
  • 62
ronp001
  • 21
  • 3
  • That's pretty nice. I'm assuming that each file gets info from the most recent commit that actually changed the individual file? (and yes, I *DO* need keyword expansion, if I want to track what other people are inadvertently doing (changes entirely outside of revision control aside, alas). Only when your release system is actually being followed correctly does the need for supplemental info like keywords go away. – Roboprog Jun 12 '13 at 14:08
  • This is mapped as "feature of last resort" and should rather not be used – RS1980 Oct 11 '16 at 13:43
2

hg branch | xargs hg log -l1 --template {rev} -b

This will give you the revision number for the current branch that you are working in - very important for builds from different branches.

In an ant file this is what you need...

    <exec dir="${basedir}"
        executable="/usr/local/bin/hg"
        outputproperty="branch">

          <arg value="branch"/>
    </exec>

    <exec dir="${basedir}"
          executable="/usr/local/bin/hg"
          outputproperty="version">

          <arg value="log"/>
          <arg line="-l1 --template {rev} -b${branch}" />
    </exec>
RPM
  • 3,426
  • 2
  • 27
  • 35