Google's project hosting service

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

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.