This is a series of blogposts that consists of three parts:

(1) Part I: History of Bookmarks
(2) Part II: Daily Bookmarking
(3) Part III: Pushable Bookmarks

I stumbled over Mercurial in August 2007. Back then I had already
used Git for 6 months, but wanted
to try out different distributed version control systems (DVCS).
I soon began to like Mercurial’s approach because of its simple and
intuitive interface and its clean codebase. While playing around
with Mercurial for a few weeks I was content with its concepts.
There was one feature missing
that I really like in Git: git-like branches.

Unlike in Mercurial or in any other version control system, branches in
Git are simply lightweight markers pointing to a commit. Every ancestor of
the commit is considered part of the branch. Back then, this sounded odd to me. Later I realized it was a really good tool to create small local branches. You can create a small branch
for a feature, merge it into your mainline, and remove the branch
without anyone knowing you ever had a branch called
‘stupid-little-feature‘. To make a long story short: It’s a good
idea to have a similar concept in Mercurial, but none existed back in 2008.

In June 2008 I started developing Mercurial References providing lightweight branches similar to those available in Git. Although the initial work was appreciated by the community, it was rejected
in favor of a concept more natural to Mercurial. Matt Mackall, the author of
Mercurial proposed Mercurial Bookmarks.

Bookmarks

The concept of bookmarks is easy:
You can bookmark a commit with a unique name. So it’s similar to
a tag, with one exception, a bookmark advanced when you commit.
(Like real bookmarks when you go to the next page).

I wrote an initial version of Mercurial Bookmarks in August, that
was finally accepted in October. This improved git like workflows
in Mercurial but still the implementation was far away from what I
wanted. By adding the notion of a so called “current bookmark”, it
got better. Still bookmarks had one major drawback in comparison
to git style branches. They were local only. There was no way to
push or pull bookmarks.

Pushable bookmarks

This was the status for the past two years. I tried to make bookmarks
pushable during this time. A proposal by me how extensions in general
can exchange arbitrary information over the wire was rejected in
early 2009 because it was too unrestrictive for the protocol. A new
concept, so called ‘pushkey concept’ was developed in 2009. This
was discussed and accepted during the Mercurial Sprint in Paris,
January 2010.

Matt Mackall, who now gets sponsored to work on Mercurial,
worked on the initial implementationof pushkey and
pushable bookmarks. And finally after two years of ongoing complains
by people about local-only bookmarks, Mercurial 1.6 will have
pushable bookmarks and introduces a great new concept to exchange
metadata information between repositories.

The next blogpost will show you how to use bookmarks.

• Dutch PHP Conference 2010
• Interntational PHP Conference

The talk will give a very brief overview how Git works, and will then give a more detailed insight in how Git handles commits, files, etc so that people get a very good understanding about the concepts that are needed to fully understand tools like git rebase, git reflog and git svn. The aim is to provide them will all necessary information and a few examples to get lost commits back, rebase their branches and design more complex git workflows in the future without needing to search the web or ask a guru.

A second talk will be more focused on beginners and developers coming from subversion. This talk will be part of a series of talks the german telekom is organizing. I’ll also give an extended version of this as an in-house workshop at a Munich based company.

So for me it seems that after five years, DVCS is mature enough to get into companies and that we can expect a bright variety of companies to adopt new tools and workflows. Let’s see what’s coming…

For sure I still offer Git and Mercurial trainings, so feel free to contact me (dsp ~at~ php ~dot~ net)

probably shameless self promotion

The following article will outline the current limitations of bi-directional dvcs to subversion bridges and shows a simple approach to implement a solution for a certain instance of the problem.

The bi-directional bridge
The idea of finding a way to interchange commits back and forth between a DVCS and subversion was born early in the development of tools like Git and Mercurial. The basic idea is easy to grasp. To initialize a repository the DVCS requests all changes between revision 0 and the current HEAD from the subversion server and imports every change as a regular changeset into the local repository of the DVCS. In addition it maintains a mapping between the local, DVCS specific, changeset IDs and the revision numbers in the subversion repository. If a developer wants to push his newly created changesets from it’s local repository back to subversion, the bridge determines the latest pushed changeset and then iterates over the unpushed changes, committing them bit by bit to the subversion server.

