将以下是用于实现版本的可行策略（使用“示例”作为样品文档类型）：
具有其中类型字段名为example_original一个原始文档。
该文件的后续变化都有型example_change和example_original文件作为密钥ID。 这种变化也将携带时间戳。
保持一个文档类型example_current是与所有example_change“应用” example_original的结果。 新example_change文件将自动适用于本文件。
查找特定的版本将包括在检索example_original文档和应用所需的更改（主要是达到一定的时间戳，但它也可能是一个数量的变化）。
我要指出，我的用例将涉及改变原有的数量有限。 大多数的更新将包括新的原始文件。 虽然这是我目前的使用情况我也有兴趣，会导致如果许多变化，其中涉及的问题。
你在这种方法中看到什么利弊？
我的第一个担忧是：当“得到”某个版本，您可以将改变原有无需修改数据库？
你永远都需要删除从历史的东西吗？ 你真的确定吗？ 真的，真的确定吗？ 如何分支？
总而言之，这看起来像一个复杂的策略。 请记住，我听说过的CouchDB，但从来没有使用过。 我会去一个更简单的方法：
当你创建一个文件，你分配一个UUID。 不要使用名字，否则你会在重命名操作遇到了麻烦。 添加一个版本字段，上面写着“1”。 创建一个包含文件的目录具有相同UUID的第二个文件或一个“父”指针到第一个文件。
有对每个文档“文件历史”允许历史的更快的导航，但父指针更“安全”（因为你不能很容易地创建违章建筑他们）。
当你创建一个新的修订，重新使用UUID并分配一个新的，独特的版本。 更新历史文档或父指针。
这种策略是实现非常简单，并允许各种灵活性更高版本。 您可以轻松地抹去历史的部分，重新命名为简单的，你可以创建分支。
简单的文档版本使用CouchDB
在这篇文章中描述的版本作为附件的方法应该适合版本大多数人的需求。
什么是这些文件的经营状况，特别是法律？ 我已经在你的建议将不会从商业persepctive适当的情况下工作，因为一个需要证明显示为3.0版的文件确实是文件的版本3。 动态应用的增量不会削减遵守芥末。
如果像你说的，对文档的更改罕见洛根。，那么你就不会通过存储的增量，而不是整个文件来节省磁盘空间。 存储整个文件还允许检索时间任何文件的可靠预测。 这也降低了检索过程的复杂性。
一种使用CouchDB版本的策略是不可再压缩它包含了你需要保持一个完整的历史文档的数据库。 你仍然可以紧凑其他数据库。 这个简单的策略今天开箱与编辑冲突解决策略。
删除文件可以通过没有内容，但已删除的属性集写一个新的版本来完成。
因为版本控制机制提供了修订的单个线程分行无法做到这样。
现在对于CouchDB的未来可能的：
