Announcing Eclipse Labs

Many of us here at Google, along with the open source community, use the Eclipse IDE when we develop for Android, App Engine, and Google Chrome. We also have a lot of Google engineers that use Eclipse to build our own internal products. So, when the Eclipse Foundation approached us with an idea to encourage the Eclipse ecosystem, we were very happy to help.

Today, we’re excited to announce the result of our collaboration: a Beta version of Eclipse Labs powered by Google Project Hosting, a single place where anyone can start and maintain their open source projects based on the Eclipse platform with just a few clicks.

The goal of Eclipse Labs is to improve the visibility of unofficial add-on projects. We hope that this will help Eclipse users find those projects quickly and that it will help popular projects get on the path to becoming Eclipse Foundation projects. For more information, see the Eclipse Foundation’s blog post.

To get this community started, we’re eager to seed Eclipse Labs with Eclipse add-on projects currently on Google Code. If you have an add-on for Eclipse that you would like to move to Eclipse Labs from Google Code, please let us know by filing a migration request.

Here are a few projects that have already migrated:

• Workspace Mechanic - Workspace Mechanic for Eclipse
• Project Hosting Connector for Mylyn - Eclipse plug-in for Google Project Hosting issue tracker

Let us know what you think in our developer forum and if you’re attending Google I/O, be sure to drop by the Developer Sandbox for Eclipse or visit the Google Project Hosting team during office hours.

By Ali Pasha, Product Manager, Google Project Hosting

Faster Subversion Hosting for Project Hosting on Google Code

When we launched our first Subversion-on-Bigtable service in 2006 our goal was to scale to support hundreds of thousands of projects, with the idea that we could continue to improve the service over time. A year ago, however, we realized that we would have to rebuild our Subversion service to make dramatic improvements in performance. So, we did what we had to do: we rebuilt our service from the ground up, focusing on speed and reliability.

We are now happy to announce that we have rolled out our new service to all our Subversion users. As a result, most common Subversion operations are about 3 times faster than they used to be.

One of the features of Subversion's HTTP-based protocol is that anyone can browse repositories through a normal web browser. Many open source projects hosted on Google Code use this feature to host websites for their project or post the latest versions of their software. We didn't anticipate how popular this would be when we designed our first Subversion service, but our new system has special optimizations for browser access. Latency for these pages are much lower and international users will see a dramatic improvement. We also set the appropriate caching headers, which can be manually controlled with the google-cache-control Subversion property.

To improve our reliability, our new service now has a custom replication system based on the Paxos algorithm. Whenever you make a change to your repository, the new data is now copied to several different data centers before our service reports that the commit has succeeded --- so you can code in peace knowing that your data is stored safely in multiple locations.

If you haven’t already, we encourage you to try out our new Subversion service and let us know what you think.

By Jon Trowbridge and Tony Zale, Google Project Hosting

Happy 5th Birthday Google Code!

How time flies! It was about five years ago that we launched Google Code to the world. When we launched Google Code, we wanted to make code.google.com a great resource where developers could learn about our vision for open source and the open web. We started in 2005 with a handful of our own open source projects, links to just eight APIs and an announcement of the first ever Google Summer of Code, our now-annual program that introduces university students to open source development. By 2006 our API list had grown to 21, in 2007 there were 37, and today our collection of more than 60 APIs receive over four billion hits per day. Check out the changing face of Google Code below -- from 2005, 2007 to the present.



With the meaning of open in mind, Google Code set out to foster best practices in developer documentation, build a community around web and open source development and demonstrate the power of Google technologies. Over the past five years code.google.com has come a long way from eight APIs, maturing into a destination for developers to explore our growing family of APIs and developer products, whether they speed up the web, alleviate cross-browser issues, make hosting web applications easy and scalable or make the web a more social place.

Google Code has also become an interactive place to share ideas. Not only can developers prototype their work in a Code Playground, they can also use Project Hosting on Google Code, a fast, reliable and easy way for developers to host all kinds of open source projects. Today, there are more than 240,000 projects registered, with commits coming in at about 17,000 per day...about 1 every 5 seconds. We also host 800 open source projects of our own, including four projects (Android, Chrome, Chrome OS and GWT) with over a million lines of code each.

It’s been an amazing five years, but there’s still a lot of work ahead. We’re dedicated to helping the developer and open source communities thrive in as many ways as we can. To celebrate our birthday and thank everyone for supporting code.google.com over the years we’re rolling out a new, faster Subversion server, which will double the source code storage for Project Hosting on Google Code from 1GB to 2GB. Happy coding!

