How to move a tag?

Question

I want to start using tags in Mercurial. I plan to have a "stable" tag that always points to the last good revision.

As I understand it, I can tag the current changeset via hg tag stable.

What's the proper way to move the tag? When I try to run hg tag stable again it tells me:

abort: tag 'stable' already exists (use -f to force)

And if I force it, I get this bug which has no resolution or comments. i.e., it duplicates the old tag. I don't even know why the tag needs to be in there more than once in the first place; I just want to update it to point to a single changeset.

Answer 1

I haven't see such tag move operation, but it is essentially copying something and removing the original so:

hg tag --remove stable
hg tag -r newrevisionhash  stable

Or append some sort of suffix to your tags, like a version number. It would also allow you to keep track of your releases.

Opinion 1: I always thought Mercurial was more about preserving history and whereas under git you could change something, in Mercurial you would have to overwrite it instead.

Opinion 2: another alternative to marking stable releases would be to keep them in one branch. Where I work default holds only stable code. All other work is done in isolated branches.

A dirty one-liner to update a tag:

current=`hg log -l1 --template '{node}'`; hg tag --remove stable; hg tag -r $current stable

It seems that this atrocity can even be added as a Mercurial alias in .hgrc:

[alias]
movetag=!(current=`hg log -l1 --template '{node}'`; $HG tag --remove stable; $HG tag -r $current stable)

I capture the value of current tip, as tag removal/adding are commits in themselves, so they 'move' tip along (can't see anything wrong about tagging tip -- it's for precision sake only). There's certainly potential to make it prettier, but those worked for me.

Answer 2

As @guessimtoolate and @Martin Geisler already pointed out, you can use a named branch to accommodate all good revisions (which is also the way we use hg at the company). Another way is to use bookmarks, which act as movable labels attached to one revision.

Answer 3

Instead of having a tag that moves, you should use named branches instead. They function almost like a moving tag.

You write in a comment above that

All work is done on other branches, but we merge them into 'default' when they're ready and then perform integration testing. There's a period where 'default' may be fubar if there's a bad merge. Thus I want to keep a stable tag on default and only move it after the integration testing is complete/verified.

To solve this you need an extra named branch — call it stable. Then merge tested and approved changesets on default into stable in your own pace. It doesn't matter if default has changesets that are still being tested, when changeset X passes the tests, you do

$ hg update stable
$ hg merge X

to promote X as a stable changeset. Descendants of X (on default) remain unchanged, i.e., they are not yet marked stable.