couchdb-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Robert Ames <>
Subject Re: Re: How reliable is the versioning system?
Date Sun, 26 Jul 2009 21:19:23 GMT

> we don't recommend using this for any kind of revision control system
> and we advise that you roll your own.

Piggybacking on this thread (sorry, I'm having to copy/paste it from web archives as I've
just subscribed)...

Philosophically, what is the relationship between Git and CouchDB?

When initially I saw CouchDB advertised as "distributed", I assumed it meant like HBase /
Hadoop, but now it looks like it is more designed for distributed as in Git (working set must
fit on a node), although it looks like there is talk of it being straightforward to shard
out your data to multiple nodes.

In addition, I see here an explicit recommendation is to maintain revision history outside
of CouchDB, and it seems as though the replication model is pretty similar to Git's model...
assuming a target workflow / application similar to wikipedia:

  - I can map git operations to couch using git-hooks
  - I can distribute (eventually) couch across multiple nodes
  - I can have multiple git backends hosting the same content or separate git repo's (ie:
one for 'content', one for 'comments')
  - I can feed one or more runtime couchdb's as it makes sense (ie: content v. comments, new
v. old, etc.)

Before I go charging down this path, is there any previous thought in mapping git to couchdb
or vice-versa?  Assuming it's unlikely I'll get as popular as Wikipedia (but considering that
as an upper-bound on probable size), are there any potential holes in pairing Git w/ CouchDB,
especially attempting to consider Couch primarily for runtime indexing / relations / queries
(wanting to avoid using traditional SQL and avoiding having CouchDB as the primary system
of record)?


View raw message