> 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)? --Robert