By Chris DiBona, Open Source Programs Manager

Issue Tracker Data API for Project Hosting

I'm excited to announce the Issue Tracker Data API for Project Hosting on Google Code! The Issue Tracker Data API is a Google Data API that you can use to programmatically add new issues, make changes to existing issues, or simply access issues for your open source project.

This means that the issue tracker data for your open source code is now liberated!

To get started with the API, please refer to the following documentation:

• Issue Tracker Data API Overview


• Issue Tracker Data API for Java


• Issue Tracker Data API for Python


• Issue Tracker Data API Reference

If you find yourself digging into the API and creating something useful that others can use, please let us know and we'll be sure to add it to our documentation. As always, your feedback is also welcome.

The team would also like to thank Joe LaPenna, who contributed the Python client for the Issue Tracker Data API in his 20% time.

By Jacob Moon, Google Project Hosting

Update: Net::Google::Code now supports the Issue Tracker Data API

Mercurial server-side clone support for Project Hosting on Google Code

When we launched Mercurial support our goal was to get to a point where we could enable a social coding experience. Today, I am happy to announce that today we have support for both 'project' clones and 'user' clones.

Project owners can now create multiple repositories for their project, and they can choose to make any of those new repositories a clone of any of the project's other repositories. These project clones share the same commit access permissions as the original project and make it easier for project members to work together on new features. A common pattern in the Mercurial world is to place each "official" branch into a separate repository with naming conventions like "project-crew", "project-stable", and so on.

In addition to project clones, any user can visit any Mercurial repository and create a server-side user clone of that repository, without asking permission from the project owner. These personal user clones can be easily shared with other developers -- who also can make a clone of that clone. Once a user has finished her changes in a user clone, she can coordinate with the canonical project's contributors to review and incorporate her changes.



User clones aren't forks, in the traditional sense, where a fork has little intention to contribute back to the original project. Rather, the entire purpose of a user clone is to allow users to contribute to projects without requiring official commit access permissions. Because mercurial is a distributed (peer-to-peer) version control system, it excels at branching and merging. If the project maintainers like the new code, they just "pull" the changesets from the clone and merge them into an official project repository. It's all much more elegant than emailing patches back and forth, anonymous contributors get to use the same tools as core developers.

The instructions for creating a user clone can be found on the checkout page for any Mercurial project (e.g. twisty) and existing clones for a project can be found under the Clones sub-tab under Source.

Please let us know if you have any feedback or find any issues. Happy cloning!

By Nathaniel Manista and Jacob Lee, Project Hosting on Google Code

Heavy Duty: What Project Hosting Users are Doing

In July, the Project Hosting team announced the People sub-tab where project members can easily document their duties within their projects.


Here are the top ten most frequently selected project duties:

1. Lead by providing a project vision and roadmap
2. Design new features, write code and unit tests
3. Design core libraries, write code and unit tests
4. Have fun hacking and learn new stuff!
5. Test the system before each release
6. Review code changes and provide constructive feedback
7. Plan the scope of release milestones and track progress
8. Lead the UI design and incorporate feedback
9. Write end-user documentation and examples
10. Triage new issues and support requests from end-users

Those frequent duties are a testament to the serious and thoughtful software development processes often found in open source development. But, open source is not all hard work: our users also decided that it was important to document some of their more colorful duties.  Those ranged from general, "Be awesome," to vicarious, "Watch nervously as students write code," to self-effacing, "Create elaborate unit tests for small corners of the library, write hilariously malformed XML comments, and mercilessly break the build," to simply practical leadership, "Buy the pizza for everyone else."

Don't skip your duty to write your own! Just click the People sub-tab and start to document what you and your project team are supposed to be doing.

By Jason Robbins, Google Code Team

Above and Beyond the Call of Duty, with Permission

Project Hosting on Google Code is a beehive of activity, with many large and active projects and even more that aspire to that level. Now it will be a little easier for project members to sort out who should be doing what by documenting each member's duties in plain language on the new People sub-tab. Here's an example from the zscreen project:


Duties describe what each member is expected to be doing. Project owners can grant permissions that control what each member is allowed to do. While permissions can be fairly fine-grained, it's usually best to grant broad permissions, and then trust your project members to do their duties or go above and beyond them when the situation calls for it.

