概要
CouchDB は、ドキュメントを更新するときに元のドキュメントを上書きすることはせず、元のドキュメントと同一の _id を持ち、新しい _rev ID を持ったドキュメントをデータベース・ファイルの末尾に新しく作成します。この種のストレージ・システムはディスクスペースを消費するため、ディスクスペースを空けるためには定期的に圧縮を行う必要があります。なお、古いリビジョンをビューで表示することはできない点に注意してください。
ドキュメントのリビジョンは、オプティミスティックなコンカレンシー・コントロール（並行処理制御）のために使われます。古いリビジョンを使ってドキュメントを更新しようとすると、更新処理によって衝突が生じます。これらの衝突はクライアント側で解決する必要があります。一般には、ドキュメントの最も新しいバージョンを取得し、これに修正を加えて、もう一度更新を試みます。
@@ How does this relate to replication conflicts?
リビジョンの履歴
コンカレンシー・コントロール以外の目的にドキュメントのリビジョンを利用することはできません。
圧縮の結果、リビジョンは任意の時点で消滅する可能性があります。リビジョンは、クライアントのリビジョン・システムの代わりに使用することはできません。
レプリケーションもリビジョンに影響を与えます。具体的に言えば、レプリケーションではドキュメントの最新バージョンだけがレプリケートされるので、レプリケート先のデータベースでは、レプリケート元のデータベースに格納されていた以前のバージョンのドキュメントにはアクセスできなくなります。
クライアント・システムにリビジョンを実装する方法としては、これまでにいくつかパターンが提案されています。
添付ファイルを使って古いリビジョンを格納する方法。
複数のドキュメントを使って古いリビジョンを格納する方法。
@@ Please add to this list and flesh out the solutions as you see fit.