Google's project hosting service [LWN.net]

Google's project hosting service

Posted Aug 14, 2006 19:40 UTC (Mon) by Tet (subscriber, #5433)
Parent article: Google's project hosting service

The strange decision here is the use of Subversion. I mean, I can understand it being an easy stepping stone up from CVS. But Subversion is anything but state of the art where revision control is concerned, and the decision to use it for a new project hosting system seems backwards to say the least. One of the distributed systems (darcs, bzr, monotone, mercurial, etc.) would have been a much better choice. There is an almost unlimited range to choose from, in various states ranging from experimental to stable and ready for production use. But surely one of them could have met the requirements that Google have, and wouldn't have hit the scalability problems that they've mentioned with svn.

to post comments

Google's project hosting service

Posted Aug 14, 2006 23:52 UTC (Mon) by gstein (guest, #3612) [Link] (1 responses)

We have seven people on staff that are committers on the Subversion project, growing to nine in a few weeks. They are some of the foremost experts in the world on Subversion. That is more people than some of those alternatives' entire development team. With that kind of experience, why would we NOT use it?

Second, Subversion's user model and design fit very well with Google's model of providing (HTTP-based) services. We knew it would fit, and we had the depth of experience to make it work very well.

And for scalability: no version control system on the planet can meet the scaling needs that we want to target. Even in a distributed case, people still need to fetch a master copy from one central project repository to begin their work. We have to be able to support that load, and nothing out there can do it. That's why we built a new backend for Subversion. We knew that it could, given an upgraded storage system.

"State of the art" is debatable. There are lots of interesting alternatives [to centralized version control] being developed today, but I do not believe any of them have the maturity, robustness, tool support, documentation, history of deployment, and more that Subversion has. None of them. In a few years? Sure, I hope that the fragmentation will be reduced and there will be a clear and solid winner in the distributed-repository camp which answers "yes" to all of those points.

Regardless: the argument about whether centralized versus distributed repositories is not "obvious". One is not better than the other. Both models are valid for various scenarios. We chose one model based on our experience and what we thought would make the most sense for the largest group. If that does not suit some projects' needs, then they can simply use another service. We want to do the best job possible, and that means some compromises must be made. And that means we aren't going to have everybody's favorite tool.

Google's project hosting service

Posted Sep 1, 2006 7:08 UTC (Fri) by bjornen (guest, #38874) [Link]

(Thanks for talking to us Greg) gstein wrote:
> We have seven people on staff that are committers on the Subversion project, growing to nine in a few weeks. They are some of the foremost experts in the world on Subversion. That is more people than some of those alternatives' entire development team. With that kind of experience, why would we NOT use it?

I think we all assumed that Google hired seven Subversion developers *because* they wanted to use Subversion on their new service. It's actually a coincidence?