In open source software development, anyone can access the source code of the project, and it's important to allow anyone to access issues and project documentation. But in some projects, there is a need to restrict some information to a subset of project members for a limited time. For example, you might want to quickly patch a security hole before publicizing the details of how to exploit it. Project members can now place restrictions on individual issues to control who can view, update, or comment on them.
Here's some of what our new permission system allows project owners to do when they need to:

• Acknowledge the role of a contributing user without giving them any additional permissions
• Trust a contributor to update issues or wiki pages without letting them modify source code
• Restrict access to specific issues to just committers, or to a specific subset of members
• Restrict comments on specific issues or wiki pages when another feedback channel should be used instead
• Automatically set access restrictions based on issue labels

Getting started is easy, just click the People sub-tab and start to document what you and your project team are supposed to be doing. If you need to mess with permissions, see our permission system documentation for all the details.

If you'd like to meet some of the people behind Google Code, please drop by the Google booth at OSCON 2009 this week.

By Jason Robins, Project Hosting on Google Code Team

Apollo 11 mission's 40th Anniversary: One large step for open source code...

On this day 40 years ago, Neil Armstrong and Buzz Aldrin became the first humans to walk on the Moon. This was quite an achievement for mankind and a key milestone in world history.

To commemorate this event the Command Module code (Comanche054) and Lunar Module code (Luminary099) have been transcribed from scanned images to run on yaAGC (an open source AGC emulator) by the Virtual AGC and AGS project.

For more information on this project, I recommend looking at the website and the open source project.

Here are a few links to the source code:

• http://code.google.com/p/virtualagc/source/browse/trunk/Comanche055/CM_BODY_ATTITUDE.s?r=258
• http://code.google.com/p/virtualagc/source/browse/trunk/Luminary099/LUNAR_LANDING_GUIDANCE_EQUATIONS.s?r=258
• http://code.google.com/p/virtualagc/source/browse/trunk/FP8/FP8.s?r=258

As the project evolves, look for syntax highlighting done with a special extension for google-code-prettify.

Image - NASA/courtesy of nasaimages.org

By Nathaniel Manista, Project Hosting on Google Code

Mercurial Now Available to All Open Source Projects

About a month ago we announced Mercurial support for early testers. Today, we are happy to announce that all Project Hosting users can create a new Mercurial project and convert their existing projects from Subversion to Mercurial. 

We also want to thank the projects that helped us test support for Mercurial. Projects like Clojure-Dev and Spice of Creation helped us discover new usage patterns and fix several unforeseen issues. Unlike our mature Subversion implementation, there are still a few issues/features that we are working on. 

We therefore encourage everyone to be familiar with what is supported before picking Mercurial.

Please let us know if you have any feedback or find any issues. If you're coming to Google I/O, be sure to come meet us in person and hear our talk about Mercurial on Bigtable this Thursday at 3:45pm-4:45pm in Moscone West - Room 5. We have Mercurial SWAG!

By Ali Pasha, Google Code Team

Closing the Loop - Version Control and Issue Tracker Integration

If you are a developer on an open source project hosted on Google Code, and you are committing a change that fixes a known defect or adds a requested enhancement, you will want to update the associated issue. You could do that by first committing the change, and then using the web UI to update the issue. But, now there is a more convenient way to close the loop: you can update an issue by putting an issue tracker command in your commit-log message.

There are commit-log commands to:

• Easily set an issue's status to Fixed.
• Update any aspect of the issue, and add a comment.
• Enter a new issue.
• Request a code review.

The most common case is to close the issue as Fixed. For example, your commit-log message might be:


Now, your commit links to the issues, the issues are closed, and a back-link is added from each issue to the revision.

Updating an issue, without closing it, can be useful when a commit partially resolves the issue. And, opening a new issue is useful when you know that follow-up work will be needed. For more information and examples, see our issue tracker documentation.

By Jason Robbins, Google Code Team

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.

By David Baum, Software Engineer

Custom Logos for Open Source Projects

Open source projects now have customizable logos! You can use this to maintain consistency with your other websites or just for fun. Here's an example of a project with its own logo. To update the logo on your project, click on the Administer tab (as long as you're a project owner) and upload an image. It will automatically be resized. You can switch back the default logo or upload a new logo at any point.

Google projects such as Chromium will retain the large Google logo.

For other notable changes, see our groups post.

