Subject: Re: Mercurial on BigTable

From: Jakub Narebski <[email-masked]>
Date: Fri, 12 Jun 2009 09:14:14 +0200

On Fri, 12 June 2009, Shawn O. Pearce wrote:
> Jakub Narebski <[email-masked]> wrote:
> > Andreas Ericsson <[email-masked]> writes:
> > 
> > > I'm more curious as to why they didn't choose git. The only explanation
> > > that was actually true is that hg works well over HTTP 
> > 
> > Well, Google App Engine was in Python, so it follows that the crew
> > would have it easier understanding Mercurial code (which is written in
> > Python with parts in C for performance), and in moving it to BigTable.
> 
> This has nothing to do with Google AppEngine.  GAE has CPU and
> bandwidth limitations in place that make running a source code server
> like Hg on it impossible.  E.g. the maximum size you could download
> in a single HTTP request was 1 MB, now its up to 10 MB (IIRC).
> The Hg hosting runs in a different cluster than the GAE hosting does,
> and are managed by different teams.
> 
> > Adding Java to Gogle App Engine is, as far as I know, fairly recent;
> 
> True, yes, GAE Java support is fairly new.

I didn't wanted to say that support for Mercurial (or other DVCS) in
Google Code had anything to do with Google AppEngine.  Rather I wanted
to imply that what might have mattered when choosing between Mercurial
and Git was the fact that there was large pool of people who are 
proficient in Python (and later in Java) _and_ with web application(s).

But I don't quite see how lack of good over HTTP support should matter;
if they are rewriting Mercurial[1] (and earlier Subversion) to use 
BigTable, couldn't they add "smart" HTTP protocol support to Git 
(which I think would be easier)?

[1] Mercurial is not AGPLv3 licensed...

> 
> > additionally JGit (git implementation in Java) is not yet full
> > implementation.
> 
> JGit implements sufficient parts of Git to be a full server, and
> could power a hosting site... indeed it powers Gerrit Code Review,
> which some companies do use as their entire Git server solution,
> rather than e.g. Gitosis.

By "not full implementation" I meant here that as far as I know JGit
doesn't have yet support for _creating_ (as opposed to simply reusing)
deltas in packfiles.

P.S. On the other hand, Mercurial support for multiple branches is
not so good[2], and the way tags got implemented seems iffy to me...

[2] http://schacon.github.com/2008/11/24/on-mercurial.html

-- 
Jakub Narebski
Poland