Depending on the DVCS you use it will then delete the local changeset and reimport the comitted changesets from the subversion server to ensure that the changeset contains the right date and comitter information as well as the right mapping to the subversion revisionnumber.

Example
To clarify what we just discussed. Assume that we are using git-svn. We are importing a subversion repository with just one commit using the command (I won’t get into detail how to use the command):

$ git svn clone svn://example.com/repo

This command results in a repository which in our example contains the following commit.

commit 7a730e9187becbe1979059cd9752fdea38e3cd9e
Author: david >david @cffdd316-8dd2-4046-8f43-d0df91842a18<
Date: Thu Jul 12 19:39:51 2007 +0000

Crescas in mille millia

Let’s asusme that we create a new commit on top:

commit 129e0e4239ac4d375f2a2132dee042a27f2fd70c
Author: David S. P. >dsp at php.ent<
Date: Fri Jul 13 12:23:42 2007 +0000

First Draft

If we push it using git svn dcommit, it’ll be committed into subversion and
reimported as:

commit 8200f32f61432004b488d063564ac9dae7bf6827
Author: david >david @cffdd316-8dd2-4046-8f43-d0df91842a18<
Date: Fri Jul 13 12:23:42 2007 +0000

First Draft


Limitations
Tools like git-svn or hgsubversion are working perfectly fine as long as you use them just as a subversion client. There is a serious limitation in what you can push and pull from and to a subversion server. Particularly, problems arise if you are using the usual DVCS push and pull method to exchange changesets. Why so? If you push and pull from other DVCS repositories you might have to create a merge. Modern DVCS like Git, Mercurial or Bazaar represent history as a directed acyclic graph (DAG). Therefore a merge is a commit which has two (or more) parents, which means that a merge is the resulting connection of two parallel strands of history. Now this is a very comfortable and powerful way to describe history in parallel development. Sadly subversion doesn’t handles history and hence merges the same way (at least not priort svn 1.5). As a result, it is not possible to represent the Merge from a DVCS in subversion.

Different bi-directional bridges have different approaches to this problems. Git-svn will commit the Merge but not the commits which are part of the seconds strand of history, while hgsubversion will abort if it has to push a merge. The fact that hgsubversion aborts in case of a merge is our actual problem. We want to use Mercurial and therefore need to find a way to push a merge to subversion.

A usecase
You shouldn’t care much about these limitations. Usually, people are using the bi-directional bridge locally to be able to do offline commits or bisect a bug. In that case, everything will work fine.

But why do I write a complete blog post about a hg to svn bridge if the problem is already solved? The answer is pretty simple.

1. Imagine you are working in a small team. Everybody in the team knows Mercurial and everybody likes to use it. Moreover you are working offline from time to time, and the members of the team sometimes have to exchange unfinished features with other members. In that case you will probably use Mercurial as your version control system. The problem here is the customer. He dictates the VCS and it has to be Subversion. Now subversion at all is not that bad, but in your particular case, it’s a huge drawback. You have to find a way to mirror your Mercurial repository to the Subversion server.
2. A second use case is that you are working on an OpenSource project which uses github or bitbucket to host it’s repositories. As you are using the OpenSource framework also at work. You have to use Subversion and you want to use svn:externals to integrate your fancy framework into the existing Subversion repository

As you see, there is a use case for DVSC to Subversion mirror. As no such tool exists at the moment, we’ll try to implement a (frankly, very stupid) mirroring mechanism.

The idea and it’s limitations
We see that we need to mirror a existing Mercurial repository to Subversion.
We also know that we cannot use the existing tools. Our requirements are the following.

1. Mirror a Mercurial repository into a Subversion repository
2. Track latest synchronized changeset
3. Handle merges

Note that we would have been able to do this with git-svn, while it’s not possible to do it with hgsubversion.

A few assumptions about the environment where we want to use our mirroring mechanism helps us to simplify the requirements.

1. We do not need to preserve the author information
2. We have a central Mercurial repository called Gate
3. No commit will be done into the repository other than our mirroring (and believe me, things get ulgy for you if you try to…)
4. We do not need to preserve all commits