By Andy Chu, Software Engineer, Google Code

Staying up to date with Google Code

By Ali Pasha & Jacob Moon, Google Code

As the number of developers and projects have grown on Google Code, we've started thinking about how to get projects to learn from and work with each other. Today, we're happy to announce that we have made a few steps towards that goal.

First, we've added user update streams to make it easy to see what a particular user has been doing across Project hosting on Google Code. As an example, take a look at Ben Collins-Sussman's activities on his profile page. Ben works on Google Code, but it's obvious that he has other interests as well.

In addition, tracking open source projects and other developers is as easy as starring a project or a developer profile. Starring a project or developer adds a link in your new "Starred Projects" and "Starred Developers" section of your profile page, making it really easy to find those projects or developers again. Starred projects are also added to the new "My projects" drop-down, which makes it easy to navigate to a project from anywhere on the site.

Once a project or a developer is starred, all updates from starred projects and developers can be tracked by looking at your personalized updates.

For those that prefer to use their feed reader, use the following new feeds:

• Updates for a user - http://code.google.com/feeds/u/{username}/updates/user/basic
• Developers a user is tracking - http://code.google.com/feeds/u/{username}/updates/projects/basic
• Projects a user is tracking - http://code.google.com/feeds/u/{username}/updates/developers/basic

As always, we look forward to your feedback.

Project Hosting Upgraded to Subversion 1.5

By Ben Collins-Sussman, Google Code Project Hosting

We're pleased to announce that the Subversion component of Google Code Project Hosting has been upgraded to version 1.5. What does this mean to users? If you're using a Subversion 1.5 client, you can now take advantage of Subversion's improved "merge tracking" feature to manage branches.

Prior to Subversion 1.5, branching wasn't very friendly to users. A developer had to manually keep track of the revision from which a branch was copied. She also had to keep track of exactly which changes had been merged into a branch already (to avoid repeated application of changesets), and to always specify the exact range of revisions to merge next. Merging a branch back to trunk was even more difficult, since it required comparing two precise URLs in a very specific way.

With improved merge-tracking, users never have to type a single revision number. Here's a basic example of branch workflow.

1. Make a branch for your experimental work:
   $ cd trunk-working-copy
$ svn cp trunkURL branchURL
$ svn switch branchURL



2. Work on the branch for a while:
   # ...edit files
$ svn commit
# ...edit files
$ svn commit



3. Sync your branch with the trunk, so it doesn’t fall behind:
   $ svn merge trunkURL
--- Merging r3452 through r3580 into '.':
U button.c
U integer.c
...
$ svn commit



4. Repeat the prior two steps until you’re done coding.


5. Merge your branch back into the trunk:
   $ svn switch trunkURL
$ svn merge --reintegrate branchURL
--- Merging differences between repository URLs into '.':
U button.c
U integer.c
...
$ svn commit

For a more detailed discussion of merge-tracking (and its limitations), see chapter 4 of the online Subversion Book. Live in fear of branches no more!

Playing around with Google's AJAX APIs

By Ben Lisbakken, Developer Programs Engineer

For me, documentation isn't always enough to learn about APIs; I need examples that I can play with. That's why I started a fun project recently--a tool for teaching developers how to use Google's JavaScript APIs: the AJAX API Playground. I have been working on this in my 20% time and today I am proud to announce that we are launching the AJAX API Playground as the official way that Google will show JavaScript samples!

The AJAX API Playground is currently loaded with over 170 samples for 8 Google JavaScript APIs (Maps, Search, Feeds, Calendar, Visualization, Language, Blogger, Libraries and Earth) that you can edit and run to help you explore what Google's APIs have to offer. There are also save and export features. The save feature allows you to hold onto an edited sample so you can continue working on it later, while export lets you modify a sample and publish the code to a permanent url.

As the AJAX API Playground is built on App Engine, you can create your own App Engine instance to show off your code samples. The code is open sourced under an Apache 2.0 license and uses several open source libraries and tools, including jQuery, jQuery UI, YUI Compressor, and CodeMirror. You can find the code on Google Project Hosting and learn about adding samples on the project wiki.

Stay tuned for more samples for more APIs. Enjoy!

Happy holidays from Google Code!

By Matt Hansen, Google Developer Programs

At Google Code, we are getting into the holiday spirit early. To thank open source developers for their support, I'm happy to announce that we are giving every project on Google Code a whole lot more quota!

