Re: Mercurial on BigTable

[Jakub Narebski <jnareb@gmail.com>]

Andreas Ericsson <ae@op5.se> 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 (if you can call
> 3 network requests per not-up-to-date head "well"). Since I can't imagine
> them not doing proper research before launching a project that almost
> certainly cost quite a lot of money, and I personally think that the
> "http rules all" explanation sounded weak, I'm guessing there were other
> reasons as to why they didn't go with git instead, and I'm fairly curious
> to hear them. If I was to take a guess, I'd say git is written in a pretty
> unfriendly way for implementing other storage engines.

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.
Adding Java to Gogle App Engine is, as far as I know, fairly recent;
additionally JGit (git implementation in Java) is not yet full
implementation.

I don't know if Git would be easy to implement on BigTable, and
whether it wouldn't be better for performance to try to implement it
on top of underlying Google File System (GFS) and Chubby Lock Service
_directly_...


Sidenote: lack of good HTTP protocol support (there are some numbers
at the bottom of comparison[1], but not enough detail to satisfy) as a
reason is especially strange now that there was quite long discussion
designing git-over-HTTP ("smart" HTTP protocol); cleaning warts in git
pack protocol, working around HTTP being stateless, ensuring backward
compatibility, ensuring that it would work well with HTTP caches...

But that is the problem with detailed research for "fast moving
target". Good research takes time, and by the time you finished it its
results are already obsolete...

[1] http://code.google.com/p/support/wiki/DVCSAnalysis

> 
> Ah well. In a year or two they'll probably support git as well. One can
> hope at least ;-)

Let's hope to that...

-- 
Jakub Narebski
Poland
ShadeHawk on #git