So what is the end result? We just need to find a way to push all changesets and just ignore all merged changes, but commit the merge itself. This should be sufficient.

In our particular environment everyone has his own repository, but one person integrates all changes into one repository called the Gate. Commits reaching the gate are committed to Subversion.

The implementation
To make a long story short (it’s getting late). We are using Mercurials log command and it’s option to obtain a linear history that can be pushed. To get the the history, we use

hg log --follow-first

This will return the history omitting all merged changesets but including the merges itself. We silently drop the changesets that were merged, but retain the result. As we need to get just the SHA-1, we use the –template option to get the node. We then iterate over the history, updating our working copy to each changeset in the history, adding all newly created files and deleting all removed files and then comitting the current state of the working directory. So here is our final script

#!/bin/sh

lc=0
cont=0
if test -f "LAST_COMMIT"
then
	lc=`cat LAST_COMMIT`
	cont=1
fi

for hash in `hg log --follow-first --template "{node}\n" -r $lc:tip`
	do
		if test $cont -eq 1
		then
			cont=0
			continue
		fi

		echo "update to $hash"
		if ! hg log --template "{desc}\n"  -r $hash > COMMIT_MSG
		then
			echo "Canno get log" >&2
			exit 127;
		fi
		cat COMMIT_MSG

		hg up -C -r $hash
		for file in `hg log --template "{file_adds}\n" -r $hash`
			do
				echo "add $file"
				svn add --parents $file
			done
		for file in `hg log --template "{file_dels}\n" -r $hash`
			do
				echo "del $file"
				svn rm $file
			done
		svn commit -F COMMIT_MSG
		echo $hash > LAST_COMMIT
	done

It looks scary, and yes it is scary. But for the moment it works. Our simple hg to subversion bridge is finished.

The idea
Our general idea to import the git repository into subversion is easy. We import the current subversion repository and then push the changes from the our existing git repository on top of that imported subversion repository. We than can use git-svn to commit the changes back to the subversion repository. Even thought this sound simple, it is not. Part of the problem is the fact that subversion usually deals with linear history, while git does not. (1) We have to keep in mind that we need to linearize the git repository while pushing changes to the imported subversion repository. (2) we have to make sure that every commit from the original git repository is pushed to the imported repository as a descendant of the last commit from the subversion repository to avoid conflicts. (3) the imported subversion repository and the existing git repository are not related to each other. As they don’t have a common ancestor in terms of a common commit (with according sha1s), we are not able to merge both repositories easily. We will use a technique called grafts to create a fake common ancestor, which will make it possible to merge both repositories.

1. Importing the svn repository into git
Our first step is importing the svn repository into git. We are using git-svn for that task.

# git svn clone svn://path/to/repo

We will get a git repository with a branch called master. As we later want to push our git repository on top of the imported svn repository, we need to remember the current id of the repositories head (we’ll discuss later why we need that). The command git rev-parse will give us the necessary information.

# git rev-parse HEAD
00f97c72f22b82c6c77ae429986060832c6b6f55


2. Importing the git repository into our imported svn repository
Let’s start with the voodoo part. We want to merge our imported svn repository and our existing git repository. But git doesn’t know how to merge them because both repositories don’t share a common ancestor. We can solve this problems by creating a fake common ancestor, but to do so we need all commits of both repositories in one repository. Therefore we fetch the content of the git repository into our imported subversion repository. To fetch the existing git repository into our imported svn repository we use the following git-fetch command:

# git fetch /path/to/git/repository master:tomerge

The resulting repository will look that way:

Both branches the one from the existing git repository and the svn imported one exist in parallel in the same repository.

3. Tell git what to merge…
We have two parallel branches. We now create the fake ancestor. This is called a graft. Unfortunately git’s grafts are not very well documented. Let’s visualize which commits we want to graft on each other:

So we will graft the existing git branch on top of the svn branch. The fake ancestor will be the HEAD of the svn branch and the first commit of the existing git branch. To get the first commit of the existing git branch we use the following command:

