Relational database backend for mercurial or git

Question

What I like about fossil is that it uses plain old sqlite to store changesets, files, etc. I can use its command line tool to query the repository, but if I want something not supported by it, I can fallback to writing an sql query.

Mercurial and git are more mature, they have more libraries, more momentum, but they use their own repository format. I wonder if it's possible to have sqlite as their repository backend. (I know there are tools to query a mercurial or git repo directly, but sql seems easier.)

Answer 1

With git, the repository format is a pretty fundamental part of the way everything works. You'd have to do a lot of work to change that.

I haven't read any of mercurial's source, but I imagine the situation isn't much different.

As I suggested in my comment, I'm not really sure why you'd want to do this. For git to still be able to have all of its advantages, you'd have to store git objects in your sqlite database. You'd still need all of the low-level git tools to access and manipulate them - you're not going to be just looking up blobs and trees by their SHA1s and doing all the rest of the work yourself. (And even if for some reason you wanted to, you could do that just as easily by looking in the git objects directory.)

My suggestion would be that, if you find that there are operations you want to perform in git that are unsupported, you familiarize yourself with some of the plumbing commands and figure out how to write them as scripts. Git really does expose pretty much the lowest level of operations you could want.

P.S. If you should find a specific unsupported operation you want to do, and are having trouble finding the plumbing you need to perform it, or with the scripting necessary to implement it, post a question here! No reason to get stuck just because you can't use sql.

Answer 2

As Jefromi writes, Mercurial is also using a custom format to achive high compression and fast access to any revision. This is the revlog format which is an append-only data structure that takes advantage of the immutability of changesets in Mercurial.

However, it is of course possible to replace this storage format with another if you like. Google did this when they put Mercurial on Bigtable for code.google.com. One funny consequence of them using their own backend format is that you don't see any revision numbers in their web interface. In normal Mercurial, the revision numbers (the local-only integer you can use instead of the full changeset hash) are the index of the changesets in the revlog. When changesets are not stored in revlogs, there is no natural index and therefore Google shows you no revision numbers.