Automatically Tag changesets when commit or pushed to kiln

Question

I would like to know if there is a way to automatically tag a changeset as it is committed locally or when pushed to the kiln repository.

I would like every changeset to have a tag with version/build number. I am planning to store my version/build numbers in a database and would like to have a script retrieve this value from the database and add a tag to the changeset. Is it possible to invoke a script automatically to do this as a post-commit event or as a post-push event when pushed to the kiln repository?

I am also open to any other approaches to achieve automatic tagging on every commit/push.

Answer 1

Rather than creating a tag for each changeset, why not try one of the following:

• Use the changeset hash as your identifier?
• Use a string generated from the log as your identifier (see below)?

A descriptive string can be generated from the log using this command:

hg log -r 1.7.2 --template '{latesttag}-{latesttagdistance}-{node}\n'

The result takes the form:

<latest tag>-<# changesets since latest tag>-<changeset hash>

For example, on my local clone of the Mercurial repo, this generates:

1.7.2-2-5e51254ad4d4c80669f462e310b2677f2b3c54a7

Which tells me that there have been two commits since tag 1.7.2 and the current changeset hash is 5e51254a.

In Mercurial, each tag creates a new changeset. So if you tag every commit, you double the number of changesets in the repo. You should use the built-in tools (as described above) rather than try to recreate the wheel.

Answer 2

I would like to know if there is a way to automatically tag a changeset as it is committed locally or when pushed to the kiln repository.

You could always write a post commit hook to do that.

I would like every changeset to have a tag with version/build number.

Tags are useful to identify important moments in your commit history. Providing those moments a meaningful name that relates to the product development like release 1.0, release 1.3 etc .

If you were to make a tag every change set then you would just increase noise level. You will still need to keep information about important tags some where.

Consider tag as meta information about change-sets. Not all of them deserve the same importance. Not all of them require that meta information.

Looking at tags can give you meaningful history only when you use them sparingly.

On hooks

See:

• http://www.selenic.com/mercurial/hgrc.5.html#hooks
• Useful Mercurial Hooks
• https://www.mercurial-scm.org/wiki/Hook

Example: Run after a changegroup has been added via push, pull or unbundle. I have used it to trigger automatic builds.

[hooks]
changegroup.yyyy = command 

Similarly, there is post-commit , post-push hooks

[hooks]
post-<command> =  command