Mercurial Makers Meet in Munich
October 21st, 2014 | Published in Google Open Source
Back in August, the Google Open Source Programs Office sponsored a meetup for contributors to Mercurial, a distributed version control system. Learn more about their two day hackfest below.
On August 29th-31st, the Mercurial project held one of its twice-a-year sprints in the Google Munich office. Mercurial is a distributed version control system, used by Python, OpenJDK, and Firefox among others. We had 24 developers in attendance, some from companies with large Mercurial deployments and some individual contributors who volunteer in their spare time.
One of the problems Mercurial wants to tackle soon is scaling from supporting hundreds of thousands of files to supporting millions of files in a single repository. The community has identified two approaches to scaling: shallow clones and narrow clones. Shallow clones will allow clients to pull down only part of a repository’s history, and narrow clones will make it possible to pull history for only some files.
At the sprint, we talked through some of the initial narrow/shallow clone implementation hurdles, like how to securely and efficiently store large manifests, and made good progress on a plan. We spent time working on changeset evolution, which makes it easier to manage the process of collaborating on a patch before it’s done. A group also discussed how to make bookmarks work better for users of changeset evolution in large systems, including developing a good plan around remote bookmark management.
If you are interested in finding out more about Mercurial (or perhaps you’d like to contribute to make it scale even better!) you can find our mailing list information here.
By Augie Fackler and Lennard de Rijk, Google Engineering
One of the problems Mercurial wants to tackle soon is scaling from supporting hundreds of thousands of files to supporting millions of files in a single repository. The community has identified two approaches to scaling: shallow clones and narrow clones. Shallow clones will allow clients to pull down only part of a repository’s history, and narrow clones will make it possible to pull history for only some files.
At the sprint, we talked through some of the initial narrow/shallow clone implementation hurdles, like how to securely and efficiently store large manifests, and made good progress on a plan. We spent time working on changeset evolution, which makes it easier to manage the process of collaborating on a patch before it’s done. A group also discussed how to make bookmarks work better for users of changeset evolution in large systems, including developing a good plan around remote bookmark management.
By Augie Fackler and Lennard de Rijk, Google Engineering