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

["Shawn O. Pearce" <spearce@spearce.org>]

Johannes Schindelin <Johannes.Schindelin@gmx.de> wrote:
> 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.