We've moved! Come visit our new blog:

Blog Archive

Friday, April 24, 2009

Mercurial support for Project Hosting on Google Code

We are happy to announce that Project Hosting on Google Code now supports the Mercurial version control system in addition to Subversion. This is being initially rolled out as a preview release to a few invited users on a per-project basis, so that we can iron out the kinks before making this available to the general public.

Mercurial, like Git and Bazaar, is a distributed version control system (DVCS) that enables developers to work offline and define more complex workflows such as peer-to-peer pushing/pulling of code. It also makes it easier for outside contributors to contribute to projects, as cloning and merging of remote repositories is really easy.

While there were several DVCSs that we could support, our decision to support Mercurial was based on two key reasons. The primary reason was to support our large base of existing Subversion users that want to use a distributed version control system. For these users we felt that Mercurial had the lowest barrier to adoption because of its similar command set, great documentation (including a great online book), and excellent tools such as Tortoise Hg. Second, given that Google Code's infrastructure is built for HTTP-based services, we found that Mercurial had the best protocol and performance characteristics for HTTP support. For more information, see our analysis.

If you would like to help us launch Mercurial and to try out the features as an invited user, please fill out the following form. We are currently looking for active projects with more than two users that are willing to try out Mercurial and work with us to identify issues and resolve them. For projects that plan on migrating from Subversion, see our conversion docs for the steps required for this process.

Our implementation of Mercurial is built on top of Bigtable, making it extremely scalable and reliable just like our Subversion on Bigtable implementation. For more information on our Mercurial implementation, we will have a TechTalk at Google IO that will be led by Jacob Lee, one of the core engineers working on Mercurial support. Let us know if you plan on attending and we'll give you access to Mercurial ahead of the talk.

Git de-facto? Sort-of. Like MySQL is the "de-facto" SQL server people use. Both due to people not knowing any better and being to lazy/stupid to actually do any research, so they pick what "everyone else uses". In the case of Git, it's "those kernel guys are using it, so it must be *great*".

I do hope Google Code's adoption of Hg helps to balance this out a bit.

Code revision control software is nearly as much about personal taste and usage style as it is about "real" features. Personally, I found it much easier to transition from bitkeeper to git than to any other distributed revision control system I tried. I don't recall offhand what my thoughts of mercurial were at the time, but ultimately I didn't find it to be suitable to me.

I would love to see google code eventually pick up git support as well, however, Mercurial is a far sight better than SVN for open source project usage. Distributed truly is better!

It would be very useful to have git support too. Most major Open Source project have now switched to git (kernel, X, Gnome, etc), while only one uses Hg (Mozilla). It would be especially useful to have git support for Android since it seems to be the preferred DVCS in that part of Google.

Not sure I see what the issue is. There are excellent free and commercial choices already for any and all open source projects. If you use git, there is github. If you use mercurial, there is bitbucket. Everybody can be happy.

Google doesn't recognized Mercurial as a superior SCM than git or Bazaar, but rather evaluated it as a more suitable solution for given situation.And anyway, they're using other solutions themselves (Android team using git, for example), so I'd say suum cuique.

I completely agree.Hg is a great DVCS and mantaining support for both centralized and distributed (both simple to use and enough powerful to be useful :) ) is the right choice to support all kinds of projects hosted on Google Code.

(and it's written in python like large amount of google's own code :D )

The thing is, if you are dealing with distributed version control you don't need the google code really or any central source code repository. In fact, the dvcs would be really powerful if somebody would come up with a coder's social network with a strong source code managing linking.You can choose any free web host to distribute your own clone from a certain code repository with your own changes without actually separating from other's code. So it's a good thing to have a dvcs system on the google code, but in the terms of distributed system you need a new development discipline to using it as an actual distributed code management which is exactly the opposite that the sf.net, github or the gc itself can offer.

On git: mercurial/hg, bazaar were the first widely available distributed version control systems and as such they have a little "concept" kinda smell: VCSs mustn't created on a scripted level since the code management operations need to be as fast as possible in order to encourage the developers to use them as frequent as possible. Now python is a good language and system but it fail at this point: it is interpreted (even with the "precompilation" not fast enough) so any system built on the top of it consequently slow. Now it is good enough for server side but if you're dealing with it regular basis on your system (e.g. tortoisehg) you'll experience a terrible overhead. The CPU power doesn't mean too much since the real time parsing cannot be coupled with the number of cores and one could expect exponentially growing parsing time for more and more complex codes. In these matters git performs better because the underlying system is built on native tools and the shell script tools are just for the user interface. That's a sort of advantage what you can not ignore. git is much younger than hg or bazaar and it just actually got in to the shape to say: this is a system that I can use in my usual tasks. Because of that the lack of convenient tools will go soon away and therefore it could grow to a reference distributed file system. I haven't got this feeling using mercurial even it implements a very similar functionality.