Confronto DAG efficiente su una rete

Nei sistemi di controllo di versione distribuito (come Mercurial e Git ) è necessario confrontare in modo efficiente i grafici aciclici diretti (DAG). Sono uno sviluppatore Mercurial e saremmo molto interessati a conoscere il lavoro teorico che discute della complessità temporale e di rete del confronto tra due DAG.

I DAG in questione sono formati dalle revisioni registrate. Le revisioni sono identificate in modo univoco da un valore hash. Ogni revisione dipende da zero (commit iniziale), uno (commit normale) o più (commit di unione) delle revisioni precedenti. Ecco un esempio in cui le revisioni aper estati fatti uno dopo l'altro:

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

Il confronto dei grafici viene visualizzato quando qualcuno ha solo una parte della cronologia e desidera recuperare la parte mancante. Immaginate Ho dovuto aalla ce feci xe ybasandomi su c:

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

In Mercurial, farei hg pulle scaricare de e:

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

L'obiettivo è quello di identificare de ein modo efficiente quando il grafico ha molti (diciamo, più di 100.000) nodi. L'efficienza riguarda entrambi

• complessità della rete: il numero di byte trasferiti e il numero di round trip della rete necessari
• complessità temporale: la quantità di calcolo effettuata dai due server che scambiano i changeset

I grafici tipici saranno stretti con poche tracce parallele come sopra. Di solito ci saranno solo una manciata di nodi foglia (li chiamiamo teste in Mercurial) come ee ysopra. Infine, quando viene utilizzato un server centrale, il client avrà spesso un paio di changeset che non si trovano sul server, mentre il server può avere oltre 100 nuovi changeset per i client, a seconda di chi molto tempo fa il client ha estratto l'ultima volta dal server . È preferibile una soluzione asimmetrica : un server centralizzato dovrebbe fare pochi calcoli rispetto ai suoi client.

In questo contesto, i nodi del grafico hanno una sorta di identificatore univoco (un hash o checksum), giusto? Quindi non è necessario eseguire alcun tipo di test dell'isomorfismo dei sottografi, è sufficiente un elenco dei nodi che differiscono tra le due versioni e i bordi non sono affatto utili per questo passaggio. Il mio documento SIGCOMM 2011 " Qual è la differenza? Riconciliazione efficiente dei set senza contesto precedente"(con Goodrich, Uyeda e Varghese) considera esattamente questo problema: si scopre che è possibile determinare le identità dei nodi che sono detenute da uno ma non da entrambi i due server comunicanti, usando una quantità di comunicazione che è solo proporzionale al numero di nodi modificati e utilizzando solo un solo round-trip. Una volta ottenute tali informazioni, è facile estrarre le modifiche stesse in un secondo round-trip, sempre con una comunicazione ottimale.

Nella soluzione che abbiamo implementato per Mercurial, un'altra preoccupazione era l'asimmetria: il carico del server dovrebbe essere ridotto al minimo sia per la larghezza di banda in uscita che per il tempo della CPU, a costo del carico del client.

Mi sembra un processo in due fasi.

1. chiedi a tutti i clienti se hanno commesso dove si trova il genitore c
2. in tal caso, trova tutti i bambini di c

Il compito di 1. Penso che sia principalmente elaborato dal lato client e tutto il client ha bisogno dell'hash di commit sulla rete.