以下是否是实现版本控制的可行策略（使用“示例”作为示例文档类型）：
拥有一份原始文档，其中类型字段名为 example_original。
文档的后续更改都以 example_change 类型和 example_original 文档的 id 作为键。更改还将带有时间戳。
保留一个类型为 example_current 的文档，该文档是 example_original 的结果，所有 example_change “已应用”。一个新的 example_change 文档将自动应用于该文档。
查找特定版本将包括检索 example_original 文档并应用所需的更改（主要是到某个时间戳，但也可能是许多更改）。
我应该提一下，我的用例将涉及对原始用例的有限数量的更改。大多数更新将包含新的原始文档。虽然这是我当前的用例，但如果涉及到许多更改，我也会对可能导致的问题感兴趣。
您认为这种方法有哪些优点和缺点？
本文中描述的作为附件的版本控制方法应该适合大多数人的版本控制要求。
我的第一个担心是：当“获取”某个版本时，您可以在不修改数据库的情况下将更改应用到原始版本吗？
您是否需要从历史记录中删除某些内容？你真的确定吗？真的，真的确定？树枝呢？
总而言之，这看起来是一个复杂的策略。请记住，我听说过 CouchDB，但从未使用过它。我会采用更简单的方法：
创建文档时，您会分配一个 UUID。不要使用该名称，否则在重命名操作期间会遇到麻烦。添加一个显示为“1”的版本字段。创建第二个文档，其中包含具有相同 UUID 的文档列表，或者将“父”指针添加到第一个文档。
每个文档都有一个“历史文档”可以更快地导航历史，但父指针更“安全”（因为你不能轻易地用它们创建非法结构）。
当您创建新修订时，重复使用 UUID 并分配一个新的、唯一的版本。更新历史文档或父指针。
这种策略实现起来非常简单，并且在以后允许各种灵活性。您可以轻松擦除部分历史记录，重命名很简单，并且可以创建分支。
这些文件的商业状态如何，尤其是合法的？我曾在您的提案从商业角度不合适的情况下工作，因为需要证明作为 v.3 呈现的文档确实是文档的版本 3。动态应用增量不会减少合规性要求。
如您所说，如果不经常更改文档，那么您将不会通过存储增量而不是整个文档来节省太多磁盘空间。存储整个文档还可以可靠地预测任何文档的检索时间。它还降低了检索过程的复杂性。
使用 CouchDB 进行版本控制的策略是永远不要压缩包含您需要保留完整历史记录的文档的数据库。您仍然可以压缩其他数据库。这个简单的策略现在可以通过编辑冲突解决策略开箱即用。
删除文档可以通过编写没有内容但已删除属性集的新版本来完成。
分支不能以这种方式完成，因为版本控制机制提供了一个单一的修订线程。
现在对于 CouchDB 可能的未来：