Comparaison DAG efficace sur un réseau

Dans les systèmes de contrôle de version distribués (tels que Mercurial et Git ), il est nécessaire de comparer efficacement les graphiques acycliques dirigés (DAG). Je suis un développeur Mercurial, et nous serions très intéressés d'entendre des travaux théoriques qui discutent de la complexité temporelle et réseau de la comparaison de deux DAG.

Les DAG en question sont constitués par les révisions enregistrées. Les révisions sont identifiées de manière unique par une valeur de hachage. Chaque révision dépend de zéro (validation initiale), une (validation normale) ou plusieurs (validation de fusion) des révisions précédentes. Voici un exemple où les révisions aà eont été faites l' une après l'autre:

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

La comparaison du graphique apparaît dans l'image lorsque quelqu'un n'a qu'une partie de l'historique et veut récupérer la partie manquante. Imaginez que je devais aà cet fait xet ybasé sur c:

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

Dans Mercurial, je ferais hg pullet téléchargerais det e:

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

Le but est d'identifier det eefficacement lorsque le graphe comporte de nombreux (disons, plus de 100 000) nœuds. L'efficacité concerne à la fois

• complexité du réseau: le nombre d'octets transférés et le nombre d'aller-retour réseau nécessaires
• complexité temporelle: quantité de calculs effectués par les deux serveurs qui échangent des changesets

Les graphiques typiques seront étroits avec quelques pistes parallèles comme ci-dessus. Il y aura également généralement seulement une poignée de nœuds foliaires (nous les appelons têtes dans Mercurial) comme eet yau - dessus. Enfin, lorsqu'un serveur central est utilisé, le client aura souvent quelques ensembles de modifications qui ne sont pas sur le serveur, tandis que le serveur peut avoir plus de 100 nouveaux ensembles de modifications pour les clients, en fonction de qui il y a longtemps, le client a été retiré du serveur pour la dernière fois. . Une solution asymétrique est privilégiée: un serveur centralisé devrait faire peu de calcul par rapport à ses clients.

Dans ce contexte, les nœuds de graphe ont une sorte d'identifiant unique (un hachage ou une somme de contrôle), non? Vous n'avez donc pas besoin de faire de test d'isomorphisme sous-graphique, vous avez juste besoin d'une liste des nœuds qui diffèrent entre vos deux versions, et les bords ne sont pas vraiment utiles du tout pour cette étape. Mon article SIGCOMM 2011 " Quelle est la différence? Réconciliation efficace des ensembles sans contexte préalable"(avec Goodrich, Uyeda et Varghese) considère exactement ce problème: il s'avère que vous pouvez déterminer les identités des nœuds détenus par un mais pas les deux serveurs communicants, en utilisant une quantité de communication proportionnelle uniquement au nombre de nœuds modifiés et en n'utilisant qu'un seul aller-retour. Une fois que vous avez ces informations, il est facile de tirer les modifications elles-mêmes dans un deuxième aller-retour, là encore avec une communication optimale.

Dans la solution que nous avons implémentée pour Mercurial, une autre préoccupation était l'asymétrie: la charge du serveur devrait être minimisée à la fois pour la bande passante sortante et le temps CPU, au détriment de la charge du client.

Cela me semble être un processus en deux étapes.

1. demander à tous les clients s'ils se sont engagés où le parent est c
2. si oui, trouvez tous les enfants de c

La tâche de 1. Je pense qu'elle est principalement traitée côté client, et tout le client a besoin du hachage de validation sur le net.