Hacker News Reader

Comment by ken | Hacker News Reader

That's like saying DVCS has nothing to do with VCS -- it's just the server model. Every major advance has been accomplished by increasing the scope of version control.

Arbitrary diff/merge in Git is a great example of the Turing Tar-Pit. It's possible, but prohibitively inefficient for many things I want to do. You can't add your own types, index, or query optimizations.

Today, if I want to store data for my application, I have a choice between good support for rich object types and connections (e.g., Postgres), or good support for history and merging (e.g., Git). There's no one system that provides both.

View on HN

> Today, if I want to store data for my application, I have a choice between good support for rich object types and connections (e.g., Postgres), or good support for history and merging (e.g., Git). There's no one system that provides both.

I like the way you put this. In case anyone's interested in brainstorming I'm dabbling in this problem with a thing called TreeBase (https://jtree.treenotation.org/treeBase/). It's still a toy at this point, but it stores richly typed data as plain text files to leverage git for history and merging and then can use SQLite (or others) for querying and analysis. A very simple database in the wild looks like this: https://github.com/treenotation/jtree/tree/master/treeBase/p...

Have you looked at Qri? (https://github.com/qri-io) - free & open source dataset versioning. Also: https://qri.io

AFAIK I've never seen that one. Thank you very much for the link. Looks very interesting and related to the stuff I'm working on. Thanks!

Couldn't you store the exported database as sql commands? I'm not familiar with every git hook, but if there aren't enough to automated that I guess you could wrap it.

The slowness of destroying a whole database and then recreate it when checking out should be something you can handle by relying on the diff to generate a series of delete commands and a series of insert commands.

But yeah, I guess committing will be slow if you have a lot of data to export. For the time being, it's a trade off to be made.

[I might consider testing this with my current database project. But I'm using SQLite so I guess that implies a lot less data than Postgres.]

> That's like saying DVCS has nothing to do with VCS

I could see myself agreeing to that.

frutiger is correct that the diff algorithm has nothing to do with git itself, in that git can accept pretty arbitrary diff algorithms in the first place for all the commands that take one.

Check out git-diff(1) and --diff-algorithm. --anchored is the one I find the neatest.

DVCS indeed has nothing to do with VCS, it has a lot to do with the data model used by the VCS.

A modern but still centralized VCS like Subversion or Perforce is what you get if you first add networking (CVS) and then atomic commits. Without atomic commits you are pretty much forced to keep a centralized server, and Subversion didn't try to change the server model after adding atomic commits.

DVCS instead is what you get if you start with local revision tracking like RCS, and add atomic commits before networking. Now the network protocol can work at the commit level and is much more amenable to distributed development.

Reply on news.ycombinator.com