Databranches: using git as a database(kitenet.net)
kitenet.net
Databranches: using git as a database
http://kitenet.net/~joey/blog/entry/databranches/
6 comments
If you're interested in this concept — even (or especially!) for just hacking around on a bored afternoon — Rick Olson gave a fun talk on it last year at RubyConf. "Git: the stupid NOSQL database" http://confreaks.net/videos/443-rubyconf2010-git-the-stupid-...
Wasn't distributed SCM always really just a database for files? Besides hack value, what's the benefit of using git as a (non-file) database when I can just use a proper database?
I would guess that the only real advantage is that you can use git tools to manually explore the object store. So it's highly transparent from a debugging point of view for example.
Giddy - Schema-less, versioned media/document database based on Git.
http://search.cpan.org/~idoperel/Giddy-0.013_001/lib/Giddy/M...
this makes Haskell look interesting: http://source.git-annex.branchable.com/?p=source.git;a=blob;...
Save the database on the torrent worldwide network, it allows for:
easy worldwide publishing, access, distribution,
immorability (no loss possible 4 eternity, even safe 4 evil politicians' needs),
..?,
Third Millenium Proof.
This duo: git-torrent is hitting the streets soon.
It is safe, even where/when internet is forbidden by law.
This duo: git-torrent is hitting the streets soon.
It is safe, even where/when internet is forbidden by law.
Don't torrents have to match checksums in the .torrent file for each chunk? Every time you changed your data, you'd have to publish a new torrent, and all the clients would have to download the new .torrent file.
IIRC it doesn't actually use BitTorrent, it's just inspired by it. The Git and BitTorrent models are related enough that an intelligent synthesis could work nicely.
"GitGraph is a Blueprints Graph which stores its data in a hierarchy of plain text files and plays well with version control software such as Git. This allows multiple parties to edit a graph concurrently and later to merge their changes.
GitGraph also enables partitioning of a graph into functional hierarchies, and to combine graphs in a tree-like fashion. For example, if you have a graph with information about cities, and another with information about people, you can place the two graph directories side by side in a parent directory and load this as a single graph. You can create new vertices and edges, at the parent level, which connect people and cities, and then you can save the whole thing and check it in to Git. Another developer can then check out your work and either load the whole graph or, if he is only interested in either cities or people, one of the subdirectories.
Even if he only loads the graph about cities, he can make local changes to it and push them back to you without invalidating the top-level graph".
See this discussion on the Gremlin Users group (https://groups.google.com/d/msg/gremlin-users/trBKdAW105U/qB...).