Bookmark concept
Matt Mackall
mpm at selenic.com
Sat Mar 29 18:21:06 UTC 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