# git rev-list --reverse tomerge | head -n 1
bab39ed371145b83340750101e7ec85167845857

Therefore the commit bab3… and 00f97… will be our grafts. We create the file .git/info/grafts with the content

bab39ed371145b83340750101e7ec85167845857 00f97c72f22b82c6c77ae429986060832c6b6f55

We use gitk to check if our history seems to be linear. If everything is correct, just switch to the master branch and rebase your tomerge branch. We use rebase here to get a linear history. A merge might make it impossible for git-svn to push to the remote svn repository as imported commits cannot have commits which are not synchronized to the svn yet.

# git checkout master
# git rebase tomerge
# git svn dcommit


Done.

Never rebase branches or trees that you pulled. Only rebase local branches.

Disclaimer: I never read this article myself

Let’s visualize this:
Let’s assume that we have a linear history. In our graphic we see the last tree commits in that history.

Okay. Now let’s say there is a bug in the software. For sure, we don’t do any mistakes, certainly a co-worker did that mistakes. Unfortunatly we are the only one smart enough to know how to fix that. So we checked out our stable branch and committed our fixes to that branch. Our fix needs two commits. Let’s see how this reflects in our visualization:

The commit 433fa and 322ac are our commits that fix a certain problem. Now we need to integrate these commits into our current experimental development version. But as we keep our stable branch also public for other employees to push, we push this branch first before we merge it into our experimental branch. Let’s repeat this. We pushed this branch to a place where other people can pull it. Again, we pushed it. Remember that!

So we have to get that fix into our experimental branch. So we use the merge command. In Git or Mercurial this would look like:

$ git checkout stable
..fix fix fix fix..
$ git commit
…
$ git checkout experimental
$ git merge stable

$ hg branch stable
..fix fix fix..
$ hg commit
….
$ hg branch default
$ hg merge stable

So we create our merge commit. This is a new commit that reflects our merge.

Please note: The actual ID’s of our commits that include the fixes did not change.

So let’s get back to our ‘stable’ branch which were we commitet our fixes to:

So we want to rebase this branch on top of our experimental branch. What does rebase do: It cuts off these commits. The commits don’t have any information about their parents anymore. The system then applies them on top of the new branch, which is in our example the experimental branch. If everything went fine, we get a nice linear history. Our old branch doesn’t exist anymore but instead we have all the important commits applied on top of our experimental branch. As people tend to dislike merge conflicts rebase is the perfect tool to get rid off these commits. Let’s visualize this:

We literally cut of these commits and then apply it on top of the new branch:

But what are the implications? Why does merge even exists if we found such a nice way to handle our history? Ohhhhh. Let’s way…take a look at the graphics. Our commit ID changed! Why? We have a new parent, we even might have completly new changesets (depending on the changes on the new branch). Our revision control system really thinks of our commits as patches and applies them on top of the new branch. Therefore our revision control system thinks that our commits are new commits. Recapitulate this. IT THINKS THAT THESE ARE NEW COMMITS. Why? Because they have new IDs. It’s that simple. The common ancestor of a commit is determined by traversing the list of commit IDs and their parent IDs. As the parents changed, the ID’s have changed too.

So if you have pulled your branch to some place and you now pull it back, you will get duplicated commits. Okay you might be smart enough to get around this, but other people that might have pulled from your stable branch might not know what happened, so they have all these duplicated commits, or if you pull from them, you get these commits back. Actually you don’t even see them until you try to merge them, because their ID is completly different. As a result you get a millions of merge conflicts and have to find a way to get rid of the duplicated commits. But why, and how can you prevent his? And why do these systems include a command that can cause so much pain?

So let’s see.

Rebase done right
We saw that rebasing results in duplicated commits if we try to rebase branches that we already pushed to some repository, that either we or others pulled from. Let’s see why there is still a point to use rebase at all. Imagine you want to fix a bug locally. This means, you do not push this branch somewhere. Did you get that point? If you then rebase your local fancy branch on top of your branch that you usally push everything is fine. Let’s take a look at a good example:

$ git branch pdo-mysql-config-fix
$ git checkout pdo-mysql-config-fix
..hack.hack..
$ git commit
$ git checkout master
$ git rebase pdo-mysql-config-fix
$ git push master

