My understanding is that in CouchDB you can't guarantee that older versions of documents will still exists (they might be there, but they could have been removed by compaction or not replicated).
However, there is a fairly nice way of storing older versions of documents - hold older versions as file attachments on the document. See:
This is probably the biggest misunderstanding of couchdb, imo. The versioning system in couchdb is only there to make the seamless replication possible. There's no guarantee that previous versions will exist at a future time, like in git.
Where couchdb has some immense possibilities is in distributed applications, not only server side, but also mobile phones and browsers. Since you can write and contain an entire webapp inside of couchdb, you can technically replicate the entire app to your mobile phone, and it'd work offline or online. And if you need your app on another platform--as long as it has couchdb, you can just replicate it there.
I never see this mentioned in any overviews of comparison for couchdb.
The sticking point right now, though, is that couchdb isn't on very many mobile platforms. There has only been experiments with writing couchdb on top of HTML5's localStore, and jChris et al are working on Couchdb for android.
The "versioning" is really just there to support their optimistic concurrency model, if I recall. The idea is that you know you need to retry your operation if the version hash of the file has gone up since you last read the data and thus you know your local file is out of date.
As I recall, the id field is just a string. It's just common to let it do the automatic "#-hash" representation.
It's been a while since I played with CouchDB though, so I could be off.
I didn't mention that (it does not really matter when choosing one right now), but I too consider that one of the most exciting explorations in this area!
Thanks for the solid comparison, it's a breath of fresh air. We're working on the mobile platform SDKs right now, should be rolling them out all through 2011.
Trying to use CouchDB's versioning system seems like depending on a very leaky abstraction. That you can see it's versioning is a side-effect of how it behaves; not a feature it is providing.
If you need versioned records, you are likely better off identifying your versioning requirements and building to those than trying to piggyback off of something else poorly suited.
Yes, if versioning is the main point, then surely one should take special measures to keep them, as in the case of invoices (stornoed, stornos stornoed, etc). As for a CMS system, for example, it's nice to have most of the history, but nobody gets hurt if some gets lost during replication outages, etc.
However, there is a fairly nice way of storing older versions of documents - hold older versions as file attachments on the document. See:
http://jchrisa.net/drl/_design/sofa/_list/post/post-page?sta...