XNAT Docs Index

Related Pages

 Click here to expand...

This documentation is for XNAT versions 1.6.0 - 1.6.5. You can find the latest documentation for XNAT 1.7 at https://xnat.org/documentation

Skip to end of metadata
Go to start of metadata

Mercurial Hosting Options


  • The growing standard in the Mercurial world. Offers paid accounts for collaborating on private repositories and additional space. Free space is 1 GB.
  • "Social coding" – Activity feeds, metrics, messaging
  • Simple issue tracker, wiki, and static page hosting .
  • cname support (e.g. hg.xnat.org could go to bitbucket.org/nrg)
  • Forks do not count against disk space (so only one paid account should be necessary).


Google Code

  • Offers free project hosting with Mercurial support and recently added the ability for personal forks of projects (just as bitbucket has)
  • Google Code URL's only contain the project name (e.g. http:_code.google.com-p-demo , unlike bitbucket which is username then project name (e.g.http:_bitbucket.org-nrg-demo ). The bitbucket approach would allow all NRG projects to be hosted under a single namespace.
  • Simple issue tracker, wiki


Self hosted

  • Mercurial can use an HTTP(S) or SSH communication protocol for pushing & pulling. The SSH protocol simply requires that users have shell access to the machine hosting the mainline repository
  • Mecurial includes a builtin command "hg serve" that allows one to browse the repository at http:_localhost:8000 (http:_localhost.8000-).
  • Mercurial also ships with a CGI script for host a single or multiple repositories. It provides similar details as the "hg serve" command, while allowing finer grained access control. The CGI script can be hosted from Apache or similar web server.



  • Similar to self-hosted in terms of setting up CGI script, but on Sourceforge
  • Issue tracker, wiki, dynamic page hosting

Mercurial vs X

Below is a short comparison between Mercurial and other leading version control systems, highlighting some of the major differences. These comparisons are not exhaustive and are based partly on published differences and partly on personal experience.

Mercurial vs Subversion

  • Subversion is a centralized version control system, started in 1999, and was designed to be the logical successor to CVS by fixing common issues with CVS
  • Subversion has more mature support in 3rd party tools, such as TortoiseSVN (http:_tortoisesvn.tigris.org-) and Subclipse (http:_subclipse.tigris.org-). Mercurial equivalents exist and have rapidly been improving
  • Both are well supported on all operating systems
  • Centralized model means that network connectivity is required to interact with a repository
  • Commiters in subversion are first-class citizens, while the general public can only use the repository in a unidirectional manner. In a DVCS, everyone has first-class status, while allow the maintainers of a project to still retain control of what specific changes are allowed in the mainline. The DVCS model can encourage 3rd party participation more easily.

Mercurial vs Git

  • Git is also a distributed version control system. Mercurial and Git were both started at the same time in 2005
  • Git has wide spread adoption among Linux kernel related tools and in the Ruby community. Major Mercurial projects include Mozilla, Open Office, OpenJDK, and Python
  • Mercurial provides a cross-platform, Python-based extension architecture. Git customizations most likely required shell script changes.
  • github is the git version of bitbucket. It provides functionality not found currently at bitbucket
  • Git has poorer Windows support
  • Git encourages local branching within the working directory to experiment or work on feature branches. Mercurial often suggests simply cloning into a separate directory, although there are plugins which partially replicate the git behavior. Mercurial also has an extension Patch Queues , which allows a developer to work on a series of patches without affecting the repository's history until the patch is ready.
  • Git's command line interface has been called more challenging that mercurial's.
  • Git has a staging area in which you add specific files, then commit the staged files. Mercurial commits all current modifications unless told to do otherwise.

Converting CVS to hg

Throw Away History

If willing to sacrifice the conversion of history, you can simply export the CVS module, and create a new hg repo:

Convert Extension

We can convert CVS modules into hg repositories. This operation is intended to be a one-way conversion, such that changes to the hg repository can not be communicated back to the CVS repository. If instead you wish to use hg locally to communicate with a CVS server, look at this Mozilla guide .
We can migrate all the CVS history, including branches and tags, using the Convert Extension.

Add the following to your ~/.hgrc:

Run the following commands to checkout the module, then convert it

The convert command will take a while (>20 minutes) to convert all commits. A new directory will be created, "xdat_release-hg"

We will likely want to map the CVS usernames to new Mercurial usernames using the --authors flag (http:_mercurial.selenic.com-wiki-ConvertExtension) on the hg convert command. To find out the list of distinct users who have committed to CVS, we can run the Churn Extension (http:_mercurial.selenic.com-wiki-ChurnExtension) on the converted repository (the module should be re-exported with the --authors flag set):

  • No labels