How to move a tag?

I want to start using tags in Mercurial. I plan on having a โ€œstableโ€ tag that always indicates the last good revision.

As I understand it, I can mark the current set of changes with hg tag stable .

What is the correct way to move a 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 error , which does not have permission or comments. those. duplicates the old tag. I donโ€™t even know why the tag should be there more than once in the first place; I just want to update it to point to one set of changes.

+7
mercurial vcs-tags
source share
3 answers

I have not seen such a tag move operation, but it essentially copies something and deletes the original like this:

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

Or add some suffix to your tags, such as version number. It will also allow you to keep track of your releases.

Opinion 1: I always thought that Mercurial was more concerned with preserving the history, and although you can change something in git, in Mercurial you will have to rewrite it instead.

Opinion 2: another alternative to labeling stable issues would be to store them on the same branch. where I work default contains only stable code. All other work is performed in isolated branches.

Dirty single line tag update:

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

It seems like 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 fix the value of the current tooltip, since deleting / adding tags is itself a commit, so they "move" the tooltip forward (I see nothing wrong with tip tagging - just for the sake of accuracy). There, of course, there is the potential to make it more beautiful, but they worked for me.

+12
source share

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

You write in the comments above that

All work is performed in other branches, but we combine them in the "default" when they are ready, and then perform integration testing. There is a period when "default" can be fubar if there is a bad merge. Thus, I want to keep the stable tag by default and only move it after completion / verification of integration.

To solve this problem, you will need an additional named branch - name it stable . Then combine the verified and approved changes to default into stable at your own pace. It doesn't matter if there is a default change set that is still being tested when change set X passes the tests, you do

 $ hg update stable $ hg merge X 

to promote X as a stable set of changes. The descendants of X (on default ) remain unchanged, i.e. They are not yet marked stable.

+7
source share

As @guessimtoolate and @Martin Geisler already pointed out, you can use the named branch to host all the good versions (which is also related to how we use hg in the company). Another way is to use bookmarks , which act as movable tags attached to one revision.

+3
source share

All Articles