Near as I can tell, CouchDB revisions are not to be treated like revisions in the document versioning sense of the word. From glancing at other posts, they seem to be regarded as transient data that exists until a coarse-grained compact operation is called.
My question is, if I am interested in using CouchDB to maintain documents, as well as a version-history of those documents, should I allow that to be handled natively by CouchDB revisions, or should I build a layer on-top that will survive a compact operation?
I am thinking the latter, simply because Couch does not replicate revisions of documents, only the latest update. This makes me think revision is a mis-leading name, as it's more of a data structure for stabilizing replication.
You must build that layer because couchdb revisions are not a versioning system for your data.
'revision' is misleading, and so is 'version' and so is every name that has been suggested so far. Suggestions welcome, if only to confirm how tricky naming this is.
来源：https://stackoverflow.com/questions/8263043/how-should-couchdb-revisions-be-treated-from-a-design-perspective