From the posting "Bookmark concept" by Matt Mackall, Sat Mar 29 13:21:06 CDT 2008 (http://selenic.com/pipermail/mercurial-devel/2008-March/005602.html)
Currently we have three ways of labeling revisions:
- tags: point to single revisions, modifiable, stored in history, shared
- local tags (tag -l): point to single revisions, modifiable, not stored or shared
- branches: stored in changesets themselves, not modifiable, stored in history and shared
Our branch concept is fairly similar to the one in CVS and similar systems, but very different from the one in git. Git's notion of a branch is instead much more like our local tag: a modifiable pointer to a branch head that isn't stored in history. This has the advantage that it's very easy to make private branches, but the disadvantage that there's no recorded history of branching for public branches.
One obvious approach to git-like functionality here is to add a "local branch" analogous to local tags. Unfortunately, that's problematic as currently a changeset can only be on a single branch
So I've been tinkering with a new concept which I call a 'bookmark'. A bookmark would be like a local tag that gets updated every commit. So to work on a feature, you'd run 'hg bookmark myfeature', do a bunch of commits, and the myfeature bookmark would follow along. Switching between features (or branches, etc.) would be an 'hg update <id>'.
This works fine until we want to share with other people. Pushing branches to a server would simply be 'hg push <bookmark>'. But because our bookmarks live outside the history and push/pull -only- transmit history, the server won't have any knowledge of our bookmark. This is both a good and a bad thing: in general, we don't want to spread our bookmarks all over the world. But we probably do want a way to be able to make our bookmarks visible on a server so that our branch can be pulled by name.