У розподілених системах управління версіями (таких як 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
Мета - визначити dта eефективно, коли на графіку є багато (скажімо, понад 100 000) вузлів. Ефективність стосується обох
- складність мережі: кількість переданих байтів та кількість необхідних об’їзних мереж
- часова складність: кількість обчислень, проведених двома серверами, що обмінюються наборами змін
Типові графіки будуть вузькими з кількома паралельними доріжками, як вище. Також зазвичай буде лише декілька листових вузлів (ми називаємо їх головами в Mercurial), як eі yвище. Нарешті, коли використовується центральний сервер, клієнт часто матиме пару наборів змін, яких немає на сервері, тоді як сервер може мати 100+ нових наборів змін для клієнтів, залежно від того, хто давно клієнт востаннє витягнув із сервера . Асиметричне рішення є кращим: централізований сервер повинен зробити невелике обчислення в порівнянні зі своїми клієнтами.