Hacker News new | comments | show | ask | jobs | submit login

"Veracity goes beyond versioning of directories and files to provide management of records and fields, with full support for pushing, pulling and merging database changesets, just like source tree changesets."

Okay, I re-read that three times, and I still parse that as some form of database versioning (vs. a database where versioning data is stored)... I mean it talks about records and fields, etc. I guess we'll have to wait a bit to see what's supported.

On the other hand, tghw's interpretation could be very on the mark as well (e.g. simple meta data that goes alongside the sourcecode).

tghw's interpretation is closer to being correct.

A Veracity repo can have lots of DAGs (directed acyclic graphs).

A DAG in a repo can either be a "tree dag" or a "database dag".

Veracity's notion of a "database" is a model that is unique to Veracity, although its concepts are quite common. Records. Fields. Multiple record types. Simple constraints. Links between records. Simple queries. It's not SQL.

Nothing here implies that Veracity will help you, as a database developer on SQL Server or Oracle, manage the versioning of your schema and sprocs and so on. Those are interesting features, but they're distinct from (and a lot higher level than) the stuff I was describing.

I am very interested in that "database dag". If it works the way I think it does, I think it will be far more significant than the source control part of the product. For example, I'd like to be able to put together a decentralized knowledge base. Who knows, we may see http://redmonk.com/sogrady/2010/05/04/open-data-github/ sooner than later.

Hi Eric, love your ambitions. Why did you feel the need to put something so database-y right into the repo and go beyond file/directory versioning and key,value tags?

Thanks for clarifying!

Guidelines | FAQ | Support | API | Security | Lists | Bookmarklet | Legal | Apply to YC | Contact