Marker concept idea
adrian at cadifra.com
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).
hg mark closed
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
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
But this might then need yet another option ("--all"?) to really list
Question is how all this would interfere with current branch names.
More information about the Mercurial-devel