CouchDB如何知道文档的修订历史？

假设有两个数据库被复制，A和B。数据库A拥有一个包含四个修订的文档。修订树如下所示：

   +--- r2a --- r3a
  /
r1----- r2b

   +--- r2a --- r3a --- r4a
  /
r1----- r2b --- r3b

当前的leaf版本显然是

r3a

和

r2b

。根据文档，复制期间仅传输这些修订。所以数据库B将看到：

 r3a

 r2b

数据库B如何知道这些修订的历史？据我所知，唯一被复制的信息是这两个版本，对他们的父母没有任何概念。我错了吗

更新：为什么数据库B应该知道历史记录？

考虑在第一次复制之后对数据库A进行更多更改。每一个分支都可以通过另一次修订来结束。修订树如下所示：

   +--- r2a --- r3a
  /
r1----- r2b

   +--- r2a --- r3a --- r4a
  /
r1----- r2b --- r3b

让我们做另一个从A到B的复制。数据库B怎么知道

r4a

是

r3a

的后代，因此

r3a

不再是叶版本。（与

r3b

和

r2b

相同）换句话说：数据库B如何处于这种状态：

 r3a --- r4a

 r2b --- r3b

而不是此状态（所有叶修订）：

您在CouchDB中看到的“修订版”不是版本控制机制。它们纯粹用于一种称为（或MVCC）的技术，该技术允许在不实现锁的情况下并发访问数据库

---

“修订号”的名称似乎表明它可以用来追溯文档的历史，但事实并非如此。正如您已经确定的，并不是所有的修订都被复制。此外，压缩数据库时，将删除所有非当前版本。

CouchDB 2的文档包括复制算法的详细说明。答案很简单：修订历史记录在复制过程中传输。你可以在这里阅读：

数据库B如何知道r4a是r3a的后代，因此r3a不再是叶版本

---

因为r4a与r3a的ID相同-它们的版本ID不同，而不是文档ID，所以很明显r4a是同一文档的较新版本？

为什么您认为数据库B会知道这些版本的历史？谢谢@Kerr。我更新了我的问题，以便解释为什么B了解A的历史很重要。也许这个问题可以用另一种方式解决——更重要的是，我很高兴能确切地理解如何解决。这是一个真正有趣的问题。读了你的问题后，我准备给出一个与多米尼克类似的答案，但我想我可能遗漏了什么。我认为这与如何将修订历史与修订本身分开处理有关。我正试图弄清楚这到底是怎么回事。谢谢你的回答。我详细阐述了我的问题，因为遗憾的是，还有一些方面我不理解。如果您能再次分享您的想法，我将非常感激。r4b、r3a和r3b都有相同的id。根据id，r4b可能是两个r3版本的后代。