Bookmark concept

Matt Mackall mpm at selenic.com
Sat Mar 29 13:21:06 CDT 2008


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.

-- 
Mathematics is the supreme nostalgia of our time.



More information about the Mercurial-devel mailing list