Got it? We never cut off the pipe. It’s just like we prepared that pipe on another stream and then cut it off and weld it on top of our main pipe. As all the people just look at our main pipe it looks like we just added a new piece on top of the old pipe. We never ever pushed the branch that we use to rebase. If I would have pushed it, I would get duplicated commits:

So let’s rehearse the Golden Rule Of Rebasing:

Never ever rebase a branch that you pushed, or that you pulled from another person

It’s that simple. If you would rebase a branch from another person and he would pull back the integrated changes from you, he would get duplicated commits. So never ever do this.

The bad news: Too many developer get rebasing wrong and think that it’s a fancy way to get a linear history
The good news: Believe me, even well known top-level maintainer didn’t get what rebasing is about.

This article is about rebasing. Rebasing is a way to push commits from a branch on top of another branch. Decentralized revision control systems such as Git or Mercurial implement this feature.

UPDATE
A few people at reddit.com pointed out that it might not be a good idea to rebase a dev branch on top of master. If you are doing drastic changes in your dev branch, that’s right. People might use rebase then to keep their dev branch up to date on top of the master branch and therefore rebase against master. At the end they can merge the dev branch into the master branch (in fact the result is the same here, as it’s both way a fast forward).

WARNING: This is the most subjective, most pointless approach to this topic ever. I didn’t read it myself a second time, I just published it.

I will start the same way as last time:

git
Git is a decentralized version control system written by Linus Torvalds to replace bitkeeper as the version control system of choice for the kernel because of licensing issues (okay I know this is the short story and it was much more complex and you can write a thousand lines about that, but it’s enough for most people). Git is designed to be fast. Everthing is optimized in that way. It contains a huge C written core with a lot of bash and perl scripts around it. A few years ago the C written part formed the so called plumbing. Nowadays the git community tries to replace high-level commands written in bash and perl that call the plumbing commands with c-written code to get a more consistent code base.
Let’s make a long story short:
Git is powerful. Awesome powerful. This is true since git’s beginning, but back then it lacks a good interface and the git community did a great job in improving the horrible interface git had once. Git is still awesomely fast. Commits, bisecting, everything works like a charm particularly on big projects like the kernel. They can rewrite history, they are doing a great job in helping intergrators to apply patches, reviewing them, and pushing to multiple sources. Everything about git is really unique, their focus on a powerful command set, their branching support and their targeted audience. I want to talk a little bit about that fancy branching support. Frankly, every version control system, even the 3rd generation decentralized ones have a pretty conservative way of doing branching by giving every changeset a name that the changeset belongs to (at least this is true for mercurial, and called named branches there). Git just gives a sh** about that and takes a version control branch the same way as a tree branch. It’s just an unnamed branch of the DAC. This gives you the awesome possibility to great huge set of local branches, to merge, rebase them without any bigger problem or even just discard them (actually that is one of the biggest problems in mercurials bookmarks implementation). Another just great feature in git is the staging area. You can stage hunks, as a virtual repository that is used to actually commit the ‘selected’ changesets. That’s awesome and I’m really missing that in most of the version control systems that I use. The idea of a staging area is just a huge win for git. It’s so incredible powerful. Okay to put it in a nutshell: git is just awesome, but….

