Google Summer of Code 2009

For the last few years, Google has offered a fantastic opportunity for students to help out Open Source software projects in the summer while getting paid for it. It's called Google Summer of Code™, and it provides free software projects a great way of attracting development effort while providing software developers who are still in university with some interesting and useful experiences. Find out more about the Summer of Code (SoC) from [ their site].

Mercurial is a Distributed Version Control System (DVCS), and we are one of the mentoring organizations for 2008's Summer of Code (see also In recent years (notably since the Linux kernel project started looking for a new VCS), DVCSs have rapidly started to gain traction. For Open Source projects, especially, the use of a distributed system can be a great enabler, in that it's much easier to keep track of your own changes and publish them back to the community in a structured way. With centralized systems, you have a central repository that only a happy few have (write) access to, and people spend a lot of time mailing around diffs. With distributed systems, everyone has their own branch, and it's very easy to publish it on the web, compare the changes to those on some other branch or merge two branches back together.

We believe distributed version control is the future, and it looks like many other technologists believe the same. There's some healthy competition between Open Source VCS systems. In one corner, there's the old CVS and the better, but still centralized and complex Subversion, and in the other corner, there are three main contenders in the distributed VCS space: git, Bazaar-NG and Mercurial. The competition for users is fierce and stimulates fast-paced development in all three systems. It's therefore important (and good for the competition) that projects like ours gain more developers, to keep up with the race for robustness, performance and features. We view the Summer of Code as a great opportunity to help us in this competition.

Written largely in Python (with the exceptions of a few performance-critical core modules), it is easy to develop for and allows for good code organization and clean abstractions. Moreover, it has been optimized from the start for good performance, using an append-only datastore, minimizing random disk access and smart uses of compression. Finally, it has extensive features for sharing changesets, over HTTP, SSH and in files over email and has an innovative extension (Mercurial Queues) to help building and organizing changesets into a thoroughly useful source history.


1. Project Ideas

Here are a bunch of project ideas you might like to apply for. Of course, if you have a different idea of something in Mercurial that badly needs fixing or some feature you think would make a difference, go ahead and apply with it! Some more project ideas can be found via NewFeatureDiscussions, CategoryNewFeatures and NewIdeas.

1.1. Instantaneous status on Windows, OS X

The InotifyExtension makes a huge difference to performance on moderate to large [:Repository:repositories] on Linux. Since Windows and Mac OS X provide file status notification APIs, it should be possible to port the inotify extension to one or other (or both) of these platforms, providing the same kinds of speed improvements as on Linux.

1.2. Partial cloning

Currently, it's only possible to clone one whole repository at a time. PartialClone and TrimmingHistory could help make cloning more efficient by limiting the cloning process in either of two dimensions: time or space. For time, we could maybe clone the last few [:ChangeSet:changesets] and lazily fetch the rest as needed. For space, it would be nice if it was possible to clone just a subtree of any repositories. For these features, any number of thorny issues can arise because of current assumptions in Mercurial code.

1.3. Lightweight copies/renames

Copies and renames currently are not light-weight. Mercurial copies the copied/renamed source file to the new initial revision of the target file in its internal history store. For renames, this is especially counter-intuitive, as renaming a large file grows the store by the file's size. It would be better if Mercurial had some way of referring to the existing revision from the new file, while preserving its bounded I/O guarantees for retrieving revisions.

1.4. Interactive patch selection for commit/Mercurial Queues/record/import

Being able to select parts of the existing changes, with hunk or greater granularity, in an interactive way can improve a lot the use of commands and extensions that take changes, as commit, mercurial queues, record or import. Record currently allows patch hunk selection, but sometimes a better granularity is desired, as when a set of adjacent function definitions should go in different commits. This feature could be added as an --interactive mode for some commands.

1.5. Subrepositories

The ForestExtension implements a solution for repositories that want to include a number of subrepositories (similar to svn:externals). For large projects and because DVCS systems in general advocate smaller repositories, it can be helpful to implement a coherent set of repositories. A [NestedRepositories subrepositories implementation] is in the works but it needs further polish, and integration into the mercurial core, as well as extended functionality, as the capability to use other VCS sources.

1.6. TortoiseHg

TortoiseHg is a GUI front-end, similar to TortoiseCVS and TortoiseSVN. For many people, this makes interacting with Mercurial much easier. There's a lot of room for improvement, adding graphical UI to interesting extensions like pbranch and others. The project keeps a TODO list of suitable tasks for a Summer of Code.

1.7. Conversion tools

Mercurial is a relatively new entrant in the VCS market, and many projects are still using older VCSs such as CVS and SVN. While we currently have some tools to help migrate to Mercurial in the form of the ConvertExtension, these tools could certainly use more improvements. Specifically, enabling the use of Mercurial as a client for SVN or even git and/or Bazaar-NG repositories would be very nice, as it enables developers to make their own choice regarding the use of their VCS client, thereby drastically enlarging our userbase.

The hgsubversion extension already works quite well, but better integration with the existing mercurial user interface would be nice.

1.8. C version of some lower-level operations

It should be possible to extract a large performace improvement from writing a C version of some basic operations. The main candidate for this would be the code that handles the index of a [:RevlogNG:revlog]; other parts of the revlog implementation (like the heads operation that is used in the WireProtocol and when calculating tags) could also benefit quite a bit.

Some work has already been done at

2. Notes on applying

Here are some tips on what you might want to include in your application.

3. Getting things done

Some idea of how we would expect the project to be carried out.

4. Mentors

5. Students Considering Application

6. Applications Received From

7. Project status


"Google Summer of Code" is a trademark by Google Inc.