I would disagree that referential integrity and schemas are the only issues a DB version control should focus on.
For example, I would be very interested in having git like branching on top of something like this - http://sandbox.substance.io/docs/lorem_ipsum.json. Basically version controlled schemaless object tree.
I recently implemented something like this, backed by mongodb, and by exposing a HTTP api which mimicked git. I had to relax these two requirements, but it is still worth it.
However I would be very much interested in using libgit2 with a database backend instead of filesystem.
Comments
I would disagree that referential integrity and schemas are the only issues a DB version control should focus on.
For example, I would be very interested in having git like branching on top of something like this - http://sandbox.substance.io/docs/lorem_ipsum.json. Basically version controlled schemaless object tree.
I recently implemented something like this, backed by mongodb, and by exposing a HTTP api which mimicked git. I had to relax these two requirements, but it is still worth it.
However I would be very much interested in using libgit2 with a database backend instead of filesystem.
EDIT: not affiliated with substance in any way.
You can implement a change DAG for a DB inside the DB. It works pretty well.
What is a change DAG?
A directed graph showing the dependencies between changes.