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.

43 comments:

  1. Awesome! Thanks so much! I'm glad you recognized HG is better than Git =D Well done guys.

    ReplyDelete
  2. Fantastic! Thanks so much. This is great news.

    ReplyDelete
  3. When should we see Git support! Git is like de-facto now for distributed version control. Btw nice to see HG support!

    ReplyDelete
  4. Wow, now that is indeed some pretty cool stuff!

    RT
    www.anonymity.es.tc

    ReplyDelete
  5. Awesome work guys! Wonderful accomplishment!

    ReplyDelete
  6. 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.

    ReplyDelete
  7. Great work, "our implementation of Mercurial is based on BigTable", now you people are just bragging.

    Interesting, given that the Android team is using Git.

    ReplyDelete
  8. 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!

    ReplyDelete
  9. 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.

    ReplyDelete
  10. Yeah, sure. Please count with me: Mozilla, OpenJDK, Python ... (still counting) ...

    ReplyDelete
  11. 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.

    ReplyDelete
  12. 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.

    ReplyDelete
  13. So, I am guessing we can host a project in subversion and with mercurial?

    ReplyDelete
  14. This is definitely great news

    2Berlin Brown: Yes, but AFAIK you will need to take care about syncing repositories.

    ReplyDelete
  15. 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 )

    ReplyDelete
  16. Suggestion: it might be worth considering allowing more than one hg repo per project?

    ReplyDelete
  17. it sounds good... but why not GIT instead of Mercurial?

    ReplyDelete
  18. Great. When can we expect to see Git now ... ?

    ReplyDelete
  19. That is really great, and the choice show why Hg > git.

    Thanks

    ReplyDelete
  20. Way to go Google! Someone finally got it right.

    ReplyDelete
  21. Yaaaaaaaay! And it's my favorite DVCS too!

    ReplyDelete
  22. Nice to see the move to DVCS support but git should really be supported. I suppose that's a matter of time...

    ReplyDelete
  23. I suggest anyone who says there is no great Windows GUI for GIT checks out Git Extensions. It even has a plugin for Visual Studio 2005 and 2008. I use it daily and works great.

    ReplyDelete
  24. Anyone working on the Linux kernel, like the Android project, will naturally use git. Mercurial is a wonderful system. You hg haters can go sulk with the Ruby AppEngine programmers.

    ReplyDelete
  25. Great! :) I like Mercurial and projectgroups at my school mostly use Google Code because there's nothing the academy provides. Now we can use Mercurial in Google Code so I'm happy. :)

    ReplyDelete
  26. Great news. Does that mean google projects are gonna use more HG and less SVN from now on?

    ReplyDelete
  27. Project Kenai from Sun has had hg and Subversion support since September 2008, and also now offers Git support.

    ReplyDelete
  28. Is there any chance that Mercurial on Bigtable will be usable by the AppEngine people? It would be really nice to clone a repo to AppEngine for internal use (like versioning a wiki, etc.)

    ReplyDelete
  29. If you are not going to support git then I'll move my projects out of google code.

    ReplyDelete
  30. > If you are not going to support git then I'll move my projects out of google code.

    go ahead.

    ReplyDelete
  31. Thanks for Mercurial support!

    ReplyDelete
  32. This comment has been removed by the author.

    ReplyDelete
  33. If you are not going to support git then I'll move my projects out of google code.See if they care!

    ReplyDelete
  34. can't wait for mercurial support to get out of beta!

    ReplyDelete
  35. Cool stuff. Does anybody know when HG support is going public?

    ReplyDelete
  36. It's great that Mercurial is now supported. However, the Google Code workflow is still pretty oriented towards centralized version control (branches and code reviews).

    I hope there will be support similar to Launchpad for distributed version control.

    ReplyDelete
  37. This is great news, time to start learning hg.

    ReplyDelete
  38. Wow, it's really now that is indeed some pretty cool stuff!

    ReplyDelete
  39. Very interesting site. Hope it will always be alive!

    ReplyDelete
  40. Oh, sweet. This might actually make GC usable!

    ReplyDelete
  41. 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.

    ReplyDelete