Distributed Development with Mercurial

Every clone of a Mercurial repository can act as a consistent, fully functional repository itself. This is a very useful property of a DVCS; one that you can take advantage of to make development a lot easier, especially for teams that are dispersed in multiple places of the globe.

Imagine for a moment that your team is not sharing the same physical space every day. In fact, half of your team works in an office in the west coast of the United States and the other half is located somewhere in Europe.

Mercurial Clones without a Working Copy

Mercurial repository clones can have two parts:

1. An .hg/ subdirectory, where all the repository metadata is stored
2. A “working copy” area, where checked out files may live

The .hg/ subdirectory stores the repository metadata of the specific clone, including the history of all changesets stored in the specific clone, clone-specific hooks and scripts, information about local tags and bookmarks, and so on. This is the only part of a Mercurial repository that is actually mandatory for a functional repository.

Mercurial crew branch grows diff -c option

With changeset 9c6ae2e09e11 the Mercurial “crew” branch includes support for a diff -c option now.

Scripting Mercurial

Dan Fuchs posted a short article about scripting Mercurial to see what files an incoming changeset modifies.

I am always amazed at how easy Mercurial (and other free software tools) make this sort of thing.

Mercurial command demo: hg verify

One of the wonderful commands that Mercurial support is the “verify” command. Running this command in a Mercurial workspace goes through the backing store of the repository and makes sure that the history and contents of the versioned files are not corrupt, missing or otherwise in a “bad” state.

An example of how you can use this Mercurial command is described here.

Mercurial 1.0 Released

Mercurial 1.0 is out!

http://www.selenic.com/pipermail/mercurial/2008-March/018014.html

Mercurial SCM has reached an important milestone. The release of Mercurial 1.0 marks the first 1.X release of Mercurial; one that many people were waiting for to give Mercurial a try.

A nice article about dVCS in the Enterprise

Bryan W Taylor posted a very intriguing writeup a bit earlier, titled:

`The Need for Distributed Version Control in the Enterprise‘

There are a few points of the article that seem a bit controversial. For instance, I am not sure I totally agree with the comments abouts “feature scoped” development.

.scm subdirs

I just stumbled upon an interesting Subversion bug.

Issue 707 on the bug tracker of Subversion is now several years old. It seems to be related to one of my personal pet peeves with Subversion: the use of `.svn’ subdirectories everywhere.

Merging should be *this* easy

Is merging so easy in your SCM system?

$ pwd
/home/keramida/hg/mercurial/gker
$ hg pull crew
pulling from /home/keramida/hg/mercurial/crew
searching for changes
adding changesets
adding manifests
adding file changes
added 54 changesets with 143 changes to 82 files (+1 heads)
(run 'hg heads' to see heads, 'hg merge' to merge)
$ hg up -C keramida
0 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ hg merge
merging mercurial/commands.py
merging mercurial/hgweb/webcommands.py
merging tests/test-hgweb-commands.out
79 files updated, 3 files merged, 3 files removed, 0 files unresolved
(branch merge, don't forget to commit)
$ 

Mirroring the varnish-cache repository with svnsync

Quoting the Wikipedia about Varnish cache:

Varnish is a high performance HTTP accelerator designed for content-heavy dynamic web sites.

The main development repository of Varnish is very easy to browse, using Trac. You can see the latest changes through the web interface at:

http://varnish.projects.linpro.no/browser/

If you want to browse the history of Varnish when you are offline, a web interface doesn’t really cut it. You will have to somehow “mirror” the official repository.