通过网络进行有效的DAG比较

在分布式版本控制系统（例如Mercurial和Git）中，需要有效地比较有向无环图（DAG）。我是一名Mercurial开发人员，对于听到有关讨论比较两个DAG的时间和网络复杂性的理论工作，我们将非常感兴趣。

有问题的DAG由记录的修订构成。修订由哈希值唯一标识。每个修订依赖于先前修订的零（初始提交），一个（普通提交）或多个（合并提交）。这是一个示例，一个接一个a地e进行修订：

a --- b --- c --- d --- e

当某人仅拥有部分历史记录并想要检索缺失的部分时，图形比较就会出现。想象一下，我只好a到c并提出x和y基于c：

a --- b --- c --- x --- y

在Mercurial中，我将进行hg pull下载d和e：

a --- b --- c --- x --- y
              \
                d --- e

目标是确定图何时具有许多（例如，超过100,000个）节点d并e有效地进行识别。效率兼顾

• 网络复杂度：传输的字节数和所需的网络往返数
• 时间复杂度：交换变更集的两个服务器完成的计算量

典型的图形将很狭窄，几乎没有像上述的平行轨迹。还有通常只有叶节点少数的（我们称之为水银他们的头），如e与y以上。最后，当使用中央服务器时，客户端通常会有几个不在服务器上的变更集，而服务器可以为客户端提供100多个新变更集，具体取决于客户端上一次从服务器上拉出的是谁。一个非对称解决方案是首选：集中式服务器应该比较给客户做一点计算。

在这种情况下，图节点具有某种唯一标识符（哈希或校验和），对吗？因此，您无需进行任何子图同构测试，只需要列出两个版本之间不同的节点列表，并且边缘对于此步骤实际上根本没有用。我在SIGCOMM 2011上发表的论文“有什么区别？无需事先说明即可进行有效的对帐””（与Goodrich，Uyeda和Varghese一起）完全考虑了这个问题：事实证明，您可以使用仅成比例的通信量来确定由两个但不都是两个通信服务器持有的节点的身份获得更改后的节点的数量，并且仅使用一次往返即可。一旦获得了该信息，就很容易在第二次往返中将更改本身拉出，而且又可以实现最佳通信。

在我们为Mercurial实现的解决方案中，另一个问题是不对称性：应该在传出带宽和CPU时间方面最小化服务器的负载，但要以客户端的负载为代价。

对我来说，这听起来像两个步骤。

1. 询问所有客户，如果他们有承诺，父母是c
2. 如果是这样，找到c的所有子元素

1.我的任务主要在客户端处理，所有客户端都需要通过网络提交哈希。