Johannes Schindelin wrote:
Hi,
On Sun, 26 Apr 2009, A Large Angry SCM wrote:
Another important criteria was which, both or neither of Git and Hg
would actually work and perform well on top of Google Code's underling
storage system and except to mention they would be using Bigtable, the
report did not discuss this. Git on top of Bigtable will not perform
well.
Actually, did we not arrive at the conclusion that it could perform well
at least with the filesystem layer on top of big table, but even better if
the big tables stored certain chunks (not really all that different from
the chunks needed for mirror-sync!)?
Back when I discussed this with a Googler, it was all too obvious that
they are not interested (and in the meantime I understand why, see my
other mail).
I don't remember the mirror-sync discussion. But I do remember that when
the discussion turned to implementing a filesystem on top of Bigtable
that would not cause performance problems for Git, my response was that
you'd still be much better off going to GFS directly instead of faking a
filesystem on top of Bigtable without all of the Bigtable limitations.
Bigtable _is_ appealing to implement the Git object store on. It's too
bad the latency in Bigtable would make it horribly slow.
--
To unsubscribe from this list: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html