Marker concept idea

Adrian Buehlmann adrian at
Sat Mar 29 15:28:03 CDT 2008

Every changeset has a set of markers (can be empty). A marker is a string.

Markers are an integral part of a changeset and thus do spread to other

If I commit a new cset, the new cset by default gets all the markers
of its parent changeset(s). But I can add or remove markers on the
commit if I want.

The difference to current named branches is, that a cset can have
multiple markers. But markers are sticky like the branch name.

We could then define some reserved markers. "closed" would be a reserved
marker (analogous to the reserved "default" branch name we already have).

The sequence:

  hg mark closed
  hg commit

would close a line of development.

  hg markers  or  hg marks

would list all markers currently set for the working dir.

  hg mark --remove closed

would remove the "closed" marker from the working dir.

A project could define how to use markers. For example a project
X could define markers "trunk", "stable", "experimental", "featureY", etc.
So you could combine markers in a changeset:
"experimental" + "featureY" + "closed".

  hg update stable

Would update to the head with the marker "stable" (or return
an error message if there are multiple heads with that marker).

If the working dir currently has no local modifications and has
markers "experimental" + "featureY" a

  hg merge

would merge with the other head having "experimental" + "featureX"
or return an error message if that is ambiguous.

We could then also filter heads based on markers and color csets
in the viewers (hgweb, hgtk log).

  hg heads -m stable

would list all heads having mark "stable".

  hg heads -m closed

would list all closed heads.

  hg heads -m experimental -m closed

would list all closed experimental heads.

If the working dir currently has

  $ hg markers

it might be worth to think about returning only heads having
mark "stable" when then doing a

  hg heads

But this might then need yet another option ("--all"?) to really list
all heads.

Question is how all this would interfere with current branch names.

More information about the Mercurial-devel mailing list