Re: Google Code: Support for Mercurial and Analysis of Git and Mercurial

From: Shawn O. Pearce <spearce@spearce.org>
Date: Apr 27, 2009, 21:15 UTC
Message-ID: <20090427211502.GI23604@spearce.org>
In-Reply-To: <alpine.DEB.1.00.0904261208000.10279@pacific.mpi-cbg.de>

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:

Show 10 quoted lines

> On Sun, 26 Apr 2009, Christian Couder wrote:
> 
> > For information, now Google Code supports Mercurial [...]
> > 
> > Mercurial was choosen over Git because of this (one year old) analysis:
> > 
> > http://code.google.com/p/support/wiki/DVCSAnalysis
> 
> FWIW some little bird (yes, related to the Google Code team) told me that 
> the real reason was because [...]

There were certainly technical factors involved.

As the DVCSAnalysis document above describes, Hg's relatively efficient custom Hg-in-HTTP protocol performs about as well as git:// does, but requires only stateless HTTP, rather than a stateful direct TCP connection.

There is a fundemental reason why Google App Engine only supports incoming HTTP connections on 80/443. Its easy to stand up a new application behind the existing load balancers. Its quite a bit more effort to add support for yet-another-protocol.

As the recent discussion on eclipse.egit

  http://www.eclipse.org/newsportal/article.php?id=34&group=eclipse.egit#34

showed, many users are stuck behind corporate firewalls where only HTTP transit is available.

Tossing aside the Google server infrastructure and why HTTP might be preferred there, Google also tries to target the widest user base possible. Running your VCS through HTTP, which can be easily run through a corporate proxy, gives a wider user base than running your VCS through an SSH tunnel, or a relatively new IANA assigned port.

A long-time GCC committer, and an old SVN committer, pointed out to me the other day that the reason why SVN uses HTTP is so it can get around corporate firewalls without involving the IT staff. Because for the past 10 years, being "on the Internet" has meant being "behind an HTTP and SMTP proxy". And "tunneling through HTTP" is somehow safe, no matter how insecure the protocol might be; while opening an IANA assigned port causes the world to end.

IOW, if Git wants to expand into these user communities where the individual is stuck behind a corporate proxy that only permits HTTP "for security reasons" (but blindly winds up passing through whatever it gets), we need to support a more efficient HTTP protocol.

-- 
Shawn.