We're increasing the maximum file sizes from 20MB to 40MB, Subversion quotas from 100MB to 1GB, and download quotas from 100MB to 2GB.

Happy holidays!

P.S. If you need more space, let us know!

Adding some style to the wiki on Google Code

By Nathan Ingersoll and Jason Robbins, Google Code

Based on user feedback, we added a few highly requested features to the project hosting wiki on Google Code.

To improve navigation from one wiki page to another, we added side navigation across wiki pages (e.g doctype docs). You can add a 'Wiki sidebar' by specifying the wiki file that describes your side navigation in the Administration tab under Wiki settings.

To help navigate a wiki page, we added the ability to add a generated table of contents. To add a table of contents, just copy the following syntax to your wiki page.

<wiki:toc max_depth="1" />

Finally, to improve the style of your wiki pages we have added some html support. For more information on what html is supported, take a look at the documentation.

As always, we look forward to your feedback.

Introducing Content Licenses on Google Code

By DeWitt Clinton, Google Developer Programs

The Google Code team is pleased to announce the availability of content licenses for projects hosted on code.google.com. Projects owners may now select from either the Creative Commons Attribution license or the Creative Commons Attribution-Share Alike license to indicate the terms under which their non-source code materials may be distributed.



While this may seem like a minor change, it reflects the continued evolution of our mission to support best practices in open source software development.  As the open web increasingly relies on protocols and formats that reach beyond source code, we encourage authors to apply an explicit copyright license to the data, documentation, and related media that complements their work.

Please join us in the project hosting discussion group if you have any questions.

New feeds for Project hosting on Google Code

By Andy Chu, Google Code Team

We get a lot of feedback on Google Code and one of the biggest requests have been for feeds (as you can see in issue 8, issue 131, or issue 190). Therefore, I'm happy to announce that we now have Atom feed available for you to track issues, downloads, Subversion changes, and Wiki updates.

As an example, you can take a look at feeds for Google Web Toolkit:

• Issues feed at http://code.google.com/feeds/p/google-web-toolkit/issueupdates/basic
• Downloads feed at http://code.google.com/feeds/p/google-web-toolkit/downloads/basic
• Subversion changes feed at http://code.google.com/feeds/p/google-web-toolkit/svnchanges/basic
• Wiki changes feed at http://code.google.com/feeds/p/google-web-toolkit/svnchanges/basic?path=/wiki/

For the SVN changes feed you can add '?path=/path/' to the end of the url to filter the changes by path -- for example, '?path=/trunk/' or '?path=/wiki/'. Simply substitute 'google-web-toolkit' for your project to see your feeds.

As always, if you have any feedback please do not hesitate to let us know.

SSL Certificate Renewal for Project Hosting on Google Code

By Ben Collins-Sussman, Open Source Team

If you have open source projects hosted on Google Code, you may have noticed that the SSL certificate changed for the googlecode.com domain. (The old certificate expired, and a new one was generated.) In particular, your Subversion client may have yelled about the certificate not being recognized:

Error validating server certificate for
'https://projectname.googlecode.com:443':
- The certificate is not issued by a trusted authority. Use the
 fingerprint to validate the certificate manually!
Certificate information:
- Hostname: googlecode.com
- Valid: from Wed, 28 May 2008 16:48:13 GMT until Mon, 21 Jun 2010 14:09:43 GMT
- Issuer: Certification Services Division, Thawte Consulting cc, Cape
Town, Western Cape, ZA
- Fingerprint: b1:3a:d5:38:56:27:52:9f:ba:6c:70:1e:a9:ab:4a:1a:8b:da:ff:ec
(R)eject, accept (t)emporarily or accept (p)ermanently?

Just like a web browser, your Subversion client needs to know whether or not you trust particular SSL certificates coming from servers. You can verify the certificate using the fingerprint above, or you can choose to permanently accept the certificate, whichever makes you feel most comfortable. To permanently accept the certificate, you can simply choose the (p)ermanent option, and Subversion will trust it forever.

Thawte is a large certifying authority, and it's very likely that the OpenSSL libraries on your computer automatically trust any certificate signed by Thawte. However, if you want your Subversion client to inherit that same level of automatic trust, you'll need to set an option in your ~/.subversion/servers file:

[global]
ssl-trust-default-ca = true

If you set this option, then your client will never bug you again about any certificate signed by the "big" authorities.

Happy hacking!