There is Mercurial.
Okay some kind of a warning in advance: I contributed two well known extensions to Mercurial, I hang around in their chatroom and I think that I’m a well known part of the community. Nevertheless if you talk about Mercurial and compare it with git you have to take care. Mercurial is by far not as powerful as git, and…that is just the best think about Mercurial. Matt really keeps it simple and clear for everybody. it’s so incredible easy to understand in the first place. There are no weird commands with a thousand of flags. Okay I try to be fair. Mercurial is much less powerful than git in the first place. Because it tries to keep everything simple. There is no rebase, no cheap branching, no staging area. But there are extensions. You can learn Mercurial and know all it’s commands within 24h. They are really easy to learn, and not powerful, but they can be extended, by a large range of extensions. You can have cheap branching (bookmarks), you can have kind of a staging area (record extension), you can have patch management on top (mq) and much more. With all those extensions, Mercurial is as hard to learn as learning all git commands (which frankly is not necessary at all), but it’s more of a evolutionary approach. I know a thousand people who say that learning git is as easy. Okay, no problem. I don’t think so but it doesn’t matter, but frankly, git is missing 2 big points. Windows and an application integration: If you live in your nice Linux/BSD/foo world you are right. Git is awesome, but come on, I don’t have a freaky Windows machine, but I know that 80% of all people and more than 50% of all programmers use Windows. No they are not these bad, not geeky enough people. They are the real programmers. Those who are not freaks and take programming as a job. They don’t care (and thats good) about their environment, they just want to get things done and want to earn money. That good. And even that is not quite true for most of them, they do their stuff just faster on Windows than on Linux, therefore it’s better for them to use Windows. Okay, you might argue, but there is mysysgit and it’s even part of official git. Oh nice arguement, but frankly, junio doesn’t provide Windows binary, there is no official site to get them from, and ….. git daemon still doesn’t work perfectly nor does git-svn. It just sucks. Big -1 from me for that one.
The second pint is the worse git internal design. It’s soooo unix style. It’s cool for people that love Unix (like I do), who pipe around at least 3 commands, and know that I it starts to get funny if you pipe around 5 commands. But most of the developer want to use a nice integrated version control system. They don’t like to use fancy command line stuff with a thousand of flags, they want to do click&click (the german expression would be ‘klicky-bunti’). They want to have it integrated in their Eclipse, their NetBeans, Visual Studio, their Windows explorer and so on, and frankly, git does a poor job in that area. I know there is an eclipse plugin (but the mercurial one is stilll a thousand times better), and all this fancy stuff, but what do they do, damn, they have to parse the shell output. This means either git will never ever change their shell output (which would be sad, e.g. I hate the # in git status), or they will break older stuff. Mercurail on the other side is really easy to interface with. Okay you need python but that’s all. Everything else is just smooth. It’s easy to handle, it’s easy to integrate, it just works fine. Git really does a bad job on that. And the git community knows it. That’s why they start their libgit, and libgit2 project, because they know something like a git library is needed.

Okay it’s late and I want to finish that without reading it a second time, no frankly, this time I want to be completely unfair, without any objective argument: So here comes my final words, make them:

If you like to play with software, if you really like to have the power, go for git, if you use Linux, even better, go for it, there is nothing equal to the power and the fun you can have with Git. You can be a thousand times more productive. But if you, or people in your team are not tech-geeks. If you use Guis and want to use Windows, believe me, you better use Mercurial. I really love both systems (as long as you don’t use bzr even SVN is fine), but in this use case Mercurial is just better. Think about it.

shame on myself: song for this post: This is the life by Amy MacDonald

$ hg bookmark -r 132 my-bookmark
$ hg update my-bookmark

Further thoughts
Just referring to a commit by a given name is nice, but it is not quite why we finally introduced bookmarks. A lot of people using both git and Mercurial like Mercurial for it’s simplicity and it’s clear interface. Nevertheless they are missing certain features from git and one of the most often requested are git-styled branches. Let me just give you a short overview of the differences between the branch implementation of both systems:

Mercurial branches
Mercurial branches have a lot in common with branches in Subversion or CVS. If you commit to a branch, the name of the branch is stored in the changeset and therefore an immutable part of the history. This means, unlike bookmarks, branches can not be deleted if you created them, and that you will always know to which branch a certain commit belongs.

git branches
In git’s notion of branches a branch is just a fork in the directed acyclic graph (DAG) of the history. Therefore the branch name is not recorded in the changeset. Branches are just pointers to a certain head of a DAG branch that move forward with every commit to that branch. This gives you the opportunity to create branches just for testing purposes or with stupid names that might be merged or rebased later. If you delete the branch name, the branch in the DAG resides, but the name is gone.

As bookmarks are also just pointers to commits in the history, it is quite obvious that it is easy to implement a mechanism equal to the branch mechanism of git. Therefore bookmarks are not just pointers, but they move forward to the next commit if you create a child commit on a commit that is referred by a bookmark.

Problems
As the branch notion in mercurial is different from git, it is clear the the internal design of mercurial makes some assumptions that rely on this behavior. This leads to some design decisions that might confuse people that come from git. If you switch to a branch in git and commit to it, only the branch that you are on is moved forward even though the parent commit has two branch names. Mercurial bookmarks are always forwarded if the parent commit is referred by a bookmark. Therefore you might forward bookmarks on commit without evening knowing. We don’t have a notion of a current bookmark. Furthermore bookmarks are local. There is no way to push or pull bookmarks. This is a limitation by the wire protocol of mercurial. There are patches floating around that implement a way to bring push/pull mechanism for various data including bookmarks, but as the wire protocol is a critical part of mercurial, the developer usually don’t like to enhance or change the protocol. You can use bookmarks remotely and do a lookup on them, but it requires a certain amount of deep knowledge.

Implementation
As already mentioned, we have a working bookmark implementation now. I worked on these bookmark stuff for several months. With the help of the mercurial community we finally made our way to the main tree (mpm’s and the crew tree) and therefore my extension will be part of the upcoming Mercurial 1.1 release. I’m currently maintaining the bookmarks on bitbucket.org and a crew member is usually merging changes from me into the crew tree from time to time.

Example
Let’s give you a short example how bookmarks work. First of all we have to checkout recent versions of Mercurial. You can get an hourly snapshot here. Then we have to setup the extension by adding the following lines to our ~/.hgrc:

[extensions]
hgext.bookmarks =

Now let’s go into a Mercurial repository. You can run hg help bookmarks to show the available flags.
Let’s start with a basic listing of available bookmarks:

$ hg bookmarks
no bookmarks set

Create a bookmark on the current tip of the repository:

$ hg bookmark my-tip
$ hg bookmarks
+ my-tip 7348:1a5c9ca2bfd5

Let’s create a bookmark on an other revision in the history:

$ hg bookmark -r 7300 hgweb-fix
$ hg bookmarks
+ my-tip 7348:1a5c9ca2bfd5
hgweb-fix 7300:591767e6ea7a

We can than update to the revision:

$ hg update hgweb-fix
82 files updated, 0 files merged, 31 files removed, 0 files unresolved
$ hg bookmarks
my-tip 7348:1a5c9ca2bfd5
+ hgweb-fix 7300:591767e6ea7a

We also can now commit to this bookmark and create a new head:

…hack..hack..
$ hg commit -m’Another hgweb bugfix’
$ hg bookmarks
my-tip 7348:1a5c9ca2bfd5
+ hgweb-fix 7349:ca3fbad32554

Let’s go back to our tip and merge our change into it:

$ hg update my-tip
$ hg merge hgweb-fix
$ hg commit -m’Merge bookmark hgweb-fix’

Now we can just delete our bookmarks

$ hg bookmark -d hgweb-fix
$ hg bookmarks
+ my-tip 7350:3acda44343da

You can use bookmarks in every rev lookup. This means you can also do hg log my-tip or hg qimport -r my-tip. It is even possible to look them up using hg id -r . I hope you enjoy it. If you encounter any bugs don’t hesitate to file an issue at the mercurial bugtracker.

Thanks to
A lot of people were involved in the development of the bookmarks extension either by giving ideas or by actually patching it. Thanks to ronny, mpm, tonfa, piranha, parren, joel, dimitriy and #mercurial.

Links

• Mercurial
• Crew repository
• Announcement of the bookmark extension
• My bookmark repository

Mercurial is a fast decentralized version control system used by projects like Mozilla and OpenJDK for their software development. It is written in python and currently maintained by Matt Mackall.

But the best thing is that it is still very familiar with the main developer jesper hanging around in the #mercurial channel on freenode. He actually changed a few things on my repository as I’m too lazy to setup them up in the first time. Thanks for that.

Hopefully it will grow like github. Well at least I’m thinking about getting a $5/month account on it.

hgbookmarks is a implementation if git-styled branches for mercurial. It allows to create local bookmarks on certain commits that move forward with any commit. You can merge and update those bookmarks. You can think of bookmarks as named commit sha1s